Path: utzoo!attcan!uunet!husc6!mailrus!iuvax!pur-ee!uiucdcs!uiucdcsp!gillies
From: gillies@uiucdcsp.cs.uiuc.edu
Newsgroups: comp.sys.mac.programmer
Subject: Re: Knowing Machine Code
Message-ID: <104700039@uiucdcsp>
Date: 15 Jun 88 05:36:00 GMT
References: <13735@comp.vuw.ac.nz>
Lines: 20
Nf-ID: #R:comp.vuw.ac.nz:13735:uiucdcsp:104700039:000:1044
Nf-From: uiucdcsp.cs.uiuc.edu!gillies    Jun 15 00:36:00 1988


I'm no expert on compiler technology, but I think some of the most
powerful optimizing compilers build a parse tree in memory and then
apply all sorts of heuristic reorganizations to the tree.  Also, some
small combinatorial register allocation problems can be solved on a
per-procedure basis (expensively).  Furthermore, when you generate
machine code you probably want to do some peephole optimization.  This
multiple-pass approach makes this type of optimizing compiler
fundamentally slow.  For a quick turnaround compiler you want to read
a line of language, emit loader code, and move on, e.g. a single pass.

That's why I was suggesting that highly optimizing compilers are
fundamentally different from high speed compilers.  If you remember
WATFOR and WATFIVE (some of the first quick turnaround FORTRAN
compilers ever written), these compilers purposely emitted bad code to
reduce turnaround time.  I don't think you can have your cake and eat
it too.

Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois
            {gillies@cs.uiuc.edu}