QBE – Compiler Back End | Hacker News Reader

QBE – Compiler Back End

c9x.me

93 pointsTomte37 comments

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.

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.

>Personally I consider ESP32

Sure you don't mean Tensilica i.e. legacy ESP32?

Espressif has notably switched to RISC-V.

> Espressif has notably switched to RISC-V

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).

>Not really switched

Yes very much switched. Thoroughly[0].

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.

0. https://riscv.or.jp/en/2021/02/latest-esp32-includes-risc-v/

> 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.

Although unfortunately not open source proper, vbcc[0][1] is interesting.

0. http://www.compilers.de/vbcc.html

1. https://en.wikipedia.org/wiki/Vbcc

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.

Fair. But note that while not a "compiler kit", VBCC has front/backend separation. This is why I mentioned it.

Of course, as it isn't open source, third party backends/frontends are unlikely to occur.

Fortunately, despite not open source, the code and documentation can still be studied.

Out of curiosity, why are you still using 32-bit architectures?

Dunno if this is where you're coming from, but working in 32-bit isn't that wacky. For example a very popular microcontroller [0] is 32-bit.

EDIT: definitely not "maybe the most" popular

[0]: https://en.wikipedia.org/wiki/ESP32

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.

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.

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.

But much better and faster optimizations than egc

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)

"my current favourite discovered dark art" is an excellent way to put it and I may end up stealing it.

Shameless plug: http://cwerg.org

Cwerg has backends for x86-64, Aarch64, Arm32 (non-thumb) and can produce executables, i.e. comes with an assembler.

It is however fairly opinionated in many ways.

> The C codebase of QBE is intended to remain hobby-scale and pleasant to hack on.

As much as I like the idea behind QBE, our definition of "pleasant C code" differ by orders of magnitude.

Discussed in the past:

Show HN: https://news.ycombinator.com/item?id=11555527 (April 23, 2016 — 241 points, 68 comments)

QBE vs. LLVM:

https://news.ycombinator.com/item?id=25273907

IR:

https://en.wikipedia.org/wiki/Intermediate_representation

Transpilation – A summary of ideas about transpilation (AI, LLM, Code, etc.):

https://news.ycombinator.com/item?id=39835365

An intersting idea, but like, if your idea of hackable is dense c code with no comments and short names, it definitely differs from mine!

see, e.g,. https://c9x.me/git/qbe.git/tree/ssa.c

Fully agree. Comments are a must. But not like these:

    if (!n) {
        /* uh, oh, warn */
        return UNDEF;

Any chance of making QBE available as a library? Even something as simple as pass an IR string get the corresponding function would be really nice.

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.

That's unfortunate...

Pronounced 'kyubey'?

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.

easier to color graph if you have like 4 registers :-)

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.

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.

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.

Curious to know how to compares with https://cranelift.dev/

Shouldn't it be Qompiler Back End?

Reply on news.ycombinator.com