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

31–38 of 38 posts

Re: QBE – Compiler Back End

#31

Post by josephg »

karelpeeters wrote: post #26
Rochus wrote: post #2

QBE is really interesting, but for people like me who still use 32 bit architectures unfortunately a bit limited. Someone recently pointed me to the Eigen compiler kit (see e.g. https://github.com/EigenCompilerSuite/ ) which - like QBE - is a lean alternative to LLVM, but supports much more architectures than QBE, even some 16 bit ones; since last week also Xtensa (ESP32) is officially supported. It's still beyond me…

Out of curiosity, why are you still using 32-bit architectures?

As far as I know, webassembly only supports a 32 bit address space on all platforms at the moment. There’s a memory64 proposal, but it doesn’t look to be widely adopted yet.

Re: QBE – Compiler Back End

#32

Post by bozey07 »

sirwhinesalot wrote: post #27

Any chance of making QBE available as a library? Even something as simple as pass an IR string get the corresponding function would be really nice.

I was disappointed by its architecture too. You must write intermediary files, you must call qbe as a separate binary, and you must write the resultant objects to disk.

If I recall correctly, the author has no interest in re-architecturing qbe like this.

Re: QBE – Compiler Back End

#33

Post by Rochus »

karelpeeters wrote: post #26
Rochus wrote: post #2

QBE is really interesting, but for people like me who still use 32 bit architectures unfortunately a bit limited. Someone recently pointed me to the Eigen compiler kit (see e.g. https://github.com/EigenCompilerSuite/ ) which - like QBE - is a lean alternative to LLVM, but supports much more architectures than QBE, even some 16 bit ones; since last week also Xtensa (ESP32) is officially supported. It's still beyond me…

Out of curiosity, why are you still using 32-bit architectures?

It's good enough for the majority of use cases and systems; even an eight bit MCU is sufficient for many cases. If you design a product, saving power and cost makes the difference.

Re: QBE – Compiler Back End

#34

Post by 95014_refugee »

karelpeeters wrote: post #26
Rochus wrote: post #2

QBE is really interesting, but for people like me who still use 32 bit architectures unfortunately a bit limited. Someone recently pointed me to the Eigen compiler kit (see e.g. https://github.com/EigenCompilerSuite/ ) which - like QBE - is a lean alternative to LLVM, but supports much more architectures than QBE, even some 16 bit ones; since last week also Xtensa (ESP32) is officially supported. It's still beyond me…

Out of curiosity, why are you still using 32-bit architectures?

Memory efficiency just for one. For most programs, and especially in the embedded space, 64b systems carry around (and process) a lot more zeros than 32b systems do. You can still do 64b math when you need it, but you don’t have to pay for it when you don’t.

Given that software is always too big, this can often be a product-making distinction.

Re: QBE – Compiler Back End

#35

Post by IshKebab »

karelpeeters wrote: post #26
Rochus wrote: post #2

QBE is really interesting, but for people like me who still use 32 bit architectures unfortunately a bit limited. Someone recently pointed me to the Eigen compiler kit (see e.g. https://github.com/EigenCompilerSuite/ ) which - like QBE - is a lean alternative to LLVM, but supports much more architectures than QBE, even some 16 bit ones; since last week also Xtensa (ESP32) is officially supported. It's still beyond me…

Out of curiosity, why are you still using 32-bit architectures?

32 bit is still very common for smaller CPUs that aren't in the "application processor" class.

They are cheaper because they use less area, and they're also more memory efficient because pointers are all half as big. On these CPUs you don't have 4GB of RAM so you don't need a big address space.

Re: QBE – Compiler Back End

#36

Post by sirwhinesalot »

bozey07 wrote: post #32
sirwhinesalot wrote: post #27

Any chance of making QBE available as a library? Even something as simple as pass an IR string get the corresponding function would be really nice.

I was disappointed by its architecture too. You must write intermediary files, you must call qbe as a separate binary, and you must write the resultant objects to disk. If I recall correctly, the author has no interest in re-architecturing qbe like this.

That's unfortunate...

Re: QBE – Compiler Back End

#37

Post by zX41ZdbW »

DannyBee wrote: post #9

An intersting idea, but like, if your idea of hackable is dense c code with no comments and short names, it definitely differs from mine! see, e.g,. https://c9x.me/git/qbe.git/tree/ssa.c

Fully agree. Comments are a must. But not like these:

    if (!n) {
        /* uh, oh, warn */
        return UNDEF;

Re: QBE – Compiler Back End

#38

Post by rurban »

Rochus wrote: post #2

QBE is really interesting, but for people like me who still use 32 bit architectures unfortunately a bit limited. Someone recently pointed me to the Eigen compiler kit (see e.g. https://github.com/EigenCompilerSuite/ ) which - like QBE - is a lean alternative to LLVM, but supports much more architectures than QBE, even some 16 bit ones; since last week also Xtensa (ESP32) is officially supported. It's still beyond me…

But much better and faster optimizations than egc
Post reply on HN