Compiler text

Francois Nouri asked:
> I very recently re-read parts of the "dragon book" ("Compilers:
> Principles, Techniques, and Tools"). Although I know it is a reference
> book, I found it to err too much on then side of the theory and to neglect
> practical aspects.


I agree completely with this point, and it is the reason that Lynn Carter
and I embarked on writing an undergraduate text on compiler construction
that went in the opposite direction.


> I also took a second look at parts of Holub's "Compiler in C" which had
> been heavily used in my compilers course last year. It really was a lot
> more pragmatic than the dragon book, but I found the code generation part
> rather disappointing, especially since what was generated was "c-code" and
> not some real assembly language. Moreover, code optimization was totally
> skipped, if memory serves me.


We do go through what we call "competent" code generation. The resulting
code is actually very good, even though we do not do (say) common
subexpression analysis. We define a project that translates a subset of C
to VAX assembly code. Here is a typical source program and the code
generated by a compiler built according to the model we present:


int
GCD(int x, int y)
{ while (!(x == y))
        if (x > y) x = x - y; else y = y - x;
    return x;
}


.ENTRY START,4095
SUBL2 #8,SP
PUSHAL -4(FP)
CALLS #1,READL
SUBL2 #8,SP
PUSHAL -8(FP)
CALLS #1,READL
BR L3
L1: CMPL -4(FP),-8(FP)
BLEQ L2
SUBL2 -8(FP),-4(FP)
BR L3
L2: SUBL2 -4(FP),-8(FP)
L3: CMPL -4(FP),-8(FP)
BNEQ L1
PUSHL -4(FP)
CALLS #1,WRITEL
RET
.END START


In this C subset the main program is always a procedure, and its arguments
are read from standard input. It's result is written to standard output.
Thus the body of the routine begins with "BR L3" and ends with "BNEQ L1".


> So, here I am: I am looking for a book which would be a good mix of those
> two books, i.e. a book that would combine the theoretical aspects and some
> implementation examples for a reasonably real compiler (generating
> assembly code for 680X0 or SPARC, for example).


Depends on how much theory you want. We took the attitude that giving a
lot of theory to undergraduates IN ADDITION to teaching them how to
actually build a compiler was too much. Therefore we USE the theory, and
build intuition about what's going on, but do not attempt to teach the
theory as such. I've found this to be a good strategy, but I know that
some people dislike it intensely. Our philosophy is stated in the
preface:


    Compiler construction has extensive theoretical foundations. The subject
    is often taught in a deductive manner, formally deriving the necessay
    algorithms from a set of axioms. We feel that this deductive approach is
    a mistake as an introduction to the subject. Most people are inductive
    learners, preferring to begin with observations of phenomena and then
    move to theoretical explanations. Our presentation is therefore centered
    on specific examples that, together, characterize the complete
    compilation problem. We provide systematic, intuitive approaches to
    solving the compiler subproblems posed by these examples. All of these
    approaches are grounded in theory, and each chapter provides notes and
    references pointing the reader to that theory. We strongly believe that
    it is more important for an introductory text to present a complete,
    coherent picture of the compilation process than to provide
    mathematically elegant derivations of individual algorithms.


> Am I asking too much, or is this little wonder available somewhere ?


You will have to decide for yourself whether it can be considered a
"little wonder", but it certainly is available:


William M. Waite and Lynn Robert Carter, "An Introduction to Compiler
Construction", HarperCollins College Publishers, New York, 1993. ISBN
0-673-39822-6


HarperCollins College Publishers
10 East 53rd Street
New York, NY 10022 USA
--

Return to the comp.compilers page.
Search the comp.compilers archives again.