[ludocode]

I was definitely hoping for a look at modern compilers. This article was written last month, yet its history ends with the release of LLVM. There's quite a lot of development in small C compilers lately!

- TinyCC, SCC (Simple C Compiler) and Kefir are all fairly serious projects in active development.

- QBE is a new optimizing backend much simpler than LLVM; cproc and cparser are two of the C compilers that target it, in addition to its own minic.

- There's the bootstrapping work of stage0, M2-Planet, and mescc.

- chibicc is an educational C compiler based on the author's earlier 8cc compiler. The author is writing a book about it.

- lacc is another simple compiler that works well, although development appears to have stalled.

I think a lot of these projects are inspired by the problem that GCC and Clang/LLVM are now gigantic C++ projects. A pure C system like OpenBSD or Linux/musl/BusyBox ought to be able to compile itself without relying on C++. We really need a production quality open source C compiler that is actually written in C. I'm hopeful one of these compilers can achieve that someday.

[sigsev_251]

- Though freeware and not foss, there is also pellesc over at Windows land, with almost full C23 support.

- For small 8 bit systems, SDCC is an excellent choice, supporting even C23 features! Also its lead maintainer is a committee member with really useful contributions to the standard.

- I have heard the RiscOS compiler is pretty cool and supports modern standards. That one uses the Norcroft frontend.

I agree with you in that we need a production level C compiler written in C. Though that is not a simple task and the C community nowadays prefers to engage on infighting over pedantic issues or rust rather than working together. A simple example of this is the lack of a modern library ecosystem, while everyone and their mother has their own custom build system. Even though C is sold as a performant language, there isn't a single parallelism library like OneTBB, Kokkos or HPX over at C++. Don't get me started on vendors not offering good standard support (Microsoft, macos-libc, OpenBSD libc)...

One correction though, cparser uses libfirm as a backend, not qbe. Also the author of chibicc has stopped writing that book AFAIK.

Bonus non-c based entries: - The zig community is working on arocc. Judging by the awesomeness of zig cc, these are really good news. - Nvidia offers their EDG based nvc with OpenACC support for free these days, which is cool.

Edit: formatting

[Gibbon1]

I agree with the thought that we need a C compiler that is written something other than C++.

One thing that caught my attentions is this paper.

https://www.cs.purdue.edu/homes/rompf/papers/xhebraj-ecoop22...

"This work is based on the observation that in cases where returning a stack-allocated value is desired, the value’s lifetime is typically still bounded, it just needs to live a little bit longer than the procedure that allocated it. So, what would happen if we just don’t pop the stack and delay it until one of the callers resets the stack, popping multiple frames at once? It turns out that this surprisingly simple idea can be made to work rather well."

Create a C compiler that does this.

[trealira]

> QBE is a new optimizing backend much simpler than LLVM; cproc and cparser are two of the C compilers that target it, in addition to its own minic.

I thought cparser targeted libFirm. That's what their GitHub page says [0].

"It acts as a frontend to the libFirm intermediate representation library."

> We really need a production quality open source C compiler that is actually written in C.

I honestly think cproc or cparser are almost there already. For cproc, you just need to improve the quality of code optimization; it's really QBE you'd need to change. For example, you could change unnecessary multiplications by powers of 2 into left shifts (edit: IDK if it's cproc or QBE that's responsible for this, actually), and you could improve instruction selection so that subtraction is always something like "sub rax, rdi" and not "neg rdi / add rax, rdi" [1]). It also doesn't take advantage of x86-64 addressing, e.g. it will do a separate addition and then a multiplication instead of "mov eax, [rdi + rsi * 8]".

For cparser, I notice slightly higher quality codegen; libFirm just needs more architecture support (e.g. AMD64 support appears to work for me, but it's labeled as experimental).

[0]: https://github.com/libfirm/cparser

[1]: I'm pretty sure this is the line of code that generates it, too: https://c9x.me/git/qbe.git/tree/amd64/emit.c#n418

[sylware]

You have the cproc compiler which does use the QBE backend. It generates much faster code than tcc since there are some basic optimization passes. On bz2 compression, with crude and basic testing, I got ~70% of the speed of gcc 13.1. tcc code is really slow, I am thinking of a QBE backend for tcc.

I would use that everywhere instead of the grotesquely and absurdely massive and complex gcc (and written in that horrible c++!). I would re-write in assembly some code hot spots. But it means those extra ~30% performance are accutely expensive, at least they could have been carefull to keep gcc written in simple and plain C99 (with benign bits of c11) to reduce the technical cost. Yeah, switching gcc to c++ is one of the biggest mistakes in open source software ever (hopefully, that mistake is not related to b. gates donations to MIT media labs revealed by the pedophile Epstein files... if all that is true though not to mention that would explain the steady ensh*tification of GNU software).

The problem is linux which does require bazillions of gcc extensions to even compile correct kernel code nowdays. You can see clang (which is no better, actually even worse) playing catchup with gcc for all the extensions creeps the kernel is getting.

All that stinks corpo-backed planned obsolescence, aka some kind of toxic worldwide scam.