I love that there are compilers beside the big 2 with a simple API, and small enough codebase, that produce decent-enough code, but damn did I make an honest effort to crack the QBE source code, and it is just impenetrable, not only because the difficulty of the domain, but the code is just arcane.
It was one of the projects that made me realize what the arcane wizened sages of olden C were capable of - C is not as much a programming language with best practices as a template for one - and many competing ideas and interesting ways of coding have emerged over the ~40 years of C dominance (starting from the emergence of the language, to the early 2000s, around when for various reasons, OOP kinda 'won') - if one abandons all pretense of safety and comfort.
There's this project and MIR - both have the same mad science DNA, QBE being a bit more friendly and well documented, with MIR making faster code - boiling down mostly to the architectural decision that MIR does inlining while QBE does not.
I personally went with QBE for my hobby project because of C-interop, but at least in my tests, I found IR much faster and better codegen than MIR. Neither of MIR or IR are friendly/easy though.
I really want to like QBE, but declaration blocks like this make it feel like 1970s Unix code more than a modern hackable piece of software:
int t, x, r, rf, rt, nr;
bits rs;
Ins *i, *i1;
Mem *m;
Ref *ra[4];
I think it deters some users by making it hard to read and understand the relatively subtle code in the 300 line function that follows. (Skill issue, I know)
Yeah, I tried my hand at adding amd64_win support to QBE, but going through the very dense code was a slog. I kept refactoring and commenting it just to make heads or tails of it, but ultimately realized I would never be able to minify it back to something upstreamable. I applaud Scott Graham's perseverance and tenacity.
Quentin took pity on me and let me upstream amd64_win with my lengthy variable names and including chatty comments. :)
SysV and Win x64 differ enough that the Windows code is mostly unrelated to/detached from the other backends, so it doesn't feel (too) awful for it to have its own idiosyncratic style.
I tried to look at the QBE code years ago while I was writing my own SSA code. I got approximately nowhere because I can't read code like that. Turns out that reading the SSA papers and writing the code was a lot easier than reading QBE.
Yeah that looks like they've prioritised code golfing a bit too much over code quality. Also using AT&T assembly syntax shows poor taste. Definitely 80s themed software.
It is hard for me to fully trust a compiler backend that isn't self hosted. There is a discipline that self hosting imposes that would both improve the quality of their ir as well as the backend itself. A self hosted backend can always be updated to have performance meeting or exceeding the best that llvm or any other backend can offer.
Windows support is huge. One of the barriers to me considering QBE for a project in recent memory was that it had no story for proprietary OSes (Windows, MacOS), and whether I like it or not, those make up the overwhelming majority of desktop-like market share. (this is the same reason I find Hare, a language that builds with QBE, interesting but not practical for my own uses - targeting only Linux and the BSDs is a non-starter, even if I personally am a Linux-only guy)
One of the benefits of this new QBE feature of supporting windows could be that this allows a language like Hare to be used for windows too, all the more power to Hare and other programming languages built on top of QBE!
In theory, sure, but there's no way Hare is going to ever officially support Windows. Even if the compiled backend supports the target, the language still needs to abstract over the OS interfaces and implement syscalls.
I'm not familiar with the language but if it targets libc, it might be easily able to work with MINGW. There are mingw/native versions of most popular libraries.
The whole point of Hare is to be a part of a modern computing environment that offers most of the creature comforts of modern computing, yet is small enough to be understood by one person.
The Linux kernel ABI, while stable, is not simpler than libc and not portable at all. You can build the modern computing environment on mingw.
However, if they chose to target Linux–only to show how low–level Hare is, that's understandable as well —no shade.
To take it to its logical conclusion, they're saying libc will be a package you install on your Hare/Linux system for compatibility with obsolete systems, which to me implies willingness to work on ports to other platforms —you're not going to replace libc otherwise.
Having Blaise work on Windows, could be interesting... Though of course only in the long tail of already built Delphi apps... that still have source.... that are reasonably written... that don't rely on now unsupported libraries...
Hmmm... Ah yes. These may be some of the reasons people might not do Delphi as much anymore. Still, Delphi was great for me and helped me get a mortgage and things like that.
The Blaise author is progressing his development along nicely using QBE for the compiler. To me, Blaise looks like a team progressing things nicely, but I think it's mostly the original author.
Blaise could be a neat Pascal compiler with a great deal of old cruft cleaned out and is quite quick.
Besides FreePascal, I think those of us that like such languages are probably better playing with Ada or Modula-2.
Ada, as it continues to evolve as ISO standard, and there is an official open source compiler (among 7 vendors), and Modula-2 as it got added to the set of GCC frontends, and being the language Wirth actually designed for systems stuff (the uppercase keywords are a downer if not using a proper IDE though).
Hare did the legwork of adding proper DWARF support afaik. Btw that spec is huge, and the debug info generator ended up being larger than the rest of the compiler at that point.
Btw adding some non-standard debugging support to QBE is not impossibly hard even without that. You can inject bogus no-ops per line, force the compiler to keep them, and it will dutifully track all state values throughout the pipeline, and likewise you can track values from variables to SSA assignments, to temp registers to actual registers, its mostly bookkeeping.
I'm guessing you mean dwarf, but I started on a pdb library that I'd planned to use along-side qbe eventually. (The code currently lives in a jitting-C compiler https://scot.tg/2023/05/02/debugging-with-pdbs/ that uses dynasm directly though.)
Read the article, 1.2 was 40% as fast on one specific benchmark, and its lack of speed largely came down to having a much worse CRC implementation, not general shortcomings.
Now 1.3 is 63% the speed of gcc O2 on this largely hostile benchmark.
Whoops somehow I missed the 63%. Either way, it's still too slow to be considered production ready. Hare is the only real example of a QBE based language but why put up with something that's C-like with manual memory management but slower than a bunch of managed languages? If I'm going to have to write my own allocations and deal with a static language, it needs to be within spitting distance of C. Not slower than Java, Go or Common Lisp.
It's a cool hobby project though, can't take that away from them. On a technical basis, 63% of -O2 with the amount of LOC written is impressive.
More like no inlining, so-so register allocation, and a simple code generator. I believe also no loop unrolling. Other compilers could handle the table-less CRC implementation.
(* Normally a thread that recent with significant comments would count as a dupe (https://news.ycombinator.com/newsfaq.html), but it didn't get that much frontpage time so I've made an exception.)
I love that there are compilers beside the big 2 with a simple API, and small enough codebase, that produce decent-enough code, but damn did I make an honest effort to crack the QBE source code, and it is just impenetrable, not only because the difficulty of the domain, but the code is just arcane.
It was one of the projects that made me realize what the arcane wizened sages of olden C were capable of - C is not as much a programming language with best practices as a template for one - and many competing ideas and interesting ways of coding have emerged over the ~40 years of C dominance (starting from the emergence of the language, to the early 2000s, around when for various reasons, OOP kinda 'won') - if one abandons all pretense of safety and comfort.
There's this project and MIR - both have the same mad science DNA, QBE being a bit more friendly and well documented, with MIR making faster code - boiling down mostly to the architectural decision that MIR does inlining while QBE does not.
IR (https://github.com/dstogov/ir) is worth a look in this vein too.
I personally went with QBE for my hobby project because of C-interop, but at least in my tests, I found IR much faster and better codegen than MIR. Neither of MIR or IR are friendly/easy though.
> I love that there are compilers beside the big 2
Whatever happened to Tendra?
I really want to like QBE, but declaration blocks like this make it feel like 1970s Unix code more than a modern hackable piece of software:
I think it deters some users by making it hard to read and understand the relatively subtle code in the 300 line function that follows. (Skill issue, I know)Yeah, I tried my hand at adding amd64_win support to QBE, but going through the very dense code was a slog. I kept refactoring and commenting it just to make heads or tails of it, but ultimately realized I would never be able to minify it back to something upstreamable. I applaud Scott Graham's perseverance and tenacity.
Quentin took pity on me and let me upstream amd64_win with my lengthy variable names and including chatty comments. :)
SysV and Win x64 differ enough that the Windows code is mostly unrelated to/detached from the other backends, so it doesn't feel (too) awful for it to have its own idiosyncratic style.
I tried to look at the QBE code years ago while I was writing my own SSA code. I got approximately nowhere because I can't read code like that. Turns out that reading the SSA papers and writing the code was a lot easier than reading QBE.
Yeah that looks like they've prioritised code golfing a bit too much over code quality. Also using AT&T assembly syntax shows poor taste. Definitely 80s themed software.
It is hard for me to fully trust a compiler backend that isn't self hosted. There is a discipline that self hosting imposes that would both improve the quality of their ir as well as the backend itself. A self hosted backend can always be updated to have performance meeting or exceeding the best that llvm or any other backend can offer.
Bitdiddler style, he thinks he's smart for making his code convoluted and unreadable.
Windows support is huge. One of the barriers to me considering QBE for a project in recent memory was that it had no story for proprietary OSes (Windows, MacOS), and whether I like it or not, those make up the overwhelming majority of desktop-like market share. (this is the same reason I find Hare, a language that builds with QBE, interesting but not practical for my own uses - targeting only Linux and the BSDs is a non-starter, even if I personally am a Linux-only guy)
I agree!
One of the benefits of this new QBE feature of supporting windows could be that this allows a language like Hare to be used for windows too, all the more power to Hare and other programming languages built on top of QBE!
In theory, sure, but there's no way Hare is going to ever officially support Windows. Even if the compiled backend supports the target, the language still needs to abstract over the OS interfaces and implement syscalls.
I'm not familiar with the language but if it targets libc, it might be easily able to work with MINGW. There are mingw/native versions of most popular libraries.
The whole point of Hare is to be a part of a modern computing environment that offers most of the creature comforts of modern computing, yet is small enough to be understood by one person.
This doesn't clarify much.
The Linux kernel ABI, while stable, is not simpler than libc and not portable at all. You can build the modern computing environment on mingw.
However, if they chose to target Linux–only to show how low–level Hare is, that's understandable as well —no shade.
To take it to its logical conclusion, they're saying libc will be a package you install on your Hare/Linux system for compatibility with obsolete systems, which to me implies willingness to work on ports to other platforms —you're not going to replace libc otherwise.
It is not libc based.
Isn't libc mandatory on OpenBSD?
It looks like they do link to libc on OpenBSD hosts, but other hosts directly invoke syscalls
There was an article linked on here or lobste by an OpenBSD dev showing how to make your own "libc".
The main issue on that OS is that it is neither ABI or API stable.
The Blaise Pascal compiler uses QBE for it's backend compiler.
https://github.com/graemeg/blaise
Having Blaise work on Windows, could be interesting... Though of course only in the long tail of already built Delphi apps... that still have source.... that are reasonably written... that don't rely on now unsupported libraries...
Hmmm... Ah yes. These may be some of the reasons people might not do Delphi as much anymore. Still, Delphi was great for me and helped me get a mortgage and things like that.
The Blaise author is progressing his development along nicely using QBE for the compiler. To me, Blaise looks like a team progressing things nicely, but I think it's mostly the original author.
Blaise could be a neat Pascal compiler with a great deal of old cruft cleaned out and is quite quick.
Besides FreePascal, I think those of us that like such languages are probably better playing with Ada or Modula-2.
Ada, as it continues to evolve as ISO standard, and there is an official open source compiler (among 7 vendors), and Modula-2 as it got added to the set of GCC frontends, and being the language Wirth actually designed for systems stuff (the uppercase keywords are a downer if not using a proper IDE though).
Naturally Delphi still has lots of goodies.
Nearly ideal. The only stopper for me is missing a way to add source level debugging info.
Hare did the legwork of adding proper DWARF support afaik. Btw that spec is huge, and the debug info generator ended up being larger than the rest of the compiler at that point.
Btw adding some non-standard debugging support to QBE is not impossibly hard even without that. You can inject bogus no-ops per line, force the compiler to keep them, and it will dutifully track all state values throughout the pipeline, and likewise you can track values from variables to SSA assignments, to temp registers to actual registers, its mostly bookkeeping.
I'm guessing you mean dwarf, but I started on a pdb library that I'd planned to use along-side qbe eventually. (The code currently lives in a jitting-C compiler https://scot.tg/2023/05/02/debugging-with-pdbs/ that uses dynasm directly though.)
Is QBE intended for production use, or is it primarily a research/educational project?
Well according to this it's currently around 40% as fast as gcc -O2...
Read the article, 1.2 was 40% as fast on one specific benchmark, and its lack of speed largely came down to having a much worse CRC implementation, not general shortcomings.
Now 1.3 is 63% the speed of gcc O2 on this largely hostile benchmark.
Whoops somehow I missed the 63%. Either way, it's still too slow to be considered production ready. Hare is the only real example of a QBE based language but why put up with something that's C-like with manual memory management but slower than a bunch of managed languages? If I'm going to have to write my own allocations and deal with a static language, it needs to be within spitting distance of C. Not slower than Java, Go or Common Lisp.
It's a cool hobby project though, can't take that away from them. On a technical basis, 63% of -O2 with the amount of LOC written is impressive.
I’m hopeful for Blaise.
More like no inlining, so-so register allocation, and a simple code generator. I believe also no loop unrolling. Other compilers could handle the table-less CRC implementation.
clearly the latter.
So will hare now support windows?
Drew and team are pretty clear about being philosophically against that idea: https://harelang.org/documentation/faq.html#will-hare-suppor...
Related. Others?
QBE – Compiler Back End - https://news.ycombinator.com/item?id=48059633 - May 2026 (28 comments*)
Blaise – A modern self-hosting zero-legacy Object Pascal compiler targeting QBE - https://news.ycombinator.com/item?id=48058644 - May 2026 (55 comments)
Qbecc – QBE based C compiler - https://news.ycombinator.com/item?id=45461195 - Oct 2025 (3 comments)
Let's write a peephole optimizer for QBE's ARM64 back end - https://news.ycombinator.com/item?id=45099348 - Sept 2025 (1 comment)
QBE – Compiler Back End - https://news.ycombinator.com/item?id=40346320 - May 2024 (37 comments)
cproc – Small C11 compiler based on QBE - https://news.ycombinator.com/item?id=32466098 - Aug 2022 (1 comment)
QBE 1.0 - https://news.ycombinator.com/item?id=31846433 - June 2022 (3 comments)
I wrote a peephole optimizer for QBE - https://news.ycombinator.com/item?id=30864448 - March 2022 (5 comments)
Cproc C Compiler - https://news.ycombinator.com/item?id=28242024 - Aug 2021 (45 comments)
Cproc – a C11 compiler using QBE as a back end - https://news.ycombinator.com/item?id=25273918 - Dec 2020 (1 comment)
QBE vs. LLVM - https://news.ycombinator.com/item?id=25273907 - Dec 2020 (99 comments)
Show HN: QBE – a new compiler back end - https://news.ycombinator.com/item?id=11555527 - April 2016 (68 comments)
(* Normally a thread that recent with significant comments would count as a dupe (https://news.ycombinator.com/newsfaq.html), but it didn't get that much frontpage time so I've made an exception.)
Those are related but the current link is about a new release that dropped yesterday (June 1 2026).
[dead]