Path: utzoo!attcan!uunet!wuarchive!texbell!cs.utexas.edu!usc!snorkelwacker!spdcc!esegue!compilers-sender
From: preston@rice.edu (Preston Briggs)
Newsgroups: comp.compilers
Subject: Re: Compiler Design in C How about it?
Keywords: books, summary
Message-ID: <1990Jun1.194941.5781@esegue.segue.boston.ma.us>
Date: 1 Jun 90 19:49:41 GMT
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: Preston Briggs <preston@rice.edu>
Organization: Rice University, Houston
Lines: 59
Approved: compilers@esegue.segue.boston.ma.us
In-Reply-To: <1990May31.160821.3007@esegue.segue.boston.ma.us>

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.