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

QBE – Compiler Backend – 1.3

c9x.me

Post reply on HN
Print view View original

11–20 of 39 posts

Re: QBE – Compiler Backend – 1.3

#11

Post by IshKebab »

supergarfield wrote: post #2

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

Re: QBE – Compiler Backend – 1.3

#13

Post by orthoxerox »

supergarfield wrote: post #2

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.

Re: QBE – Compiler Backend – 1.3

#14

Post by peterfirefly »

supergarfield wrote: post #2

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)

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.

Re: QBE – Compiler Backend – 1.3

#15

Post by torginus »

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.

Re: QBE – Compiler Backend – 1.3

#16

Post by torginus »

dismalaf wrote: post #10
r2ob wrote: post #6

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.

Re: QBE – Compiler Backend – 1.3

#17

Post by peterfirefly »

torginus wrote: post #16
dismalaf wrote: post #10

Earlier quoted context omitted.

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.

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.

Re: QBE – Compiler Backend – 1.3

#18

Post by avadodin »

packetlost wrote: post #9
Imustaskforhelp wrote: post #4

Earlier quoted context omitted.

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.

Re: QBE – Compiler Backend – 1.3

#20

Post by torginus »

luikore wrote: post #19

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.

Post reply on HN