Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!necntc!ames!ucbcad!ucbvax!decvax!ima!johnl
From: stevev@tekchips.tek.com (Steve Vegdahl)
Newsgroups: comp.compilers
Subject: Re: Request comments on text.
Message-ID: <609@ima.ISC.COM>
Date: Mon, 6-Jul-87 14:26:47 EDT
Article-I.D.: ima.609
Posted: Mon Jul  6 14:26:47 1987
Date-Received: Wed, 15-Jul-87 00:54:30 EDT
Sender: johnl@ima.ISC.COM
Lines: 69
Approved: compilers@ima.UUCP
In-Reply-To: Your message of 2 Jul 87 19:16:45 GMT.  <252@hubcap.UUCP>


>[I'm not familiar with Trembley and Sorenson, but is there any particular
>reason not to use the dragon book? -John]

In response to John's question, I can think of a number of reasons to not
use the dragon book.  Before I list the ones I can think of, let me
preface this with some background.

I have taught both the front- and back-end halves of a two-quarter
graduate compiler course using the dragon book (1986 edition).  Non-
technical circumstances made the use of the dragon book nearly manditory,
so I spent virtually no time searching for other options.  DESPITE THE FACT
THAT FOLLOWING TEXT DISCUSSES WEAKNESSES OF THE DRAGON BOOK, I THINK THAT
OVERALL, IT IS A GOOD COMPILER TEXT.  My compiler experience has been in
compilers for microcode target architectures, and for "advanced" languages
(e.g., Lisp, Smalltalk) for more traditional architectures.

The following describe what I perceive to be weaknesses of the dragon book.
These weaknesses can be largely summed up in the sentence "the dragon book
teaches you how to write a C compiler for a traditional architecture".

  * Although I feel that the treatment of the lexical and syntax analysis
    if very nice, the discussion of semantic analysis lacks a bit of
    overall perspective, being treated in a somewhat ad hoc fashion.  The
    treatement of back-end issues (e.g., code-generation, optimization)
    is even less unified.
  * The issue of automatic garbage-collection is all but ignored.  It
    is actually ignored in two ways.  First, little treatment of garbage
    collection algorithms is given.  (ONE PAGE to discuss both reference-
    counting and marking.  I believe that they do not even mention copying
    garbage-collectors and generation-scavenging, although the latter may
    have been too recent for their printing schedules.)  Secondly, the
    presence of a garbage-collector in an implementation pervades (virtually)
    the entire compiler.  For example, non-standard data-representations
    are typically used; certain optimizations may be disallowed; registers
    are typically divided into "rooted" and "non-rooted" classes, with
    restrictions on how each is used.  The pervasiveness of the garbage-
    collection on the entire compiler-writing process is ignored by the
    book.
  * Little (if any) treatment is given to supporting first-class procedures
    and continuations.
  * Although type-inference (a la ML) is discussed, the treatment given
    is too shallow.  Subtleties arise when implementing type-inference
    that are not addressed.
  * No (little?) discussion of code-reorganization that is now common in
    many RISC-style compilers.
  * A good programming environment is becoming increasingly recognized
    as a fundamental piece of a language implemenation.  The book does
    not really address this subject.  Quite a bit of good work has
    been done, for example, in the area of incremental compilation
    (e.g., Reps).

OK, there's my (partial?) list of "gripes" about the dragon book.  Let
me again say that this should not be (mis)construed as a statement that
the dragon book is a lousy book; on the contrary, I think it's a very
informative, well-written book.  If a book came out, however, that
addressed some of the above issues, it would be worth considering as
a replacement for the dragon book.  I do not know whether any such book
exists.  In particular, I am not familiar with Trembley and Sorenson.
(Who publishes their book?)

		Steve Vegdahl
		Computer Research Lab
		Tektronix Labs
		Beaverton, Oregon
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request