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

QBE vs. LLVM

c9x.me

Post reply on HN
Print view View original

71–80 of 101 posts

Re: QBE vs. LLVM

#71

Post by akavel »

throw0101a wrote: post #40
mhh__ wrote: post #29

Earlier quoted context omitted.

That's entirely possible, but does it hurt their bottom line? They switched from GCC, because LLVM was available (to grow and eventually use). Their aversion to the GPL seems mostly cultural, which is interesting given that we skewer microsoft for their sins along those lines 20 years ago now.

Apple has an aversion to GPL 3 and not to GPL 2.x because of what 3 forces people to do. It's the same with FreeBSD: once libgcc_s went to 3 they could no longer use it. It's the same reason why bash and rsync have not been upgraded on macOS to newer versions: they also started using GPL3.

Honestly curious what's the thing that "[GPLv]3 forces people to do" in context of those cases? IANAL but interested in perspective of choosing license for some of my current and future works

Re: QBE vs. LLVM

#72

Post by fefe23 »

I would love to have a way to bootstrap LLVM. This looks promising but I'm guessing a C++ frontend is much more challenging than writing this backend.

gcc used to be the missing link, but they switched to C++ and now you can't bootstrap it with something like tcc.

Re: QBE vs. LLVM

#74

Post by tieze »

siraben wrote: post #7

I wanted to write an LLVM backend for various instruction sets (e.g. Z80, R216[0]), since those would deal with the problems of optimization passes and register allocation for me, but the LLVM tutorial[1] makes it look so goddamn hard. Does anyone know of a tutorial or of a declarative way to write such backends for either QBE or LLVM? The QBE git repository[2] has a few backends but also looks similarly involved. Co…

It's certainly not trivial, but still an interesting journey. I made a backend for MMIX, heavily influenced by the risc-v implementation, and kept the patches logically consistent by rebasing new changes to serve as an example. The last rebase was a year ago, but I think following a previous implementation is the best way forward as there is so much boiler-plate: - https://github.com/stuij/mmix-llvm-support - https://github.com/stuij/mmix-llvm-backend

That said, those kind of olden CPU's aren't a terribly snug fit for LLVM, due to their peculiarities. You'll have to bend LLVM quite a bit to bend it to your will, which also means that you need to get quite familiar with it as well.

edit: this tutorial is even older still, but for me it was one of the best resources, next to checking other simple backends: https://jonathan2251.github.io/lbd/llvmstructure.html

Re: QBE vs. LLVM

#75

Post by UncleOxidant »

pjmlp wrote: post #11

Also to note, LLVM isn't the first compiler toolchain of its kind. Notable mentions, IBM's research project on PL.8 while developing their first RISC designs. https://rsim.cs.uiuc.edu/arch/qual_papers/compilers/auslande... https://pdfs.semanticscholar.org/3288/fc042cd474f0ec93d67753... https://rishiheerasing.net/modules/hca2102/paper/cocke.pdf The Amsterdam Compiler Toolkit, http://tack.sourceforge.net/ https://githu…

Also the Rose Compiler infrastructure: http://rosecompiler.org/

Though it's more for source transformation and analysis.

Re: QBE vs. LLVM

#76

Post by biryani_chicken »

piinbinary wrote: post #68

I wish something like this existed for garbage-collected languages. The closest thing I know of is the JVM (and other similar VMs), but I'm hoping for ahead-of-time compilation. The key difficulty in adding garbage collection to code emitted with tools like this is being able to accurately tell what the root set is. (I know LLVM has support for this in theory, but I have found nothing that tells how to actually use i…

Something like the CIL[0]? I know there was a python and a ruby implementation on top of it.

[0] https://en.wikipedia.org/wiki/Common_Intermediate_Language

Re: QBE vs. LLVM

#77

Post by erlend_sh »

piinbinary wrote: post #68

I wish something like this existed for garbage-collected languages. The closest thing I know of is the JVM (and other similar VMs), but I'm hoping for ahead-of-time compilation. The key difficulty in adding garbage collection to code emitted with tools like this is being able to accurately tell what the root set is. (I know LLVM has support for this in theory, but I have found nothing that tells how to actually use i…

The Mu Micro Virtual Machine might interest you: https://news.ycombinator.com/item?id=25278568

Re: QBE vs. LLVM

#78

Post by badsectoracula »

akavel wrote: post #71
throw0101a wrote: post #40

Earlier quoted context omitted.

Apple has an aversion to GPL 3 and not to GPL 2.x because of what 3 forces people to do. It's the same with FreeBSD: once libgcc_s went to 3 they could no longer use it. It's the same reason why bash and rsync have not been upgraded on macOS to newer versions: they also started using GPL3.

Honestly curious what's the thing that "[GPLv]3 forces people to do" in context of those cases? IANAL but interested in perspective of choosing license for some of my current and future works

Not lock down people's devices basically. [L]GPLv3 requires that people are able to replace the [L]GPLv3'd binaries in their own devices if they want to (so they actually take advantage of the code being FLOSS instead of some nice theoretical novelty - ie. it is nice that my router uses Linux and find it amusing that it comes with the GPLv2 printed out, but what is the point if i can't open it up and fix/change some things that annoy me?). Apple wants to keep the devices they sell you under tight control, so [L]GPLv3 rubs them wrong.

And so they avoid it.

Related: https://en.wikipedia.org/wiki/Tivoization

It might also be about patents since IIRC [L]GPLv3 requires that if you use a [L]GPLv3'd program and that program infringes some of your patents then you are not allowed to sue others over their use of your patents in the same program.

Re: QBE vs. LLVM

#79

Post by csharptwdec19 »

biryani_chicken wrote: post #76
piinbinary wrote: post #68

I wish something like this existed for garbage-collected languages. The closest thing I know of is the JVM (and other similar VMs), but I'm hoping for ahead-of-time compilation. The key difficulty in adding garbage collection to code emitted with tools like this is being able to accurately tell what the root set is. (I know LLVM has support for this in theory, but I have found nothing that tells how to actually use i…

Something like the CIL[0]? I know there was a python and a ruby implementation on top of it. [0] https://en.wikipedia.org/wiki/Common_Intermediate_Language

That's about viable nowadays.

Elaborating: Until recently, your best option for running CIL in an AOT type environment would be Mono AOT, which has it's own limitations.

Nowadays, however, we do have CoreRT in a state that lets you do AOT, still with limitations around things like reflection. But, it's fairly doable nowadays, I would think.

Re: QBE vs. LLVM

#80

Post by mech422 »

pjmlp wrote: post #11

Also to note, LLVM isn't the first compiler toolchain of its kind. Notable mentions, IBM's research project on PL.8 while developing their first RISC designs. https://rsim.cs.uiuc.edu/arch/qual_papers/compilers/auslande... https://pdfs.semanticscholar.org/3288/fc042cd474f0ec93d67753... https://rishiheerasing.net/modules/hca2102/paper/cocke.pdf The Amsterdam Compiler Toolkit, http://tack.sourceforge.net/ https://githu…

No one mentioned the Purdue Compiler Construction kit yet? Weren't they and the Amsterdam compiler kit the 2 'big ones' back in the day ?
Post reply on HN