|Non-sequential compilation. KODIS@delphi.com (1993-09-18)|
|Re: Non-sequential compilation. firstname.lastname@example.org (1993-09-21)|
|Re: Non-sequential compilation. email@example.com (1993-09-21)|
|Re: Non-sequential compilation. firstname.lastname@example.org (1993-09-21)|
|Re: Non-sequential compilation. email@example.com.OZ.AU (1993-09-22)|
|Re: Non-sequential compilation. firstname.lastname@example.org (1993-09-27)|
|Re: Non-sequential compilation. email@example.com.COM (1993-10-04)|
|From:||firstname.lastname@example.org (Cliff Click)|
|Organization:||Center for Research on Parallel Computations|
|Date:||Tue, 21 Sep 1993 16:43:49 GMT|
A great deal of compiler theory has a very stream-oriented flavor --
left-to-right scans, single vs. multi-pass translators, and so on. ...
is the sequential, stream orientated processing of current compiler
theory something which is being clung to beyond its usefulness?
Why not the best of both worlds? Take your old streaming code, and bump
up the buffer size. Still no limit on file sizes (and machine generated
source can be huge), but for "normal" stuff it's all loaded in a single
buffer read. I wrote a 68000 x-assembler for PCs. We used a 32K buffer
for each open file. Most of our source files were in the 5-10K range
(i.e. entire file read at once). Assemble + link rate was approximately 3
Meg_of_source/sec for a reasonable 486.
email@example.com -- Massively Scalar Compiler Group, Rice University
Return to the
Search the comp.compilers archives again.