Re: To get things started...
[email protected] (Steve Fink) Wed, 22 Nov 2000 11:59:32 -0800
| Newsgroups | perl.perl6.internals.api.parser |
|---|---|
| Organization | Digital Integrity |
| Message-ID | <[email protected]> |
Bart Lateur wrote: > > On Tue, 21 Nov 2000 17:24:49 +0000, Simon Cozens wrote: > > >I really *would* recommend Aho, Sethi, Ullman, "Compilers: Principles, > >Techniques and Tools". > > AKA "The Dragon Book". You're not the only one to mention this book on > this list. > > IMO, this book is really thick to crawl through, and in the end, it's > all just theory, you still won't be able to build a compiler, or an > optimizer in case you already have a compiler. Heh. In short: are there > any more *practical* "how do I build my own compiler" books, that people > can wholeheartedly recommend? There's the LCC book. Practical Compiler Construction, or something? Should be easy to search for. It uses literate programming to describe a complete C compiler. But on the scale from theory to practice, it's too far on the practice end to be "how do I build my own compiler" -- the stuff they talk about often doesn't translate to other compilers. It's really a case study. I've written a complete compiler using the Dragon Book and the lectures from the class it was for. It was a complete compiler, from input text to MIPS assembly code output. But I wouldn't recommend the Dragon Book for practical purposes either. It's mostly useful to see what problems exist, the general approach with which they're traditionally addressed, and what terminology to use in talking about them. (And my experience isn't all that relevant, considering it was a class project with provided skeleton code and a toy language.) I've also implemented my own LALR parser from scratch, using only the Dragon Book as a reference, and I'd say it was more of a hindrance than a help. Too theoretical, too much magic hidden in the math. Sends you off on the wrong direction implementation-wise. I got more benefit from my memories of the yacc source code that I read through about five years ago, even though I intentionally avoided copying yacc's algorithm. For other recommendations, there's always gcc's source code. But it's too hairy to be comprehensible. I've heard very good things about a compiler written at Stanford. I forget the name now. But apparently many people prefer to modify it rather than dealing with gcc's complexity. Might be an informative read.