Re: Incremental Compilers

Nick Rothwell <nick@lfcs.ed.ac.uk>
Fri, 27 Jan 89 11:09:06 GMT

          From comp.compilers

Related articles
[5 earlier articles]
Re: Incremental Compilers HSauro@fssc.demon.co.uk (Herbert M Sauro) (2000-05-12)
Re: Incremental Compilers mkent@acm.org (Mike Kent) (2000-05-12)
Re: Incremental compilers brunix!apollo!alan (Alan Lehotsky) (1986-09-18)
Incremental compilers charlie@genrad.com (1989-01-24)
Re: Incremental compilers ti-csl!csc.ti.com!pf@cs.utexas.edu (Paul Fuqua) (1989-01-15)
Re: Incremental compilers rogerson@PEDEV.Columbia.NCR.COM (1989-01-26)
Re: Incremental Compilers nick@lfcs.ed.ac.uk (Nick Rothwell) (1989-01-27)
| List of all articles for this month |

From: Nick Rothwell <nick@lfcs.ed.ac.uk>
Date: Fri, 27 Jan 89 11:09:06 GMT

Charlie D. Havener (charlie@genrad.com) writes:
>I would like to stimulate some discussion in this group about incremental
>compilers and fine grained interpreters for block structured languages. Fine
>grain means it incrementally changes the compiled or interpretive code ( like
>reverse polish ) on a line by line basis instead of a file basis.
>...
>Does anyone know of other examples of fine grained
>incremental compilers or interpreters?


I presume that an interpreter for a (block structured) expression-based
language would fit your criterion - or are you thinking of a situation
where *a part* of a complete object (say, one line of a procedure) can
be compiled and replaced in isolation?
      Standard ML does incremental compilation (as do many interactive
systems) - expressions/declarations are compiled into functions which
the compiler can then call like any other function, to evaluate them.
Interestingly, the code generator itself does *not* require any
nonstandard features of the language or host system: it is simply a
function from lambda-expressions (an intermediate representation) to
strings, the string containing the correct machine opcodes. There's a
simple bootstrap call to turn a string into a function with that
string's contents as code. ML is statically scoped, so there isn't
really a concept of "replacement" of code - recompiled
functions/modules supercede existing ones for subsequent declarations;
the old declarations vanish by garbage collection as they disappear
from the symbol table.
      Perhaps this is veering from your original subject area. I'll gladly
go into further details if there's interest.


Nick.
--
Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh.
nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick
--


Post a followup to this message

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