Related articles |
---|
Code Opt. in One-pass Compilation yeh@ga.unc.edu (1996-07-24) |
Re: Code Opt. in One-pass Compilation 0002083004@mcimail.com (Tom Hawker) (1996-07-26) |
Re: Code Opt. in One-pass Compilation hbaker@netcom.com (1996-07-27) |
Re: Code Opt. in One-pass Compilation domjan@inf.ethz.ch (1996-07-31) |
Re: Code Opt. in One-pass Compilation p.froehlich@amc.cube.net (1996-08-04) |
Re: Code Opt. in One-pass Compilation henry@zoo.toronto.edu (Henry Spencer) (1996-08-09) |
From: | hbaker@netcom.com (Henry Baker) |
Newsgroups: | comp.compilers |
Date: | 27 Jul 1996 21:19:58 -0400 |
Organization: | nil |
References: | 96-07-176 96-07-187 |
Keywords: | optimize |
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 <0002083004@mcimail.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
comp.compilers page.
Search the
comp.compilers archives again.