Live data from Hacker News

QBE – Compiler Backend – 1.3

c9x.me

31–39 of 39 posts

Re: QBE – Compiler Backend – 1.3

#31

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.

It is not libc based.

Re: QBE – Compiler Backend – 1.3

#32

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…

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.

Re: QBE – Compiler Backend – 1.3

#33

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.

It is not libc based.

Isn't libc mandatory on OpenBSD?

Re: QBE – Compiler Backend – 1.3

#34

Earlier quoted context omitted.

It is not libc based.

Isn't libc mandatory on OpenBSD?

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.

Re: QBE – Compiler Backend – 1.3

#35

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.

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.

Re: QBE – Compiler Backend – 1.3

#38

Earlier quoted context omitted.

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

I’m hopeful for Blaise.

Re: QBE – Compiler Backend – 1.3

#39

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)

Bitdiddler style, he thinks he's smart for making his code convoluted and unreadable.
Post reply on HN