Re: Code Opt. in One-pass Compilation (Henry Baker)
27 Jul 1996 21:19:58 -0400

          From comp.compilers

Related articles
Code Opt. in One-pass Compilation (1996-07-24)
Re: Code Opt. in One-pass Compilation (Tom Hawker) (1996-07-26)
Re: Code Opt. in One-pass Compilation (1996-07-27)
Re: Code Opt. in One-pass Compilation (1996-07-31)
Re: Code Opt. in One-pass Compilation (1996-08-04)
Re: Code Opt. in One-pass Compilation (Henry Spencer) (1996-08-09)
| List of all articles for this month |

From: (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 <> 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. ;-) ;-) ;-)


Post a followup to this message

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