Hacker News new | past | comments | ask | show | jobs | submit login

This is definitely a backend, machine code focused list. If you're writing a compiler to WebAssembly or even the JVM you're probably not gonna need a lot of these resources.

Indeed I'd argue that these lists are more for an intermediate compiler writer. Beginner compiler writers don't need to know register allocation. They need to understand how to think about language translation, how to write an intermediate representation, how to learn a target language.

I've been toying with the idea of writing a post that goes through the thought process of translation. Specifically, how you build states, and invariants. When I write code generation I spend time thinking about the different states the stack could be in, or what invariant I need to keep across this expression (do I need to save a register or global?).

One simple but important example of this is realizing that given a proper, sound type checker, your code generator should almost never give errors. By the time you reach code generation you should have proven enough invariants that code generation cannot fail. This isn't always true but I've found it to be the case.




> Indeed I'd argue that these lists are more for an intermediate compiler writer. Beginner compiler writers don't need to know register allocation.

I'm not disagreeing with you, but note that the title does not say it's for beginners, it says it's for amateurs, which is just anyone who does it for fun rather than money.


That reminds me of the dragon book that goes heavily into VAX assembly and optimizing for CISC machines. Probably not the best resource for beginners or amateurs these days, but it won a Turing award at least.

The problem is what it means to write a compiler is pretty broad, some amateur projects focus on backend work, some on front end, many in between.


Also tremendous amounts just on parsing C. I found Lisp In Small Pieces far more interesting.


The Dragon Book is just not very good. The newer editions spend far too long on parsing, which is not a big problem, and just make it look scary.

Grune's Parsing Techniques is a good book (IIRC when I read it ten years ago), and there are some other ones here.

https://gcc.gnu.org/wiki/ListOfCompilerBooks


> Beginner compiler writers don't need to know register allocation. They need to understand how to think about language translation, how to write an intermediate representation, how to learn a target language.

I don't think people that want to write a compiler want to end up with helloworld.c instead of helloword.exe. At least I don't.


At least for me, compiling to a simpler target made learning the ideas easier. Compiling to to raw assembly does give you more nerd credit but it also makes it harder to get started.


The opposite, really. I started learning about compilers because I wanted to implement my own syntactic ideas. Don't care at all how it runs.


That's what interpreters are great for.


Ideally, you'd emit LLVM IR or some similar bytecode or assembly. Then you'd use llc/opt or an appropriate assmebler to get an executable.

Trying to emit machine code isn't too interesting when you're writing your first compiler.


Similarly, trying to parse C++ isn't too interesting when you're writing your first backend.


The creator of C++ would disagree, as C++ was devised as a compile-to-c language.


You can certain take any path into compiler writing. I dont know anything about AST or front end compilers but ended up writing register allocators and constant folding for nvidia GPU JIT


I would be interested in reading your yet-to-be-written post!


That would be great to read, I sincerely hope you write it, post it here, and I get to read it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: