QBE is really interesting, but for people like me who still use 32 bit architectures unfortunately a bit limited. Someone recently pointed me to the Eigen compiler kit (see e.g. https://github.com/EigenCompilerSuite/) which - like QBE - is a lean alternative to LLVM, but supports much more architectures than QBE, even some 16 bit ones; since last week also Xtensa (ESP32) is officially supported. It's still beyond me why the Eigen kit, which has been in development for more than ten years, is not more popular.
QBE (and Eigen) are compiler kits, i.e. useful if you implement your own compiler. There are a lot of open-source C compilers already available for nearly any architecture.
ECS looks cool, and also supports the 68000. The described ABI seems very incompatible with AmigaOS (a6) although it is likely possible to instruct the compiler to do otherwise.
Unfortunately missing in ECS is RISC-V, which QBE supports.
> Unfortunately missing in ECS is RISC-V, which QBE supports
Well, the Tensilica ABI only took a few weeks to implement; so I assume that when enough people ask for a RISC-V backend, there will be one in reasonable time. Personally I consider ESP32 and ARM32 support more useful.
Not really switched; they offer ESP32 models with (so far) single-core RISC-V; I don't think they planned to stop selling the original ESP32 designs (they wouldn't do themselves a favour).
While obviously only for new chips, years have already passed, and many new chips have been released. Tensilica are now only present in a minority of their offerings.
>I don't think they planned to stop selling the original ESP32 designs
In this market, having long term availability is important.
> While obviously only for new chips, years have already passed
Well, in 2022 they upgraded to the L7 cores.
> having long term availability is important
So they will obviously continue to produce the tensilica models (which they wouldn't if they really "switched"); that's all I (and many other developers) need.
Memory efficiency just for one. For most programs, and especially in the embedded space, 64b systems carry around (and process) a lot more zeros than 32b systems do. You can still do 64b math when you need it, but you don’t have to pay for it when you don’t.
Given that software is always too big, this can often be a product-making distinction.
32 bit is still very common for smaller CPUs that aren't in the "application processor" class.
They are cheaper because they use less area, and they're also more memory efficient because pointers are all half as big. On these CPUs you don't have 4GB of RAM so you don't need a big address space.
It's good enough for the majority of use cases and systems; even an eight bit MCU is sufficient for many cases. If you design a product, saving power and cost makes the difference.
As far as I know, webassembly only supports a 32 bit address space on all platforms at the moment. There’s a memory64 proposal, but it doesn’t look to be widely adopted yet.
Did a port of busybox bzip2 compression code to plain and simple C99, and cproc/qbe gives me 70-80% of gcc (13.2.0) speed on amd zen2 (tinycc generated machine code is 2 times slower than gcc, but it is really simple and clean assembly code... so it will have its use cases...).
Namely, the combo of cproc/qbe + custom assembly would be the perfect toolchain for a lean open source stack with more than decent performance. Yeah, but we have still people missing out why c++ is so much toxic...
Wow thank you for these back of the envelope benchmarks. I wanted to "feel out" the practicality of using tinycc with cosmopolitan over the provided gcc implementation (mostly as a fun project to re-educate myself with c and assembly) but now I think I might be better off just using the provided toolset and "building something useful" (aka now I want to get lost in how the strace/xed/dynamic assembly stuff works in cosmopolitan as it's my current favorite discovered dark art while looking through its codebase)
I was disappointed by its architecture too. You must write intermediary files, you must call qbe as a separate binary, and you must write the resultant objects to disk.
If I recall correctly, the author has no interest in re-architecturing qbe like this.
Split spiller and register allocator thanks to SSA form. (Simpler and faster than graph coloring.)
IMHO the fixation on graph colouring really held back the development of compilers. SSA was known in the late 80s but for some reason everyone thought graph colouring was the Right Way To Do It, and it only took until the turn of the century for that sentiment to change.
You can (and people do) do graph coloring on SSA form, just the same as you can do linear scan without SSA. SSA helps graph coloring, in fact, thanks to the discovery that the interference graph of SSA values is chordal and the consequences of that...which was only discovered in 2005.
SSA is more of a control flow representation and is broadly orthogonal to register allocation--you can use graph coloring to allocate registers in SSA and you can do linear scan forms of allocation without SSA.
I don't know much about compiler development, but this seems pretty high level to me. Why would I not just compile to C and get almost all the same benefits, except it being small and hackable, but TCC is that too. And if you compile to C you can target even more architectures.
