Re: Non-sequential compilation.

cliffc@rice.edu (Cliff Click)
Tue, 21 Sep 1993 16:43:49 GMT

          From comp.compilers
Related articles
Non-sequential compilation. KODIS@delphi.com (1993-09-18)
Re: Non-sequential compilation. macrakis@osf.org (1993-09-21)
Re: Non-sequential compilation. cliffc@rice.edu (1993-09-21)
Re: Non-sequential compilation. pcg@aber.ac.uk (1993-09-21)
Re: Non-sequential compilation. conway@mundil.cs.mu.OZ.AU (1993-09-22)
Re: Non-sequential compilation. gafter@mri.com (1993-09-27)
Re: Non-sequential compilation. rbe@yrloc.ipsa.reuter.COM (1993-10-04)
| List of all articles for this month |
Newsgroups: comp.compilers
From: cliffc@rice.edu (Cliff Click)
Keywords: design
Organization: Center for Research on Parallel Computations
References: 93-09-068
Date: Tue, 21 Sep 1993 16:43:49 GMT

KODIS@delphi.com writes:


      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.


Cliff
--
cliffc@cs.rice.edu -- Massively Scalar Compiler Group, Rice University
--

Post a followup to this message

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