Hacker News Reader

In the x86-64 port, they've been moving OpenVMS to use LLVM too. With the VAX->Alpha port, DEC introduced a common backend for all their OpenVMS compilers, called "GEM". For the Alpha->Itanium port, Compaq/HP kept the GEM backend but modified it to generate Itanium code instead of Alpha.

For the x86-64 port, instead of investing in modifying "GEM" to support x86-64, VSI decided to use LLVM as a backend, and then write a translator from GEM's intermediate representation to LLVM's. So they keep the same frontends as before – except for C++, where they replaced the EDG/Intel frontend with LLVM – but now use LLVM as a backend. https://llvm.org/devmtg/2017-10/slides/Reagan-Porting%20Open...

OpenVMS has a somewhat unusual ABI. For x86-64 they've tried to make it more consistent with the standard Linux x86-64 ABI, but there remain some distinctive features. One feature (which I actually really like, I think it is a shame that other ABIs don't do this), is that variadic function calls pass the argument count in a register (%rax on x86-64). Another is that all functions must have a 32-bit address; the code of a function can be allocated above 4GB, but they allocate a trampoline under 4GB which jumps to its actual code – this was done to simplify interoperability between 32-bit and 64-bit code in the same address space. https://docs.vmssoftware.com/vsi-openvms-calling-standard

IBM still has their classic XL C/C++ compilers for AIX, IBM i and mainframe, but they've been converging to LLVM. I believe the pre-LLVM versions share a common backend with some of their other language compilers (COBOL, PL/I, PL/X, PL.8, etc), ultimately going back to work of their Toronto and Yorktown labs starting in the 1980s. More recently they've started replacing their C/C++ frontends with LLVMs, while keeping their own backend; and even more recently swapping out their backend for LLVM's too.

Good point. I completely forgot IBM. And I even was a trainee there, when mainframes where a big thing, PCs an exception and nobody including myself had heard about AIX (although technically it was a year old).

Probably not qualifies as "wide use" but embedded compilers like SDCC still matters. Yes, 8-bits are giving way to ARM, but there will be a few more millennia before they are out.

Clang, GCC and MSVC are the big ones, the rest are more or less niche compilers - with Clang and GCC only differing in small details.

(one could argue that MSVC is slowly becoming a niche compiler too - it feels like it's not as important anymore as it was 10..15 years ago, maybe because a lot of new C/C++ programmers seem to start on Linux, not Windows - that's at least the 'general vibe' I'm getting)

Depends on how much one considers the game industry niche, where Linux hardly has a role other than game servers.

True of course, but then MSVC only matters for building Windows and Xbox games (and at least on Windows I would also give Clang a try since it typically optimizes better than MSVC).

And as IDE for Sony and PlayStation toolchains.

While Microsoft has embraced clang as well, including on XBox, I am certain it does not consume all Windows SDKs, not yet.

Per [1], Zig seems to have its own C compiler (AFAICT it's not just a frontend to an existing one)

[1] https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

Currently, zig cc is the Clang frontend which is linked into the Zig compiler (most things in that blog post are about differences between the Zig toolchain and a typical Clang toolchain for cross-compilation, and how Zig invokes the Clang frontend).

I'm not sure what the current plan is for C compilation after the LLVM divorce and after Clang will be moved into a Zig package (e.g. I remember talk that arocc [1] is going to be integrated into the Zig compiler, but not sure if that's still planned, or if C compilation will also be delegated to the new Clang package along with C++ and ObjC compilation).

[1] https://github.com/Vexu/arocc

For C++, there are exactly four independent frontends in wide use (gcc, clang, msvc, edg) and three independent stdlibs (libstdc++, libc++, STL).

I’m not sure how many independent compiler backends are widely used with those frontends and stdlibs.

tcc is popular too, as a fast non-optimizing compiler.

Similarly, cproc with the QBE backend. Focused on simplicity an getting to 80% of gcc/clang with 20% of the complexity/size.

The maintainer of oksh has an interesting comparison[1] between tcc and cproc as it comes to the performance of the generated code on OpenBSD. To be clear, cproc delivers. But tcc beats it, usually significantly, for reasons I can’t even begin to see how to investigate. It actually beats cparser/libfirm in most cases, which just makes no sense. (I ran the benchmarks myself on Linux some months ago; with the versions given in the original post, they reproduce.)

[1] https://briancallahan.net/blog/20211010.html

Those results are truly strange, tcc on the same level as gcc/clang for all tests? Something's going on

Right?.. There’s a reason I decided to spend the couple of hours it took to get libfirm to compile. Then again, it’s a shell benchmark, most of it is bound to be syscalls and (nonfancy) parsing, so the space for an optimizing compiler to make a difference is bound to be fairly limited. All the compilers in the test are within 2× of the best one, and CompCert isn’t exactly a speed demon either. I’d love to dig into this, but there are so many layers of stuff I don’t really know where to start.

I tested with tcc, cparser and my own slimcc, the benchmark showed multiple process with htop, so there are some dynamic cpu scaling randomness going on. I saw larger run-to-run differences with the same binary, than with comparing cherry-picked best-run of each, so probably not the best benchmark.

Fabrice Bellard, unbelievable what a single person can get done.

Reply on news.ycombinator.com