The proliferation of processors, environments, and constraints on systems has cast compiler technology into a wider variety of settings, changing the compiler and compiler writer's role. No longer is execution speed the sole criterion for judging compiled code. Today, code might be judged on how small it is, how much power it consumes, how well it compresses, or how many page faults it generates. In this evolving environment, the task of building a successful compiler relies upon the compiler writer's ability to balance and blend algorithms, engineering insights, and careful planning. Today's compiler writer must choose a path through a design space that is filled with diverse alternatives, each with distinct costs, advantages, and complexities. Engineering a Compiler explores this design space by presenting some of the ways these problems have been solved, and the constraints that made each of those solutions attractive. By understanding the parameters of the problem and their impact on compiler design, the authors hope to convey both the depth of the problems and the breadth of possible solutions. Their goal is to cover a broad enough selection of material to show readers that real tradeoffs exist, and that the impact of those choices can be both subtle and far-reaching. Authors Keith Cooper and Linda Torczon convey both the art and the science of compiler construction and show best practice algorithms for the major passes of a compiler. Their text re-balances the curriculum for an introductory course in compiler construction to reflect the issues that arise in current practice.
Given that this can easily be made into a very confusing and convoluted subject, this book does a really good job of simplifying Compiler Engineering. Still I must give a warning that this subject is not for the faint of heart.
Engineering a Compiler is an excellent introductory text on compilers. I particularly enjoyed the textbook's clean layout and design and cleanly written algorithms placed very close to the paragraphs where they are relevant.
Particularly after reading Muchnick, I found the amount of text explanation with a lack of concrete examples to be disturbing. Whole sections pass without any accompanying code examples. While I didn't think that pseudocode would have particularly enriched these topics, and I could certainly look up the relevant papers provided in the bibliography, I found the lack of a concrete representation to work with left me somehow wanting more.
All in all I suggest Engineering a Compiler as an excellent candidate for easy entry into a discussion on compilers, or an undergraduate text. After reading this textbook, if you're still hungry for more on compilers, try Appel's Compilers in ML and Muchnick's Advanced Compiler Design and Implementation.
It may be a great introduction, but I will never know. The problems with books like this is that they skim over topics not going deep into the subject ever. This book has some good chapters. The content in the book is not dense, it’s written in very dry academic style. In plain english, it is just boring. I cannot see anyone reading this book from cover to cover. And yet it is not a reference. I do not recommend it.
GT Barnes & Noble 2009-01-0x. I've been reading too many books and papers about compilers the past few months to really enjoy this book very much, especially compared to Kennedy's and Muchinek's. This is kind of the "West End" or perhaps "Goals 2000" of the trio they form, with the least rigorous presentation and most minimal coverage. I think we're using this in CS6241 only because so many MS students are gormless waste-wits, admitted only to collect some tuition (I'm coming to loathe introducing myself as an MS student; until I start my PhD, I'm going to stick with "principal engineer, mcafee" and only admit I'm also a student when prodded). Sigh, such is life!
Alright book if you are looking for a good overview of compiler concepts. I read this while using the Dragon Book as a reference, and I think in the future I will definitely use the Dragon book to look up information, but this book did a much better job of explaining concepts in a non-technical way first.
I enjoyed how the author clearly explained how algorithms in the compilers is working, especially the layout part that I think also contributed to the fact that it’s easier for me to read it.
I'm somewhat disappointed by this book, although it's not a bad reference overall.
The text is mostly fine and quite thorough, with a very similar approach to the "Dragon Book" while being sometimes more up-to-date (full reference of the Dragon Book at the end).
However, many sections are less detailed and painful to read. For example, the RE/NFA/DFA scanners seem to miss some steps and a proper presentation. The transformation from RE to NFA starts with a block of theory in which some terms have not been introduced - the reader has to fetch them further in the book and look at later examples to make sense of what the authors meant. Or the top-down and bottom-up parsing sections, which are essential parts of understanding how compilers work, are too summarized and not very clear in comparison to the Dragon Book either. There too, the authors tend to be entrenched in their abstract narrative, sometimes being even inconsistent in their notation, instead of clarifying what they mean with a simple example.
I'm surprised that modern tools are not better represented since they are a great help when developing a compiler (Lex, Yacc, ANTLR, LLVM, ...). It's always a good idea to mix theory and practice, and help the reader understand how it is applied with existing tools. After all, most of them won't be making a new compiler from scratch, they will be using existing tools.
There seems to be font issues as well, because some variable letters appear in a completely different format in the equations and the related text, which may be confusing sometimes. I know that this problem occurs sometimes in the publishing process when different software tools are used - authors of a couple of other books have reported that to me in the past. But this is the third edition, such issues should have been identified for a long time.
More frustrating is the lack of solution to the exercises. The book claims in the preface that the solutions, along with other resources, were available on the website. I typed the long URL to get there, but there was nothing available. After a few exchanges with a support who was obviously unwilling to help in any way, it appears that this promised "additional material" is only available to professors, after giving personal details on a specific portal (you still have to go through the support to get there, and get an approval after submitting your personal details).
It's not entirely legal and I was relying on the solutions to help with the learning curve, so I feel cheated. Just keep in mind that it's simply not available to anyone - I'm not even sure that it's free to teachers who qualify.
Physically overall, it is easy to handle and while the sheets are curiously uneven on the fore edge, the assembly seems robust and not likely to fall apart after the first reading. I like the notes in the margin, but why not use them to add definitions and acronyms (that I had to search multiple times)? The very succinct index didn't help much either. For some of the terms, I finally looked into the Dragon book.
Considering the steep price of this book, I'm removing a few stars for all those problems. If the solutions were freely available (or better - in the book itself), if the book had a good index, and no font issues, I would have given it 3 stars.
Buy this book only if you can't get a copy of Compilers: Principles, Techniques, and Tools by Alfred V. Aho, Monica S. Lam, Ravi Sethi, Jeffrey D. Ullman.
Engineering a Compiler is the default follow up for Engineering students after having just completed theory of computer science course laying common foundation with pure science.