3 ms·

Basics of Compiler Design [pdf]

47 points by lapenne 17y ago

deleted 17y ago
[deleted]
friism 17y ago
I was taught by this book while at DIKU. It's pretty 'dry' with its LaTex typesetting and all, but thorough and pretty comprehensive within the scope.
rlm 17y ago
I've read it as a part of the introductory compiler course at DIKU (Computer Science dept. of University of Copenhagen). It's good for exactly what the title says: Basics of Compiler Design. It won't make you a compiler guru, but it will give you a good grasp of the fundamentals. If anyone is interested, I could share the weekly assignments and the exam project from the course. The advanced compiler course at DIKU uses Modern Compiler Implementation in ML: http://www.cs.princeton.edu/~appel/modern/ml/ http://www.cs.princeton.edu/~appel/modern/ml/.
Simucal 17y ago
In his first section he describes a compiler as something that turns high-level code into machine code. This isn't necessarily true is it? A compiler is something that takes code in one language and converts it to another. It can be a Python to Javascript compiler, or a C to x86 Assembly Compiler (which can then be assembled using an appropriate assembler). I'm reading both Louden's "Compiler Construction: Principles and Practice" and the Dragon Book. They are both good so far.
- wlievens 17y ago
  The thing is, if you make the definition too generic, everything turns out to be a compiler. For instance, Photoshop is a compiler that turns commands in the UI (the input language) into PSD files (the output language). It's a lot harder to define terms like "compiler" than it actually seems.
  - eru 17y ago
    And you have to differentiate your definition for 'compiler' from 'interpreter'. And point out, that those two sit on opposite ends of the same spectrum.
    - wlievens 17y ago
      Even that is a fuzzy barrier. You have lots of languages that have the compiler built-in to the runtime environment (Smalltalk, and I guess most lisps?). Anything with JIT blurrs the line, too.
      - eru 17y ago
        Yes, that's what I was trying to say by mentioning a "spectrum". Threaded interpreters are also closer to compilers than most.
Bjoern 17y ago
I can only recommend the "Dragon Book". Its old but really a great intro into Compilers. I had the benefit of working with it must say I didn't find anything better so far. Compilers: Principles, Techniques, and Tools by Alfred V. Aho (Author), Ravi Sethi (Author), Jeffrey D. Ullman (Author) http://www.amazon.com/Compilers-Principles-Techniques-Alfred-Aho/dp/0201100886 http://www.amazon.com/Compilers-Principles-Techniques-Alfred...
- eru 17y ago
  I found the Dragon Book quite dull, and old fashioned. "Implementing Functional Programming Languages" [1] by Simon Peyton-Jones makes a much more interesting read. Edit: I guess, we are talking about different Dragon Books. Wikipedia lists [2] at least three. And says about the first: "Principles of Compiler Design is now rather dated [...]." [1] http://research.microsoft.com/en-us/um/people/simonpj/papers/slpj-book-1987/ http://research.microsoft.com/en-us/um/people/simonpj/papers... [2] http://en.wikipedia.org/wiki/Dragon_Book http://en.wikipedia.org/wiki/Dragon_Book
10ren 17y ago
Just browsing the contents on parsing (what I"m working on), it seems little different from the Dragon book. Has the simplest way to construct a parser really not improved after all these years? What about the LL(*) class of parsers that ANTLR uses, and packrat parsers (I don't use these, have just heard about them). Or has "parsing" become a pedagogical foundation subject, whose content is determined not by pragmatic usefulness, but by the its role in the curriculum?(e.g. so if you say you've studied "parsing" people can assume you know about LALR, even if no one uses it.) I'm not saying the latter would be a bad thing - we need a common vocabulary - I'd just like to see progress at the core as well as the edges.

47 points by lapenne 17y ago

deleted 17y ago

[deleted]

I was taught by this book while at DIKU. It's pretty 'dry' with its LaTex typesetting and all, but thorough and pretty comprehensive within the scope.

rlm 17y ago

I've read it as a part of the introductory compiler course at DIKU (Computer Science dept. of University of Copenhagen). It's good for exactly what the title says: Basics of Compiler Design. It won't make you a compiler guru, but it will give you a good grasp of the fundamentals. If anyone is interested, I could share the weekly assignments and the exam project from the course. The advanced compiler course at DIKU uses Modern Compiler Implementation in ML: http://www.cs.princeton.edu/~appel/modern/ml/ http://www.cs.princeton.edu/~appel/modern/ml/.

Simucal 17y ago

In his first section he describes a compiler as something that turns high-level code into machine code. This isn't necessarily true is it? A compiler is something that takes code in one language and converts it to another. It can be a Python to Javascript compiler, or a C to x86 Assembly Compiler (which can then be assembled using an appropriate assembler). I'm reading both Louden's "Compiler Construction: Principles and Practice" and the Dragon Book. They are both good so far.

wlievens 17y ago
The thing is, if you make the definition too generic, everything turns out to be a compiler. For instance, Photoshop is a compiler that turns commands in the UI (the input language) into PSD files (the output language). It's a lot harder to define terms like "compiler" than it actually seems.
- eru 17y ago
  And you have to differentiate your definition for 'compiler' from 'interpreter'. And point out, that those two sit on opposite ends of the same spectrum.
  - wlievens 17y ago
    Even that is a fuzzy barrier. You have lots of languages that have the compiler built-in to the runtime environment (Smalltalk, and I guess most lisps?). Anything with JIT blurrs the line, too.
    - eru 17y ago
      Yes, that's what I was trying to say by mentioning a "spectrum". Threaded interpreters are also closer to compilers than most.

Bjoern 17y ago

I can only recommend the "Dragon Book". Its old but really a great intro into Compilers. I had the benefit of working with it must say I didn't find anything better so far. Compilers: Principles, Techniques, and Tools by Alfred V. Aho (Author), Ravi Sethi (Author), Jeffrey D. Ullman (Author) http://www.amazon.com/Compilers-Principles-Techniques-Alfred-Aho/dp/0201100886 http://www.amazon.com/Compilers-Principles-Techniques-Alfred...

eru 17y ago
I found the Dragon Book quite dull, and old fashioned. "Implementing Functional Programming Languages" [1] by Simon Peyton-Jones makes a much more interesting read. Edit: I guess, we are talking about different Dragon Books. Wikipedia lists [2] at least three. And says about the first: "Principles of Compiler Design is now rather dated [...]." [1] http://research.microsoft.com/en-us/um/people/simonpj/papers/slpj-book-1987/ http://research.microsoft.com/en-us/um/people/simonpj/papers... [2] http://en.wikipedia.org/wiki/Dragon_Book http://en.wikipedia.org/wiki/Dragon_Book

10ren 17y ago

Just browsing the contents on parsing (what I"m working on), it seems little different from the Dragon book. Has the simplest way to construct a parser really not improved after all these years? What about the LL(*) class of parsers that ANTLR uses, and packrat parsers (I don't use these, have just heard about them). Or has "parsing" become a pedagogical foundation subject, whose content is determined not by pragmatic usefulness, but by the its role in the curriculum?(e.g. so if you say you've studied "parsing" people can assume you know about LALR, even if no one uses it.) I'm not saying the latter would be a bad thing - we need a common vocabulary - I'd just like to see progress at the core as well as the edges.