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

11–20 of 38 posts

Re: QBE – Compiler Back End

#11

Post by Rochus »

snvzz wrote: post #8
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…

Although unfortunately not open source proper, vbcc[0][1] is interesting. 0. http://www.compilers.de/vbcc.html 1. https://en.wikipedia.org/wiki/Vbcc

QBE (and Eigen) are compiler kits, i.e. useful if you implement your own compiler. There are a lot of open-source C compilers already available for nearly any architecture.

Re: QBE – Compiler Back End

#12

Post by snvzz »

Rochus wrote: post #10
snvzz wrote: post #7

Earlier quoted context omitted.

>Personally I consider ESP32 Sure you don't mean Tensilica i.e. legacy ESP32? Espressif has notably switched to RISC-V.

> Espressif has notably switched to RISC-V Not really switched; they offer ESP32 models with (so far) single-core RISC-V; I don't think they planned to stop selling the original ESP32 designs (they wouldn't do themselves a favour).

>Not really switched

Yes very much switched. Thoroughly[0].

While obviously only for new chips, years have already passed, and many new chips have been released. Tensilica are now only present in a minority of their offerings.

>I don't think they planned to stop selling the original ESP32 designs

In this market, having long term availability is important.

0. https://riscv.or.jp/en/2021/02/latest-esp32-includes-risc-v/

Re: QBE – Compiler Back End

#13

Post by snvzz »

Rochus wrote: post #11
snvzz wrote: post #8

Earlier quoted context omitted.

Although unfortunately not open source proper, vbcc[0][1] is interesting. 0. http://www.compilers.de/vbcc.html 1. https://en.wikipedia.org/wiki/Vbcc

QBE (and Eigen) are compiler kits, i.e. useful if you implement your own compiler. There are a lot of open-source C compilers already available for nearly any architecture.

Fair. But note that while not a "compiler kit", VBCC has front/backend separation. This is why I mentioned it.

Of course, as it isn't open source, third party backends/frontends are unlikely to occur.

Fortunately, despite not open source, the code and documentation can still be studied.

Re: QBE – Compiler Back End

#14

Post by Rochus »

snvzz wrote: post #12
Rochus wrote: post #10

Earlier quoted context omitted.

> Espressif has notably switched to RISC-V Not really switched; they offer ESP32 models with (so far) single-core RISC-V; I don't think they planned to stop selling the original ESP32 designs (they wouldn't do themselves a favour).

>Not really switched Yes very much switched. Thoroughly[0]. While obviously only for new chips, years have already passed, and many new chips have been released. Tensilica are now only present in a minority of their offerings. >I don't think they planned to stop selling the original ESP32 designs In this market, having long term availability is important. 0. https://riscv.or.jp/en/2021/02/latest-esp32-includes-risc-v…

> While obviously only for new chips, years have already passed

Well, in 2022 they upgraded to the L7 cores.

> having long term availability is important

So they will obviously continue to produce the tensilica models (which they wouldn't if they really "switched"); that's all I (and many other developers) need.

Re: QBE – Compiler Back End

#15

Post by bjconlan »

sylware wrote: post #6

Did a port of busybox bzip2 compression code to plain and simple C99, and cproc/qbe gives me 70-80% of gcc (13.2.0) speed on amd zen2 (tinycc generated machine code is 2 times slower than gcc, but it is really simple and clean assembly code... so it will have its use cases...). Namely, the combo of cproc/qbe + custom assembly would be the perfect toolchain for a lean open source stack with more than decent performanc…

Wow thank you for these back of the envelope benchmarks. I wanted to "feel out" the practicality of using tinycc with cosmopolitan over the provided gcc implementation (mostly as a fun project to re-educate myself with c and assembly) but now I think I might be better off just using the provided toolset and "building something useful" (aka now I want to get lost in how the strace/xed/dynamic assembly stuff works in cosmopolitan as it's my current favorite discovered dark art while looking through its codebase)

Re: QBE – Compiler Back End

#16

Post by userbinator »

Pronounced 'kyubey'?

Split spiller and register allocator thanks to SSA form. (Simpler and faster than graph coloring.)

IMHO the fixation on graph colouring really held back the development of compilers. SSA was known in the late 80s but for some reason everyone thought graph colouring was the Right Way To Do It, and it only took until the turn of the century for that sentiment to change.

Re: QBE – Compiler Back End

#17

Post by frozenport »

userbinator wrote: post #16

Pronounced 'kyubey'? Split spiller and register allocator thanks to SSA form. (Simpler and faster than graph coloring.) IMHO the fixation on graph colouring really held back the development of compilers. SSA was known in the late 80s but for some reason everyone thought graph colouring was the Right Way To Do It, and it only took until the turn of the century for that sentiment to change.

easier to color graph if you have like 4 registers :-)

Re: QBE – Compiler Back End

#18

Post by rpearl »

userbinator wrote: post #16

Pronounced 'kyubey'? Split spiller and register allocator thanks to SSA form. (Simpler and faster than graph coloring.) IMHO the fixation on graph colouring really held back the development of compilers. SSA was known in the late 80s but for some reason everyone thought graph colouring was the Right Way To Do It, and it only took until the turn of the century for that sentiment to change.

SSA is more of a control flow representation and is broadly orthogonal to register allocation--you can use graph coloring to allocate registers in SSA and you can do linear scan forms of allocation without SSA.

Re: QBE – Compiler Back End

#20

Post by chc4 »

userbinator wrote: post #16

Pronounced 'kyubey'? Split spiller and register allocator thanks to SSA form. (Simpler and faster than graph coloring.) IMHO the fixation on graph colouring really held back the development of compilers. SSA was known in the late 80s but for some reason everyone thought graph colouring was the Right Way To Do It, and it only took until the turn of the century for that sentiment to change.

You can (and people do) do graph coloring on SSA form, just the same as you can do linear scan without SSA. SSA helps graph coloring, in fact, thanks to the discovery that the interference graph of SSA values is chordal and the consequences of that...which was only discovered in 2005.
Post reply on HN