QBE vs. LLVM
91–100 of 101 posts
Re: QBE vs. LLVM
#92I 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.
GNU GUIX works on the boostraping issue, they strive to reduce the seed size as much as possible: https://guix.gnu.org/blog/tags/bootstrapping/
Re: QBE vs. LLVM
#93Doesn't allowing non-SSA forms like %v =w add %v, 1. defeat the purpose of using SSA in the first place? If this form is allowed, then I can not rely on `%v` having an immutable value which is much of the reason why we use SSA in the first place.
Re: QBE vs. LLVM
#94Earlier quoted context omitted.
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."
probably based on this: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00... I don't understand the bits about RMS' email configuration, but in that message in 2015 he indicated that he did not know about the offer in 2005 to give copyright of LLVM to the FSF.
Re: QBE vs. LLVM
#95Earlier quoted context omitted.
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…
See also "Why is FreeBSD deprecating GCC in favor of Clang/LLVM?": * https://unix.stackexchange.com/questions/49906/why-is-freebs... GPL3 is more restrictive than GPL2, which in turn is more restrictive than BSD/MIT, in the name of allowing other freedoms for end-users.
Re: QBE vs. LLVM
#96I’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…
LLVM is much better documented than any other compiler system, so I would just KISS and use it. LLVM is a beast, though, but to get started I'd want to focus on the my side of the compiler first (the sema is where the pain is imo) Remember that there's no reason why you can't have an IR in between your language and the backend. If your language fits, (based on the CPS it probably won't but still) you can use a subset…
LLVM is not KISS. Very, very far from it.
Re: QBE vs. LLVM
#97I’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…
I have done the latter, and would advise against it. The IR is powerful, but quite involved. The documentation is sometimes lacking. It's an interesting project, but you probably won't get far.
Linking against LLVM means you have to use their C++ interface, and every time you rebuild your compiler, it's going to be slow, with all the templates they use. Your compiler will be a large executable (clang and zig are about 90 MB), and you'd have to rebuild that every time you change your compiler. I would hate having to do that in my spare time, which is why I went the other route.
LLVM is very powerful. There's all these optimizations you get, and debug info. But it's not free. The integration is going to be hard and you'll have to spend quite some time on it.
The next time I would start a language project I would build an interpreter in a dynamic language, and possibly even use a parser generator. https://craftinginterpreters.com/ has a nice path laid out. Focus on what you actually want to do. Once you get somewhere, once you actually like your language, once you actually start a project in your own language, and have an actual need for more, you can write another compiler with more bells and whistles.
Re: QBE vs. LLVM
#98I 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…
Re: QBE vs. LLVM
#99and
> it is programmed in non-fancy C99 without any dependencies.
These are contradictions. C99 is not a "very hackable" language. If the compiler isn't designed to make fast binaries then they should have written it in a higher level language that has less foot guns.
Re: QBE vs. LLVM
#100I 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…
I thought this wasn't universally available (that it was only in a special version of the JDK - https://openjdk.java.net/projects/graal/). But it appears to be everywhere, albeit experimentally.