On the benefits of using C as a language backend

[medvednikov]

V uses C as the primary backend.

Many people find this choice strange, and one of the most common comments/suggestions is "Why not use LLVM?"

1. Using a C backend is a completely valid strategy (for example, the first C++ compiler Cfront did exactly this). C can be viewed as a modern cross-platform assembly language.
   To the end-user, it doesn't really matter what intermediate step is used to generate their binary, as long as it works, and the performance is good.

2. Easy bootstrapping and development. To bootstrap V, you need to download v.c and run cc v.c. That's it. No dependencies, no bootstrapping chains, nothing. The developers of the language don't need to work on two parallel implementations, new features can be introduced and used in the language right away. V has been 100% written in V since the release.

3. C gives us amazing platform support. C runs on everything, literally everything. LLVM supports lots of platforms and architectures, but it will never beat C. Being able to run V software on everything that C supports is huge.

4. Great tooling. Warnings, static analyzers, Valgrind, etc help to ensure that everything is correct. Writing programs that pass -Wall -pedantic, Clang analyzer, PVS, and result in zero Valgrind warnings/errors is a dream of any C/C++ developer. With V it's going to be guaranteed for every V program. (We are not there yet, but very close.)

5. Stability. New languages using LLVM directly are going to crash often. That's inevitable, and can be seen across all new languages using LLVM. Major C compilers like Clang/GCC/MSVC are very stable and are highly unlikely to result in crashes when compiling C code generated by V. The V compiler hasn't crashed once for me, and I haven't received any crash reports from other users.

6. Simplicity. LLVM is a huge C++ dependency, meaning that both developers of the language and the users are forced to install it. Calling C++ is not easy from V/C, so C wrappers have to be used, increasing the number of dependencies and complexities.

There is one clear drawback: you are limited by the capabilities of C. So far I've only faced some minor annoyances that could be easily overcome. Luckily V is a very small and simple language close to C.

By the time of the 1.0 release, V will also have direct x64 machine code generation (similar to TCC), but the C backend will always be available, for production builds and for all supported platforms.

With all that said, I'm open to an alternative LLVM backend. It's good to have multiple implementations.

[ntrel]

V will also have direct x64 machine code generation

It would be a very big undertaking to optimize that code as well as the gcc or LLVM backends. Perhaps that effort would be better spent outputting LLVM assembly code:
https://stackoverflow.com/a/36093722/11653112

That assembly is also much more portable than just x64. IIUC developers working on a llvm assembly backend would not need to work with the LLVM API or link with libraries, so it should be fairly fast.

Update: LLVM assembly files are also much higher level than x64 machine code, we can use typed variables, functions, macros etc.

[medvednikov]

It will never reach the optimization levels of LLVM. But that's why we'll always have v -prod which uses Clang/GCC's optimization.

Getting a good enough optimization is possible. Go did it.

There's no reason to use LLVM assembly, since we already have a C backend. -x64 is all about compilation speed, and LLVM is slow. Also their assembly syntax is not stable.

[ntrel]

There's no reason to use LLVM assembly

It could potentially produce more efficient code than C99 using more knowledge of V's higher level constructs. I was assuming it would compile faster with optimizations off.

LLVM is slow.

Compiling LLVM assembly? In theory it should be faster than compiling C without optimizations, but perhaps it is slower than tcc.

x64 is allow about compilation speed

OK. I suppose that would be very useful when building many V packages e.g. Gentoo.

Also their assembly syntax is not stable

Sounds like a problem, unless we could avoid the unstable parts.

[medvednikov]

Impossible to avoid unfortunately. They introduce major changes to fundamental things quite often.

[DBJDBJ]

"Impossible to avoid, unfortunately. They introduce major changes to fundamental things quite often."

That might be a sure sign there are too many children without supervision in the LLVM garden...
ps: IMHO: LLVM C++ dependency, is a slow train crash.

[DBJDBJ]

There is no more effective cooling, for young and hot developers, but to explain key points about C. Poetically.

C is the key ingredient of the concrete poured into the foundations of this civilization.

It is quite ok to be intelligent and investigative. After a short excavation, rock-solid C foundations are always met.

V seems to be just on top of those foundations. With no layers of dirt in between.

[kfsone]

Be done with this debate and just call it the reference implementation, otherwise you're wasting your time on the same people who love to regale you with tales of that one week spent reducing 3 cpu cycles out of loop by 300 lines of template magic that coerced a for loop to collapse into some simd insns, because they didn't want to have to split one of the expressions across two lines.

It doesn't actually matter how fast your language is, it matters how quickly people learn to write efficient programs in it.

In C++s early days I routinely encountered people who would benchmark C++ as a failure by doing something like:

// circa 1999, pre small-str optimization etc
for (int i = 0; i < 100000; i++) {
  std::string s("hello world");
}

benchmarked against

for (int i = 0; i < 100000; i++) {
  const char* s = "hello world";
}

with the earliest compilers, yes, there's a good chance that C++ would actually do the pathological thing you told it to do.

Python is another great example. It's not fast, but everyone accepts that, and so never questions the fact that most of the python that clutters our daily lives is torturously slow because people wrote awful code and shrugged when it was slow: "that's just python".

https://www.youtube.com/watch?v=D3h62rgewZM << that's the antithesis of how you implement sieve in python, which is why it is that slow.

The function call op in python's virtual machine maps to a lot of conditional instructions; making python-calls in a loop is probably 1% of the planet's carbon footprint.

Let me put it another way: C and C++ programmers spend too much of their time writing assembler in C-syntax, or "paraphrasing code". C and C++ (outside atomics) are abstract machines. But if you take knowledge about your current physical hardware and low-level internal details about your compiler, you can refactor a given piece of C or C++ code to be expressed as a specific set of instructions, which will then be someone elses' can-of-worms to try and reverse engineer when the next generation CPU really doesn't like you doing that.

So I love the fact that V takes the "unsafe" concept a step further and firewalls shenanigans behind opt-in command lines switches.

[topcheese]

Hi, longtime languages lurker here, and I'm loving what V has going on. I should be an expert by now, but I'm not, so please forgive my ignorance on the subject. I'm not trying to suggest anything, but just thinking, so you'll see me pop-up here and there with questions.
I recently discovered Halide, and I was wondering where it might fit in with V? Would it be an easier route to C++ support?

I've always liked what's going on with Cosmopolitan C, and Go does support it as an experimental target. Is it possible for V to support them, or is there no need?
~Thanks for creating such a great language!

[tajmone]

I've always liked what's going on with Cosmopolitan C, and Go does support it as an experimental target. Is it possible for V to support them, or is there no need?

I agree, Cosmopolitan "fat binaries" are a cool solution for cross-platform distribution, and it would be great to see V offer native support for it as a backend. Although fat binaries might not be everyone's choice, there are many contexts in which they make sense, and where the small penalty of the extra size-bloat doesn't matter. Having a single binary for multiple OSs dramatically increases the chances of a software tool being passed around, since the same binary will work across OSs and can be shared by their end users at will.