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

61–70 of 101 posts

Re: QBE vs. LLVM

#61

Post by ashton314 »

MaxBarraclough wrote: post #16
ashton314 wrote: post #3

I’m going to be building a compiler over Christmas break, and I was thinking of targeting the LLVM toolset. This will be my second compiler; first one emitted x86 directly. Should I consider switching to QBE? I’m more focused on compiler passes that I want to write; register allocation, etc. is not my thing. I’m going to be working with CPS-conversion ans stuff like that. Does anyone have any good tutorials for using…

What was your first compiler?

This little lisp to x86:

https://github.com/ashton314/lambda-x86

New one:

https://github.com/ashton314/christmas-compiler

Re: QBE vs. LLVM

#62

Post by segfaultbuserr »

throw0101a wrote: post #60
segfaultbuserr wrote: post #55

Earlier quoted context omitted.

> It was actually offered to GNU years ago but (if I read the thread correctly) rms didn't get the email because of the unique way he does email. Interesting anecdote. Do you have a source for that?

Perhaps this? * https://gcc.gnu.org/legacy-ml/gcc/2005-11/msg00888.html

Can you elaborate it a bit? I didn't see anything that suggested "rms didn't get the email because of the unique way he does email."

Re: QBE vs. LLVM

#63

Post by ashton314 »

siraben wrote: post #4
ashton314 wrote: post #3

I’m going to be building a compiler over Christmas break, and I was thinking of targeting the LLVM toolset. This will be my second compiler; first one emitted x86 directly. Should I consider switching to QBE? I’m more focused on compiler passes that I want to write; register allocation, etc. is not my thing. I’m going to be working with CPS-conversion ans stuff like that. Does anyone have any good tutorials for using…

Sounds like you want to compile a functional language. The best tutorial (in terms of being self-contained and being understandable in entirety) I've seen to compile FP to C is[0], I'd imagine that retargeting to LLVM wouldn't be that difficult either. [0] https://github.com/jozefg/pcf

This looks great! I’m taking a different approach than this compiler, but this looks like a good resource. Thanks!

Re: QBE vs. LLVM

#64

Post by mhh__ »

segfaultbuserr wrote: post #55
mhh__ wrote: post #17

Earlier quoted context omitted.

LLVM does seem to be explicitly designed from the start to be "industry"-worthy rather than just academic research, though. It was actually offered to GNU years ago but (if I read the thread correctly) rms didn't get the email because of the unique way he does email. It's a shame it's not under the GPL, you can already see a sign of the future (present?) in apple not upstreaming their backends.

> It was actually offered to GNU years ago but (if I read the thread correctly) rms didn't get the email because of the unique way he does email. Interesting anecdote. Do you have a source for that?

I don't, someone linked it to me on here a week ago so I'll try and dig it up.

Apparently rms never saw the email because of his server arrangement?

Re: QBE vs. LLVM

#65

Post by jcranmer »

worldsayshi wrote: post #19
siraben wrote: post #4

Earlier quoted context omitted.

Sounds like you want to compile a functional language. The best tutorial (in terms of being self-contained and being understandable in entirety) I've seen to compile FP to C is[0], I'd imagine that retargeting to LLVM wouldn't be that difficult either. [0] https://github.com/jozefg/pcf

Are there any big downsides to compiling to C instead of LLVM? I would assume that it would be less performant but it feels like a shallow preconception.

> Are there any big downsides to compiling to C instead of LLVM?

Well, for starters, you have to import all of C's undefined behavior, so it would be basically impossible to implement, e.g., 2's complement signed integer arithmetic.

Re: QBE vs. LLVM

#66

Post by FpUser »

bjornjajayaja wrote: post #51
mhh__ wrote: post #30

Earlier quoted context omitted.

Hence why I said it was a sign of the future rather than a prediction. It's not going to get any better for software freedom, especially as we move into the cloud. We live in a post-FSF world, I think people are taking for granted the bean counters playing nice with open source software.

We need software that works on the client side sans internet connection. Devices are really powerful these days so it’s funny things move to the cloud. It’s funny I’ve been using cloud storage for the past several years but I wonder why I don’t just back up to external drive or two. The convenience doesn’t buy much. I think folks really buy into laziness and technology hype. But fundamentally not much had changed in…

This is what I do. All my staff is backed up onto hard drives. I also have offsite server which takes backups from those backups just in case.

Re: QBE vs. LLVM

#67

Post by billconan »

Is it a good idea to use BNF for documentation? This form of document doesn't seem to be very useful for people who want to use the language.

Both WASM and javascript docs do this, and it is also the same here https://c9x.me/compile/doc/il.html

I think LLVM's IR document is not easy to read, this one is not better.

I don't want to reimplement a compiler for the IR language, I want to know how to use it, how to generate code using it. I need to see examples, i.e. how to implement threading, coroutine, weakly typed variables, reflection ... not the BNF.

Re: QBE vs. LLVM

#68

Post by piinbinary »

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

Re: QBE vs. LLVM

#69

Post by vmchale »

mhh__ wrote: post #10
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…

Writing compiler backend in a declarative manner is something I've been toying with for a while now, and I don't think it's realistically possible with current technology. Backends are hard, unfortunately. However, since you are targeting the Z80, you might be able to just take the IR and transform it yourself? I haven't touched an LLVM backend for a while, so I don't know what the process is atm, but if you imagine…

> Writing compiler backend in a declarative manner is something I've been toying with for a while now, and I don't think it's realistically possible with current technology.

Functional style isn't too bad. Maximal munch lines up with pattern matching, then linear scan is easy enough if you don't need gcc-tier results.

GHC has bits of its backend that are shared across architectures, maybe I should have a look at that...

Re: QBE vs. LLVM

#70

Post by jeremyjh »

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…

There are LLVM backed languages that provide garbage collection; Julia and Crystal are the first two that come to mind. Haskell also has an LLVM back-end.
Post reply on HN