Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

QBE – Compiler Back End

c9x.me

Post reply on HN
Print view View original

21–29 of 29 posts

Re: QBE – Compiler Back End

#21

Post by fuhsnn »

Rochus wrote: post #18
superdisk wrote: post #14

Earlier quoted context omitted.

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 wa…

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.

Re: QBE – Compiler Back End

#22

Post by Rochus »

fuhsnn wrote: post #21
Rochus wrote: post #18

Earlier quoted context omitted.

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.

Re: QBE – Compiler Back End

#23

Post by fweimer »

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.

Re: QBE – Compiler Back End

#24

Post by stevefolta »

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!

Re: QBE – Compiler Back End

#27

Post by duped »

lucrbvi wrote: post #6

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.

Why not? Processes are cheaper than you might think. GCC invokes several as an example.

Re: QBE – Compiler Back End

#29

Post by rurban »

duped wrote: post #27
lucrbvi wrote: post #6

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.

Why not? Processes are cheaper than you might think. GCC invokes several as an example.

Because this concept only works for offline compilers, but not for dynamic languages. It's about 100x slower.

I'm just converting the call to an external assembler in my compiler rcc to assemble the bytes directly. No need for strings and external files. The cost of the external call is outrageous.

Post reply on HN