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

21–30 of 39 posts

Re: QBE – Compiler Backend – 1.3

#21

Post by torginus »

avadodin wrote: post #18
packetlost wrote: post #9

Earlier quoted context omitted.

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.

Re: QBE – Compiler Backend – 1.3

#22

Post by [deleted] »

torginus wrote: post #15

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…

[deleted]

Re: QBE – Compiler Backend – 1.3

#23

Post by s3graham »

orthoxerox wrote: post #13
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.

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.

Re: QBE – Compiler Backend – 1.3

#25

Post by s3graham »

torginus wrote: post #15

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…

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.

Re: QBE – Compiler Backend – 1.3

#26

Post by avadodin »

torginus wrote: post #21
avadodin wrote: post #18

Earlier quoted context omitted.

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.

Re: QBE – Compiler Backend – 1.3

#27

Post by s3graham »

luikore wrote: post #19

Nearly ideal. The only stopper for me is missing a way to add source level debugging info.

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

Re: QBE – Compiler Backend – 1.3

#28

Post by throwaway81523 »

dang wrote: post #5

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

Those are related but the current link is about a new release that dropped yesterday (June 1 2026).

Re: QBE – Compiler Backend – 1.3

#29

Post by kreelman »

klardotsh wrote: post #3

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…

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.

Re: QBE – Compiler Backend – 1.3

#30

Post by mhd »

torginus wrote: post #15

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…

> I love that there are compilers beside the big 2

Whatever happened to Tendra?

Post reply on HN