Here is an earlier incarnation of the "writing a compiler" thread:
Learning to write a compiler
11–20 of 42 posts
Re: Learning to write a compiler
#12I'm upvoting this just to hopefully start a discussion and hear more about this topic from fellow HNers. I hear the Dragon Book mentioned almost daily around here; I'm intrigued. Do you think this book could be read by someone who's not actually interested in writing a compiler? Does the book stand by itself? I'm interested in reading it, but I don't really think I have the motivation to start writing my own compiler…
When did reading books become a purely utilitarian thing? Interested in reading it? Read it. It's a good book. You don't have to do the exercises.
Re: Learning to write a compiler
#13Here is an earlier incarnation of the "writing a compiler" thread: http://news.ycombinator.com/item?id=1608129
Oops, I downvoted you when I meant to upvote. There is probably another incarnation or three before the one you linked, too.
I'd recommend Appel's "Modern Compiler Implementation in ML" over the dragon book.
Re: Learning to write a compiler
#14The interesting thing about compiler writing is the drastic reduction in complexity that's happened. There are essentially off-the-shelf tools that can be used to handle everything before semantic analysis and everything after conversion to a reasonably high-level IR. This has dramatically reduced the cost of language experimentation; it's now feasible to bang out a new language in a day or two (assuming you're famil…
I think that combining this short compiler tutorial with LLVM would be a very effective way for someone to get comfortable with basic compiler writing:
http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf
Afterward, learning how to do lexing and parsing would be a good addition. The tutorial covers a subset of scheme, which is trivially simple to parse, especially if you're writing the compiler in scheme as well.
Re: Learning to write a compiler
#15I'm upvoting this just to hopefully start a discussion and hear more about this topic from fellow HNers. I hear the Dragon Book mentioned almost daily around here; I'm intrigued. Do you think this book could be read by someone who's not actually interested in writing a compiler? Does the book stand by itself? I'm interested in reading it, but I don't really think I have the motivation to start writing my own compiler…
DO NOT READ THE DRAGON BOOK.
It's not a very good introduction to compilers. Read Engineering a Compiler by Cooper and Torczon. The Appel book is also very good, and contains some stuff about functional and logic languages that are generally missing from most compiler texts. If you're an enthusiast, but not in it to build a compiler, I really enjoy Programming Language Pragmatics. For more advanced material, use the Muchnick book, or the Compiler Design Handbook (both editions have different materials). They also provide excellent pointers to literature, but aren't great for beginners.
I get the impression that most people who recommend the Dragon book haven't read it. When I was doing my PhD I had five or six books on my shelf, and was constantly unimpressed with the Dragon Book, but always impressed with Cooper/Torczon, Muchnick and Appel.
Re: Learning to write a compiler
#16Earlier quoted context omitted.
Do you want to build a compiler or design a programming language? The Dragon Book is pretty heavy on implementation details if you just want a taste without building one. If you're just getting started in mechanical program transformation, I strongly recommend using something like Structure and Interpretation of Computer Programs and its meta-circular evaluator to get the basics without the grunge of parsing and gene…
It is possible to skip the first half of the Dragon Book if you are not interested in front-end stuff. (I am not.) Chapters 8 and onward are far more interesting IMO. You will encounters topics such as SSA, data-flow analysis, points-to analysis, binary-decision diagrams, call graphs, Datalog, etc.
Meh. It's SSA treatment is poor. The dataflow chapter is OK. The points-to chapter isn't great (especially for someone so into it). BDDs and datalog are very poorly addressed, especially when trying to seek more information of Lam/Whaley's work on them.
Skip the whole Dragon Book, read Cooper/Torczon or Appel.
Re: Learning to write a compiler
#17I'm upvoting this just to hopefully start a discussion and hear more about this topic from fellow HNers. I hear the Dragon Book mentioned almost daily around here; I'm intrigued. Do you think this book could be read by someone who's not actually interested in writing a compiler? Does the book stand by itself? I'm interested in reading it, but I don't really think I have the motivation to start writing my own compiler…
DO NOT READ THE DRAGON BOOK. It's not a very good introduction to compilers. Read Engineering a Compiler by Cooper and Torczon. The Appel book is also very good, and contains some stuff about functional and logic languages that are generally missing from most compiler texts. If you're an enthusiast, but not in it to build a compiler, I really enjoy Programming Language Pragmatics. For more advanced material, use the…
Couldn't agree more, I hack on compilers a fair bit (one of my own, plus the JITs in PyPy and Unladen Swallow) and the Dragon Book was impossible for me to get anything out of.
Re: Learning to write a compiler
#18I'm upvoting this just to hopefully start a discussion and hear more about this topic from fellow HNers. I hear the Dragon Book mentioned almost daily around here; I'm intrigued. Do you think this book could be read by someone who's not actually interested in writing a compiler? Does the book stand by itself? I'm interested in reading it, but I don't really think I have the motivation to start writing my own compiler…
The Dragon Book is quite readable. The best approach is to read each chapter by itself rather than going from beginning to end. If there's a topic interested you, jump to that chapter. You can jump to the regular expression chapter, which can be read by itself, jump to the code generation and program layout, or jump to the optimization chapter, which can be read by itself. The lex and parser topics sort of go together.
Re: Learning to write a compiler
#19Earlier quoted context omitted.
It is possible to skip the first half of the Dragon Book if you are not interested in front-end stuff. (I am not.) Chapters 8 and onward are far more interesting IMO. You will encounters topics such as SSA, data-flow analysis, points-to analysis, binary-decision diagrams, call graphs, Datalog, etc.
Meh. It's SSA treatment is poor. The dataflow chapter is OK. The points-to chapter isn't great (especially for someone so into it). BDDs and datalog are very poorly addressed, especially when trying to seek more information of Lam/Whaley's work on them. Skip the whole Dragon Book, read Cooper/Torczon or Appel.
I agree that its treatment of SSA is scanty. Muchnick, which I have started poking at, is much more thorough: The Dragon Book does go into what SSA is, but it does not tell you how to compute it while Muchnick does. However, I imagine it must have been a deliberate decision since Ullman et al. go into dominance frontiers quite readily shortly thereafter.
I admit that I skipped over the book's treatment of points-to analysis since I read the original papers by Lam and Whaley on it. Obviously, I can't speak for its treatment in the book, but I found the papers to be excellent. And indeed, one of them won a Best Paper award.
Re: Learning to write a compiler
#20Earlier quoted context omitted.
DO NOT READ THE DRAGON BOOK. It's not a very good introduction to compilers. Read Engineering a Compiler by Cooper and Torczon. The Appel book is also very good, and contains some stuff about functional and logic languages that are generally missing from most compiler texts. If you're an enthusiast, but not in it to build a compiler, I really enjoy Programming Language Pragmatics. For more advanced material, use the…
Couldn't agree more, I hack on compilers a fair bit (one of my own, plus the JITs in PyPy and Unladen Swallow) and the Dragon Book was impossible for me to get anything out of.
IMO, the format of this book makes sense for the context it was intended for: Stanford's course on optimizations and program analysis, where the problem sets and reading provide theoretical knowledge and the projects -- hacking on the joeq VM/compiler-infrastructure -- provide implementation experience. These distinct experiences make for a well-rounded education in advanced compiling techniques. (Disclaimer: I have not taken this course and am basing these comments on a quick look at their course Web page.)
So reading the Dragon Book is more akin to reading mathematics than reading a handbook on compiler implementation. Its treatment of data-flow analysis is another example of this: While the Dragon Book gives top-notch treatment of the mathematical underpinnings of data-flow analysis (semi-lattices, partial orderings, monotonicity, greatest lower-bounds, etc.), it does not go into how to implement an efficient worklist algorithm; it does not even mention du-chains AFAICT. At most, it suggests using a bit-set to represent the reaching definitions that enter and exit a basic block.
So I too am in agreement. But maybe this is what you want, mapleoin. If you just want to know what a reaching def is or how compiler writers know that their data-flow analysis is going to terminate, this is a book that will not bog you down with too many implementation details.