Re: Writing a FAST compiler.

beard@ux5.lbl.gov (Patrick C Beard) writes:
>[Compiling code fast vs. compiling fast code]


John Levine writes:
>[Minimize I/O, compile directly in to memory, use fast linkers.]


See the documentation with lcc (anon ftp from princeton.edu):


* The lexer is derived automatically from a lexer specification.
    Rather than use e.g., |lex| to generate an FSM, they generate C
    code. Their tests indicate this runs faster.


* The parser is recursive descent, hand-coded for C.
    (See [Penello 86] and [Pagan 90])


Other things:


* If you have a preprocessor, integrate it with the other phases.


* Don't generate assembly code. Generate object code directly.


* Defer linking until execution.


If you have access to the previous version of the file, recompile only
the changes; e.g., changes within a function body affect only the
particular function.


Defer (all) translation to execution. Things that aren't executed
aren't even translated.




Finally, the best way to make something faster: be inflexible.


%A Thomas J. Pennello
%T Very Fast LR Parsing
%J Proceedings of the SIGPLAN 1986 Symposium on Compiler Construction;
SIGPLAN Notices
%V 21
%N 7
%D July 1986
%P 145-151


%A Frank G. Pagan
%T Comparative Efficiency of General and Residual Parsers
%J SIGPLAN Notices
%V 25
%N 4
%D April 1990
%P 59-68


;-D on ( What language is FAST? ) Pardo
--

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