Related articles |
---|
Two-pass C compilers maniattb@cs.rpi.edu (1992-08-15) |
Re: Two-pass C compilers behrenss@Informatik.TU-Muenchen.DE (1992-08-16) |
Re: Two-pass C compilers quanstro@stolaf.edu (1992-08-16) |
Re: Two-pass C compilers markh@csd4.csd.uwm.edu (1992-08-16) |
Re: Two-pass C compilers sasghm@unx.sas.com (Gary Merrill) (1992-08-17) |
Re: Two-pass C compilers leichter@zodiac.rutgers.edu (1992-08-18) |
Re: Two-pass C compilers mcrware!adam@uunet.UU.NET (1992-08-19) |
Newsgroups: | comp.compilers,comp.lang.c |
From: | quanstro@stolaf.edu (goon) |
Organization: | St. Olaf College, Northfield, MN USA |
Date: | Sun, 16 Aug 1992 18:13:56 GMT |
References: | 92-08-081 |
Keywords: | C, design |
The moderator comments:
[Depends on what you mean by pass. Most C compilers I know turn C into
assembler and only read the source once. Whether you think of the
assembler as a second pass is a matter of semantics. Some compilers, e.g.
Turbo C, go directly from C to object code, again only reading the source
once. ...
It seems to me that the Dragon book is very careful in defining a "pass"
as "reading an input file and writing an output file." [p. 20] Now in each
pass you can have as many phases as you want. In theory it would be
possible to construct a compiler for any compilable language as a one-pass
compiler with some positive number of phases. For C one needs to do
lexical analysis, parsing, type checking, and code generation with several
other phases (such as intermediate code generation and optimization) often
implemented.
In practice, C compilers have generally (well, at least often) had two
passes, with the output of the second fed to the assembler. However this
is mostly an artifact of the memory limitations in the early days of UNIX.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.