Tell HN: The dragon compiler book (2nd edition) is a great book
I have seen a lot of people on the internet say that the dragon book is horrible book to learn compilers from.
well, I have read some of the second edition of the dragon book and I think it is a great book. The main criticism is that its too focused on parsing. Thats just like 5 chapters. I skipped these and went straight into the intermediate language, code generation, and optimizing chapters.
These chapters give a detailed account of things such as register allocation, instruction selection, and instruction scheduling. The optimizing chapters are also good.
im not claiming im an expert compiler person. I am not but compilers is something i want to learn and so i gave the dragon book a try and i really liked it.
more importantly the dragon book made me realize that compilers are mathematical systems in a way. the ast is tree and trees have mathematical properties but graphs are needed for register allocation, dataflow analysis for optimization. optimization is math problem.
So i think this book gave me a better understanding of the field and it made appreciate compilers.
i'd say if youre interested in compilers you can start with "essence of compilation" by dr. siek and get some experience writing compilers and then read the dragon book.
i just wanted to share my experience. i think the dragon book is a great book.
47 comments
[ 3.3 ms ] story [ 98.9 ms ] threadso a lot of people say a lot of things. i like chapters 1-5 just as much as the rest, btw. it's objectively a great book, written by objectively great developers and computer scientists.
is it the best to learn from today? who can say.
you might also say we should not start the education for structural engineering by studying the Brooklyn bridge either.
but, so here we are.
What else should I study besides the first 5 chapters of the 2nd edition of the dragon book?
Though mind you, not everyone shares my sentiment here, last time I wrote that people were adamant about hand-written parsers.
I've had good experiences using parser combinator libraries. They are straight-forward to use, and to write, and expressive. Beyond that, it's seeing how to breakdown a parsing problem into a grammar that I think is the main skill.
But the average programmer should just use a CSV parser lib, why reinvent the wheel? For custom tasks learning about ANTLR is much more productive (a good parser generator)
But you are probably not a compiler practitioner. Then I agree it is a good book to learn about compilers.
https://www.cs.princeton.edu/~appel/modern/
In fact SSA makes no constraints on the number of operands in an instruction/operation what so ever.
```
p = a + b
q = p-c
p = q * d
```
Ssa:
```
p1 = a+ b
q1= p1 - c
p2 = q1 * d
```
Given the above examples how is it not straightforward to use ssa instead of three address code using what the dragon book teaches? What is wrong with the above examples?
In fact section 6.2.4 in the dragon book it says:
“Two distinctive aspects distinguish SSA from three-address code. The first is that all assignments in SSA are to variables with distinct names; hence the term static single-assigment.” The second one is that ssa uses a function to combine two definitions
On the other hand, if you write your analyses and transformations with SSA form as a precondition, you can reduce complexity because SSA form is referentially transparent, giving you a lot of things like use-def chains, dead code analysis, etc for more or less free.
This is what people mean when they say that SSA is essential for modern compiler construction. That quote from the book is reductionist to the maximum possible extent and put's it in the direct comparison with 3AC, to which it only has the relation that both are transformations of IR instructions the result of both have nothing in common.
The example is misleading because it displays the SSA IR also in 3AC - which is unnecessary - and it completely omits PHIs without which SSA properties simply do not hold and for which no 3AC correlation exists at all - they are not representable. In fact, control flow can easily be built such that a PHI has any amount of operands - e.g. a switch which might need significant additional code transformation to be representable as 3AC.
Perhaps you work on llvm or something professionally?
But yeah if you can please provide support for your view. Thanks
You should probably start on the Wikipedia page for SSA, which - since the dragon book doesn't teach what SSA actually is, is a reasonable starting point https://en.m.wikipedia.org/wiki/Static_single-assignment_for... Note that even though it provides many examples and other comparisons it not once mentions 3AC (and vice versa actually). Under Benefits you can find links to various optimizations some of whose pages reference what SSA helps with. None of them have much if anything to do with 3AC.
That the CMU simply copies an example straight from the book and provides no further explanation and maybe even doesn't mention PHIs (?) doesn't speak for that course at all. Especially if you take a look at the list of compilers that do use SSA on Wikipedia and note that pretty much all major programming language implementations use SSA.
Of course you can lower an AST to SSA that looks like the example (except the example is so rudimentary it's still missing the very necessary PHI functions) and you can even make it have 3AC form and still exploit the SSA properties in optimizations. It's just that the properties and the SSA form still have no real relation except that both modify your list of instructions and claiming that there's one that's somehow meaningful or that 3AC gives you anything that SSA does is at best grossly misleading by a textbook.
Since it's so old that blog post is dead now, here is an archive copy: https://web.archive.org/web/20180929002914/http://www.billth...
Just some clarification, it is not difficult to understand but difficult to build from scratch. I'm thinking maybe a book that asks me to build up BNF expressions for a series of grammars of gradually increasing complexity would be nice.
Came across it on HN but I have not read it though.
This [1] is a great tutorial to start with. Personally, I followed up with a standards compliant JSON parser of my own, in Python [2], and later ported it into a larger golang codebase. Practically building up multiple JSON parsers taught me to build my own DSL, using recursive descent parsing. My path admittedly is quite non-standard and idiosyncratic, but was way more fun than going through a textbook :)
[1]: https://www.booleanworld.com/building-recursive-descent-pars...
[2]: https://github.com/HexmosTech/json-rd
Sorry, title took me down a nostalgic trip.
List please?