Re: Two-pass C compilers

quanstro@stolaf.edu (goon)
Sun, 16 Aug 1992 18:13:56 GMT

          From comp.compilers

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)
| List of all articles for this month |
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.
--


Post a followup to this message

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