This is exactly my gripe unfortunately, it feels like needless fragility. IIRC the author has said they believe it wouldn't be too difficult to patch QBE to work as a library, but from what I've seen the code is somewhat terse and eccentric.
Cool project, and FWIW it's like one Claude prompt to add MIPS support to this. I did that and then was able to compile my little custom language to the N64.
> it's like one Claude prompt to add MIPS support to this
Can you provide the code somewhere? Is it complete? Does it really work? I have a hard time to believe that an LLM really can generate a complete and working backend for a target architecture with "one prompt". From my experience with such tools, by the end of the day it takes longer until it covers all edge cases and actually works than when writing it myself.
The backend is only ~1300 lines. QBE is a super simple project which is why adding a backend to it worked so well. I just pointed Claude at the existing RISC-V backend for reference and it whipped up the MIPS one. It really does work, though there might be bugs I didn't run into. I compiled an Amiga MOD player, written in my language, to the N64 and it worked fine, if that gives you an idea of how stress tested it was. IIRC it runs about 5x slower than GCC-generated code.
Interesting, thanks for posting. I had a first look and think that the AI has messed up with the floating-point and casting instructions (i.e. just copied over the RV instructions). I also spotted other places (e.g. TLS) which look like RV. It's also surprising that the code - as you say - is so much slower than (optimized?) GCC, since QBE is assumed to be at 70-80%.
As the other commenter said, I don't think contributing it would be that useful, since QBE is a rather zen-garden project and I don't think the author would accept slop. Also he could just generate it with a prompt himself :P
It looks like it doesn't have native support for identifying GC roots, so it's either conservative GC or explicit stack management. I would really like to see something that is (mostly) memory-safe and has string-as-bytes. It's a bit wild that people use Chez Scheme as a target IR for lack of better options.
I love QBE, but it does have its limitations:
- It handles the ABIs for passing and returning structures in registers, but only with superfluous copies to and from the stack.
- Can't generate debug info for data. This is probably due to lack of assembler support and/or complexity in the DWARF format.
- The line number debug info directives are currently undocumented and don't support inlined functions.
But it's smol, effective, and it doesn't make you deal with phi nodes!
Tons of these tools I use are from these guys (among 2f30). Small, predictable, usable, such as pointtools and catpoint. Sfeed for RSS, scc for gopher and so on, and smu for markdown from git repos > html.
I really like QBE but I hope they will make it a true library because I don't want to launch a subprocess to compile a program.
There are at least 2 Go libraries written in Go, based on QBE. One is used by this project: https://github.com/xplshn/gbc
This is exactly my gripe unfortunately, it feels like needless fragility. IIRC the author has said they believe it wouldn't be too difficult to patch QBE to work as a library, but from what I've seen the code is somewhat terse and eccentric.
There is a library conversion fork: https://github.com/sgraham/sqbe.
IMO when the intended usage is AOT with an external assembler, which is another subprocess, text-based IO is actually the more natural approach.
Tangentially: Is there a Rust alternative similar to this?
Why not? Processes are cheaper than you might think. GCC invokes several as an example.
Cool project, and FWIW it's like one Claude prompt to add MIPS support to this. I did that and then was able to compile my little custom language to the N64.
> it's like one Claude prompt to add MIPS support to this
Can you provide the code somewhere? Is it complete? Does it really work? I have a hard time to believe that an LLM really can generate a complete and working backend for a target architecture with "one prompt". From my experience with such tools, by the end of the day it takes longer until it covers all edge cases and actually works than when writing it myself.
The backend is only ~1300 lines. QBE is a super simple project which is why adding a backend to it worked so well. I just pointed Claude at the existing RISC-V backend for reference and it whipped up the MIPS one. It really does work, though there might be bugs I didn't run into. I compiled an Amiga MOD player, written in my language, to the N64 and it worked fine, if that gives you an idea of how stress tested it was. IIRC it runs about 5x slower than GCC-generated code.
https://gist.github.com/SuperDisk/1aa50263a773143c82a39d4771...
Interesting, thanks for posting. I had a first look and think that the AI has messed up with the floating-point and casting instructions (i.e. just copied over the RV instructions). I also spotted other places (e.g. TLS) which look like RV. It's also surprising that the code - as you say - is so much slower than (optimized?) GCC, since QBE is assumed to be at 70-80%.
The page says "aims to provide 70%" though, funny how words spread.
There are reports by independend testers (e.g. https://briancallahan.net/blog/20211010.html or https://news.ycombinator.com/item?id=40350384) suggesting that range.
They absolutely can for simpler cases like this, especially recent GPT 5.x models are amazing at such lower-level compiler work.
Truly amazing times. Just doing things has never been easier, and it has really reinvigorated me.
> I did that
Can you contribute it? I don't see it listed as an official backend.
> Can you contribute it? I don't see it listed as an official backend.
I don't think anyone wants AI generated contribution to QBE (neither do I).
I'm starting to think I should post my prompts if the model one shots it as I don't think the code itself is worth putting out.
As the other commenter said, I don't think contributing it would be that useful, since QBE is a rather zen-garden project and I don't think the author would accept slop. Also he could just generate it with a prompt himself :P
It's certainly fun as a toy though!
Related, there’s Blaise which is a new Object Pascal that uses QBE as its backend.
https://news.ycombinator.com/item?id=48058644
There’s also cproc which has a few HN posts about it.
https://news.ycombinator.com/item?id=24076603 https://news.ycombinator.com/item?id=28242024 https://news.ycombinator.com/item?id=32466098 https://news.ycombinator.com/item?id=25273918
Also relevant: https://git.sr.ht/~mcf/cproc is a C compiler on top of QBE
For 32 bit support there's cparser which is very close to cproc.
IR description here: https://c9x.me/git/qbe.git/tree/doc/il.txt
It looks like it doesn't have native support for identifying GC roots, so it's either conservative GC or explicit stack management. I would really like to see something that is (mostly) memory-safe and has string-as-bytes. It's a bit wild that people use Chez Scheme as a target IR for lack of better options.
Looks like a new 1.3 release is coming very soon.
I love QBE, but it does have its limitations: - It handles the ABIs for passing and returning structures in registers, but only with superfluous copies to and from the stack. - Can't generate debug info for data. This is probably due to lack of assembler support and/or complexity in the DWARF format. - The line number debug info directives are currently undocumented and don't support inlined functions.
But it's smol, effective, and it doesn't make you deal with phi nodes!
Combined with cproc, I get 70% of gcc -O2, for a small fraction of the code... and a plain and simple C coded compiler.
Do you know if there is ongoing work to support x86_64 on Windows?
Yes, windows support already merged to main so it will be in 1.3
A, c9x among codemadness, cool people, among gopher://bitreich.org
https://codemadness.org/git/
Tons of these tools I use are from these guys (among 2f30). Small, predictable, usable, such as pointtools and catpoint. Sfeed for RSS, scc for gopher and so on, and smu for markdown from git repos > html.