|Writing a FAST compiler. email@example.com (1991-08-05)|
|Re: Writing a FAST compiler. firstname.lastname@example.org (1991-08-07)|
|Re: Writing a FAST compiler. email@example.com (1991-08-07)|
|Re: Writing a FAST compiler. firstname.lastname@example.org (1991-08-07)|
|Re: Writing a FAST compiler. email@example.com (1991-08-07)|
|Re: Writing a FAST compiler. firstname.lastname@example.org (Tom Wicklund) (1991-08-08)|
|Re: Fast compilation email@example.com (1991-08-09)|
|[1 later articles]|
|From:||firstname.lastname@example.org (Patrick C Beard)|
|Date:||Mon, 05 Aug 91 23:34:55 PDT|
Most compiler efficiency issues revolve around creating highly optimized
code. However, good code generation with fast turn-around time is often
more important for the software engineer. Who cares how good the code
generated is if it's just going to change as the development process
proceeds? Therefore, my question is, how do I go about creating a compiler/
interpreter that goes as fast as possible, uses as little memory as possible,
and produces reasonably efficient code as possible. The obvious application
is for a compiler that runs on a microcomputer such as the Macintosh, with
limited resources. What are some general approaches I can follow to create
a compiler that generates slow to moderate code very quickly?
Patrick C. Beard
Berkeley Systems, Inc.
[Many PC compilers, notably Borland's Turbo compilers, run extremely fast.
The trick seems to be to minimize I/O, e.g. buffer include files in
memory,compile directly into memory if possible, use fast degenerate linkers,
etc. I also recall that the compilers for the Dartmouth Timesharing System,
which ran lots of languages other than Basic, were so fast that in most cases
people saw no point in saving object code. The various Waterloo Fortran
compilers WATFOR and WATFIV also did fast turnaround batch jobs, though I
haven't really looked at them in 20 years and don't know what they're like
Return to the
Search the comp.compilers archives again.