|Parallel compilers firstname.lastname@example.org (Gabriele Farina) (2009-09-04)|
|Algol68 compiler ? email@example.com (1996-02-19)|
|Re: Algol68 compiler ? firstname.lastname@example.org (1996-02-23)|
|Parallel Algol68 compiler email@example.com (1996-02-27)|
|Re: Parallel compilers firstname.lastname@example.org (Michael Parkes) (1996-03-05)|
|From:||Michael Parkes <email@example.com>|
|Date:||5 Mar 1996 12:23:33 -0500|
|Organization:||Sense Networking Seattle (www.oz.net)|
|References:||96-02-236 96-02-290 96-02-325|
firstname.lastname@example.org (Alex Colvin) wrote:
>Early Un*x compilers ran as a number of processes connected by pipes.
>Although this was largely due to address space limits, I suppose it
>might allow some overlap of analysis and I/O.
>Unfortunately, it looks like C requires that the lexer and declaration
>semantics be carefully synchronized, limiting the potential
I have worked on a tool that splits a compiler into a number of
processes linked by pipes and have tested the results. The speed up
is pretty good with the usual limits - the result runs as fast as the
slowest part and only scales to the number of passes (usually 4-6
It turns out that there is no *need* to synchronize the a 'C' lexer
with the parser and symantics it is just common practice as it makes
things somewhat easier when writing a compiler in a traditional manor.
However, using suitable tools the lexer can run as a free standing
process with no noticeable effects.
Return to the
Search the comp.compilers archives again.