|Is this a new idea? M.J.Landzaat@fel.tno.nl (1992-10-28)|
|Re: Is this a new idea? email@example.com (1992-10-31)|
|Re: Is this a new idea? firstname.lastname@example.org (1992-11-02)|
|Re: Is this a new idea? email@example.com (1992-11-03)|
|Re: Is this a new idea? firstname.lastname@example.org (1992-11-03)|
|Re: Is this a new idea? email@example.com (Byron Rakitzis) (1992-11-04)|
|Re: Is this a new idea? ttk@ucscb.UCSC.EDU (1992-11-04)|
|Re: Is this a new idea? firstname.lastname@example.org (1992-11-04)|
|[13 later articles]|
|From:||email@example.com (Jawaid Bazyar)|
|Organization:||Colorado SuperNet, Inc.|
|Date:||Sat, 31 Oct 1992 01:59:40 GMT|
|Keywords:||performance, question, comment|
M.J.Landzaat@fel.tno.nl (Maarten Landzaat) writes:
>While waiting for my compilation to finish for the 30th time, I concocted
>the following dream compiler:
>one that during my editing, reads the program text I typed in so far, and
>tries to compile and link it as much as it can in the background, with low
>priority so nobody gets bad response.
>So when I finally type "cc", most of the work will already be done, and it
>will complete much faster.
>Has this technique a name? Has it already been implemented in some
The only technique that I can think of that's similar to this is called
"pre-tokenization", and can be used to speed up a compile significantly in
some types of languages. Basically, you have an editor which tokenizes
the source as you type. Tokenization is, of course, the part of compiling
that breaks a source program into the individual symbols and what not.
When you compile, the editor sends the compiler the pre-tokenized source
instead of the actual source. Not only are you using less disk bandwidth
(instead of "IMPLEMENTATION" the editor passes a single word), but the
lexing phase has disappeared, making parsing a simple scan through a
linear array of tokens.
How much speed increase you get depends on the complexity of other parts
of the compiler. The speedup for an assembler is massively better than
the speedup for, say, a C compiler. The difference is that there is much
more work after lexing/parsing for high level language compilers.
The pre-tokenization method was used successfully in the Apple II 6502
assembler "LISA" which achieved assembly rates of 100,000 lines per
minute. I believe it was also used in an Apple II Pascal implementation
(the editor automatically boldfaced keywords and such, so I presume it was
P.O Box 620334
Littleton, CO 80162-0334 (303) 933-4649 firstname.lastname@example.org
[Bill McKeeman and Shota Aki at DEC have been working on reusable incremental
scanning, preprocessing, and parsing, by tracking changes to source (with a
smart editor of some sort) and only redoing what needs to be redone. Read
all about it in the JCLT. -John]
Return to the
Search the comp.compilers archives again.