eve@tnoibbc.ibbc.tno.nl (Edwin van Ek) (05/31/90)
Can anyone give me an unbiased opinion about the book Compiler Design in C
by A. Holub. It is now available in Holland and I may want to buy it. I've
read the description the author gave some months ago, and it seems a good
book. I really like to know what other people think of the book, for
instance in comparison to AHO. That one I've read because of the courses in
building a compiler.
Thanks in advance,
Edwin van Ek, eve@tnoibbc.tno.nl
PS
This address is only valid until the 20-th of June. After that date I
don't know when I can read this news-group. So please answer as quick as
possible.
--
Edwin van Ek: TNO - IBBC INTERNET: eve@tnoibbc
: PO-box 49 DOMAIN : eve@tnoibbc.tno.nl
: 2600 AA Delft FAX : +31 15 843990
: the Netherlands VOICE : +31 15 842357
[There was some generally favorable discussion about this book earlier
this year including a message from the author. -John]
--
Send compilers articles to compilers@esegue.segue.boston.ma.us
{spdcc | ima | lotus}!esegue. Meta-mail to compilers-request@esegue.
Please send responses to the author of the message, not the poster.preston@rice.edu (Preston Briggs) (06/02/90)
In article <1990May31.160821.3007@esegue.segue.boston.ma.us> you write: >Can anyone give me an unbiased opinion about the book Compiler Design in C >by A. Holub. Here's my (certainly biased) review. It's massive -- more than 900 pages. Primarily concerned with front-end development; that is, minimal coverage of optimization or code generation. 450 pages on scanning and parsing, which apparently includes development of LL and LALR parser generators. Much source code available. Another 200 pages describing most of a C front-end. Great figures; the best I've ever seen for the symbol table layout, etc. 25 (fatal) pages on optimization. 200 pages of appendices. Weak bibliography; almost exclusively books and ignoring most of the interesting technical literature (archival journals, conference proceedings). Overall, I'd say it magnifies the problem of Aho, Sethi, and Ullman (the Red Dragon book) in that it over-develops the easy parts of a compiler and gives short shrift to the interesting areas (I said I was biased!). I complained about the coverage of optimization. The short chapter is really just a menu and I only skimmed it. Three things stood out: 1) Discussions of optimization should introduce and emphasize data flow analysis. Without it, all is lost. 2) He propagates the common error that an integer var divided by a constant power of 2 (say x/8) can be replaced by a shift right (say x >> 3). This gives suprising answers when x is negative. 3) Near the end of the chapter, he includes this paragraph: ``You, as the compiler writer, must decide if it's worth the risk of doing this kind of optimization. It's difficult for the compiler to distinguish between the safe and dangerous cases, here. For example, many C compilers perform risky optimizations because the compiler writer has assumed the that a C programmer can understand the problems and take steps to remedy them at the source code level. It's better to provide the maximum optimization, even if it's dangerous, than to be conservative at the cost of less efficient code.'' I was shocked. My optimizer friends were shocked. I didn't show it to my Scheme or ML friends as it would have confirmed their worst suspicions about compilers and compiler writers. -- Preston Briggs looking for the great leap forward preston@titan.rice.edu [I must admit, I'd be awfully reluctant to use a compiler that was written by somebody who feels that way. There's a computational tradition of preferring wrong answers quickly to correct answers slowly, but it was never a good idea. -John] -- Send compilers articles to compilers@esegue.segue.boston.ma.us {spdcc | ima | lotus}!esegue. Meta-mail to compilers-request@esegue. Please send responses to the author of the message, not the poster.
rice@DG-RTP.DG.COM (Brian Rice) (06/02/90)
In article <1990May31.160821.3007@esegue.segue.boston.ma.us>, eve@tnoibbc.ibbc.tno.nl (Edwin van Ek) writes: > Can anyone give me an unbiased opinion about the book Compiler Design in C > by A. Holub. ... I bought the book when it first became available (about two and a half months ago, if my memory serves me). I like it O.K.--it explains things in a way which I can understand (I'm not a compiler scholar), and the example programs are detailed and interesting. And, of course, knowing that the author has an e-mail address and reads comp.compilers is a big plus. However, I really wish I had waited a few months to buy the book. The copy I have has a whole lot of typographical errors...not only are the errors distracting, but also I feel like a sucker for having forked over my US$50 for the book before Prentice- Hall bothered to run a spelling-checker over the damn thing. God willing, they might have done so by now. Brian Rice rice@dg-rtp.dg.com (919) 248-6328 DG/UX Product Assurance Engineering Data General Corp., Research Triangle Park, N.C. -- Send compilers articles to compilers@esegue.segue.boston.ma.us {spdcc | ima | lotus}!esegue. Meta-mail to compilers-request@esegue. Please send responses to the author of the message, not the poster.
markh@squirrel.labs.tek.com (Mark Henderson) (06/04/90)
In article <1990Jun1.194941.5781@esegue.segue.boston.ma.us> Preston Briggs <preston@rice.edu> writes: >[quoting Holub, using unsafe optimizations is an OK idea] Fact is, historically the optimizer is where compiler writers have hung themselves. I've used several commercial compilers for which I often had to turn off the optimization to get them to handle some pretty mundane code properly. (I suppose there is no need to mention company names here). Part of the problem is that there is little (unified) theory of optimization and a lot of ad hoc techniques. Certainly the front end has a more complete. theoretical base. I guess the argument is, "that part is the easiest", but then consider that this is a textbook. I think the level of detail Holub is using to describe the front end will be useful to people learning about the front end. I don't think the intention of the book was to be an encyclopaedia of compiler design, either. The material seems more than adequate for a first course in compiler design. Optimization techniques could easily be a course or book in themselves. The book is already over 900 pages long... So what I'm saying is that I like the book, on the whole. Personally, I find the level of detail of code listings a bit aversive, but then they can always be skipped and referred back to for details. The explanations are clear. The diagrams are excellent. I really like the fact that lots of examples are given. Mark -- Mark Henderson, Tektronix, Inc., MS 50-662, P.O. Box 500, Beaverton, OR 97077 Telephone: +1 503 627 6280 FAX: +1 503 627 5502 TELEX: 6503784996MCI UW INTERNET: markh@squirrel.labs.tek.com ATTmail: !mchenderson MCI MAIL: 378-4996 X.400: ADMD=MCI/C=US/Surname=Henderson/Given_Name=Mark/DDA ID=3784996 -- Send compilers articles to compilers@esegue.segue.boston.ma.us {spdcc | ima | lotus}!esegue. Meta-mail to compilers-request@esegue. Please send responses to the author of the message, not the poster.
tbrakitz@phoenix.princeton.edu (Byron Rakitzis) (06/05/90)
In article <1990Jun4.044858.15066@esegue.segue.boston.ma.us> Mark Henderson <markh@squirrel.labs.tek.com> writes: >In article <1990Jun1.194941.5781@esegue.segue.boston.ma.us> Preston Briggs <preston@rice.edu> writes: >>[quoting Holub, using unsafe optimizations is an OK idea] > >Fact is, historically the optimizer is where compiler writers have hung >themselves. I've used several commercial compilers for which I often had to >turn off the optimization to get them to handle some pretty mundane code >properly. (I suppose there is no need to mention company names here). I've heard quite the opposite from Richard Stallman about his GCC compiler, paradoxically enough: he claims that there are more bugs in "gcc" as opposed to "gcc -O" since most of the time gcc users turn the optimizer on (and hence have uncovered the optimizer bugs) and also that the optimizer tends to hide a few bugs in the code generator by never letting it generate the bad code in the first place! -- Byron Rakitzis. (tbrakitz@phoenix.Princeton.EDU) -- Send compilers articles to compilers@esegue.segue.boston.ma.us {spdcc | ima | lotus}!esegue. Meta-mail to compilers-request@esegue. Please send responses to the author of the message, not the poster.
mike@thor.acc.stolaf.edu (Mike Haertel) (06/06/90)
In article <1990Jun4.212544.18596@esegue.segue.boston.ma.us> tbrakitz@phoenix.princeton.edu (Byron Rakitzis) writes: >I've heard quite the opposite from Richard Stallman about his GCC >compiler, paradoxically enough: he claims that there are more bugs in >"gcc" as opposed to "gcc -O" since most of the time gcc users turn the >optimizer on (and hence have uncovered the optimizer bugs) and also >that the optimizer tends to hide a few bugs in the code generator by >never letting it generate the bad code in the first place! There have indeed been substantially worse problems with the code generator in GCC than there have with the optimizer. Or at least, this is the impression I have gotten in conversations with RMS. The optimizer has a rather more well-defined problem: Optimizing sequences of RTL instructions. The code generator has to produce those instructions in the first place, and it does so with a variety of ad-hoc techniques that are severely conditionalized on the characteristics of the target machine. The use of ad-hoc techinques as opposed to more uniform strategies is obviously a potentially very rich source of bugs. The optimizer, in contrast, deals with the same RTL language for all target machines, and also uses more well-defined algorithms from the literature. -- Mike Haertel <mike@acc.stolaf.edu> -- Send compilers articles to compilers@esegue.segue.boston.ma.us {spdcc | ima | lotus}!esegue. Meta-mail to compilers-request@esegue. Please send responses to the author of the message, not the poster.
napi@rangkom.MY (Mohd Hanafiah b. Abdullah) (08/07/90)
Holub's book is excellent to be used for hands on compiler project. He
describes the implementation issues clearly so that one could start writing
the compiler virtually immediately. Algorithms written in C are also given,
and that is convenient. The book emphasizes using yacc/lex to write ANSI-C
compiler in C. It also explains the complete C "type" system, and structures
in detail. Thus, it could be said that Holub's book is better in getting
beginners who do not have much Math and/or Formal Languages to be more
confident to embark on a complex and time consuming software engineering
project such as writing a compiler for C. One drawback of the book is it
does not have a comprehensive chapter on optimizations.
On the other hand, Aho's book [Aho, Hopcroft, and Ullman, I expect -John]
tries to develop sound fundamental as well as advanced understanding of the
subject matter so that one understands the overall structure and the
underlying principles and theorems. By understanding the "bigger catches" of
compiler design ie., principles and motivation of language and compiler
design, one will have a more meaningful experience and lasting understanding
of compiler writing. The book also explains optimizations in detail,
necessary for production quality compilers.
To summarize, it is good to study both books because they complement each
other to a large extent.
BTW, I haven't found any books on compiler design that explains how to write
a smart linkage editor and a loader in detail. The books never go beyond
mentioning them.
Hanafiah
--
Send compilers articles to compilers@esegue.segue.boston.ma.us
{spdcc | ima | lotus| world}!esegue. Meta-mail to compilers-request@esegue.