Number of compiler passes

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?


In particular, I'm working on a source-to-source compiler at the moment.
>From my own language to C. It now has the following stages:


* Flex + Bison to create AST
* Over AST to find declarations (and re-declarations)
* Over AST to detect which variables are used in which functions
* Over AST to find undeclared references
* Over AST to find the type of each expression and note type mismatches
* Over AST to find the access-type (read/write/both) of each expression
* Over AST to perform optimizations
* Over AST to translate to target language


Pass 2 to 4 may seem excessive, but I believe they are necessary because of
the following features:
* Var/function declarations anywhere in the code (incl. nested functions)
* Forward referencing of constant functions and constant variables


Some of the stages could be merged, I suppose. But it would not help code
readability or provability to do so.


I would like to hear some opinions about this.


Thanks!


--
Michiel Helvensteijn
[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]

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