|Two-pass C compilers firstname.lastname@example.org (1992-08-15)|
|Re: Two-pass C compilers behrenss@Informatik.TU-Muenchen.DE (1992-08-16)|
|Re: Two-pass C compilers email@example.com (1992-08-16)|
|Re: Two-pass C compilers firstname.lastname@example.org (1992-08-16)|
|Re: Two-pass C compilers email@example.com (Gary Merrill) (1992-08-17)|
|Re: Two-pass C compilers firstname.lastname@example.org (1992-08-18)|
|Re: Two-pass C compilers mcrware!adam@uunet.UU.NET (1992-08-19)|
|Organization:||Computing Services Division, University of Wisconsin - Milwaukee|
|Date:||Sun, 16 Aug 1992 19:06:31 GMT|
behrenss@Informatik.TU-Muenchen.DE (Soenke Behrens) writes:
>Hmmm ... beat me if I something silly, but: Is there any way around
>a two-pass compiler? (Or even more passes)
>First pass: Reading in the source, preprocessing it, building a symbol table.
>Second pass: Generate p-Code
>Third pass: Optimize p-Code (Note: Do not mix with 2nd pass or you are
>in deep trouble)
>Fourth pass: Generate native code in linkable object file
Pass 1: Generate optimized binaries, into an object file.
Back-patch forward references, Dump table of external and globals.
The object file format is dictated by this method. All memory images must
be written before the tables and after the header. The header must be
fixed in size, and must contain all the needed pointers to access the
The code generation rules are carefully written with optimization built
into them. For example, they can be derived by knowledge engineering
techniques from an expert human compiler (presunably the person doing the
compiler-writing would qualify).
Global analysis, data flow, register allocation, control flow are all done
on the fly during parsing. Whatever intermediate structures are needed
are stored in memory.
Pass 1.5: Linking object files and resolving the remaining unresolved objects.
Return to the
Search the comp.compilers archives again.