|Code Opt. in One-pass Compilation firstname.lastname@example.org (1996-07-24)|
|Re: Code Opt. in One-pass Compilation email@example.com (Tom Hawker) (1996-07-26)|
|Re: Code Opt. in One-pass Compilation firstname.lastname@example.org (1996-07-27)|
|Re: Code Opt. in One-pass Compilation email@example.com (1996-07-31)|
|Re: Code Opt. in One-pass Compilation firstname.lastname@example.org (1996-08-04)|
|Re: Code Opt. in One-pass Compilation email@example.com (Henry Spencer) (1996-08-09)|
|From:||firstname.lastname@example.org (Henry Baker)|
|Date:||27 Jul 1996 21:19:58 -0400|
Wei Jen Yeh wrote:
> I wonder if anybody knows of books/papers that discuss optimizations
> that can be performed for one-pass compilers (that generate code
> as it parses the source program). TIA.
Tom Hawker <email@example.com> wrote:
> See Aho and Ullman's Dragon books as well as their 2-volume theory set.
> They discuss one-pass compilation and the possible optimizations. If I
> remember correctly, the UCSD P-system used a one-pass compiler that can
> optimize whole functions, but they didn't do some of the more complex
> DAG-type optimizations because the underlying virtual architecture did
> not need it.
Aho & Ullman's coverage of 1-pass optimization is hopelessly naive. A&U,
and most of the CS compiler literature, are in love with very large, complex,
and _slow_ compilers.
Several years ago, I had an occasion to compare a number of Ada compilers
on the same source code. The time to compile & link ranged from 2 minutes
to 30 minutes (!!!), where the time to compile was _directly_ related to
the speed of the machine (i.e., the workstation compilers took _longer_ than
the PC compilers). The quality of the produced code was essentially
independent of the time to compile, with the fastest compiler producing
nearly the same speed as the slowest compiler.
The amount of main memory varied from 2 megabytes to over 30 megabytes.
(One of the workstation compilers blew out after running out of 45 mbytes
of swap space.)
After some detective work, it appeared that the 'big' compilers converted
the entire source program into some sort of an internal 'tree' structure
before even attempting to start compiling it. They then threw this
structure away, rather than caching it in some fashion.
I haven't seen very much coverage of _small_ and _fast_ compilers in the
compiler literature. I guess it's difficult to get tenure when you work
on something that practical. ;-) ;-) ;-)
Return to the
Search the comp.compilers archives again.