Re: Number of compiler passes

Michiel wrote:


> I was wondering, with the computers of today, with as much memory as they
> have, is there still a reason to limit the amount of passes a compiler
> makes? Sure, with each additional pass there will be some overhead, but
> other than that, is there a disadvantage I'm missing?
(snip)


John wrote:
> [Back in the era of coal fired mainframes, compilers were divided into multiple
> passes so the code for each pass could be overlaid. These days I agree that
> there isn't a strong argument either way except perhaps better cache data locality
> if you combine passes. -John]


Also, in those days the intermediate data usually went to disk.


I know discussion about changes in the OS/360 assembler, I believe
from F to XF, went from four passes to three, one less write and read
back from disk, with significant speed-up.


Not that I think we should go back to those days, but I am still
surprised at the amount of memory needed by some modern compilers.
There are people trying to run gcc on MVS with 24 bit addressing, with
the ability to compile itself, but it doesn't seem to fit.


There was also a discussion on extended addressing for the PDP-10,
such that one might be able to run gcc. Again, even with the full
extended addressing of TOPS-20, it seems that it won't fit.


-- glen

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