Re: Incremental Compilers/Linkers

tmb@ai.mit.edu (Thomas M. Breuel)
Tue, 23 Mar 1993 02:52:22 GMT

          From comp.compilers

Related articles
Incremental Compilers/Linkers elan@tasha.cheme.cornell.edu (1993-03-19)
Re: Incremental Compilers/Linkers c1dje@watson.ibm.com (1993-03-22)
Re: Incremental Compilers/Linkers tmb@ai.mit.edu (1993-03-23)
Re: Incremental Compilers/Linkers hugh@cosc.canterbury.ac.nz (1993-03-25)
Re: Incremental Compilers/Linkers eliot@dcs.qmw.ac.uk (1993-03-24)
| List of all articles for this month |

Newsgroups: comp.compilers
From: tmb@ai.mit.edu (Thomas M. Breuel)
Keywords: linker
Organization: MIT Artificial Intelligence Lab
References: 93-03-071
Date: Tue, 23 Mar 1993 02:52:22 GMT

elan@tasha.cheme.cornell.edu (Elan Feingold) writes:
| Does anyone have any information on any compilers that do incremental code
| generation?
[...]
|> Techniques such as incremental compiling and true dynamic linking seem to
|> offer such an increase in performance that I'm surprised that they are so
|> rare.


Many systems do this, mostly for languages like Lisp and SML. Such
languages generally have been designed with incremental compilation in
mind. Doing the same for a language like C/C++ would probably raise some
difficult semantic/user interface problems.


|> It would seem to me at first glance that one of the prerequisites for such
|> a system would be a tightly integrated development system (editor,
|> compiler, linker) with emphasis on the editor<->compiler relationship.


Yes, to fully take advantage of such a system, you need an editor which
knows about sending meaningful parts of code to the compiler. The systems
I'm most familiar with are based on the Lisp machine and GNU Emacs. If
you want to experiment with this, you might want to get a copy of CMU
CommonLisp, the CMU Ilisp modes (see the Lisp FAQ), NJ/SML
(research.att.com:dist/ml) and GNU Emacs (prep.ai.mit.edu:pub/gnu).


Incremental compilation is nice not only because it reduces compilation
times, but also because you can keep state around while you are debugging.
Its main disadvantages are that it tends to lead to bulky runtime systems
and that it can on occasion lead to unobvious behavior precisely because
you don't start debugging with an identical initial state every time.
Ultimately, you probably want both: incremental compilation for
development, and batch compilation for delivery.


In my opinion, more interesting than the rather commonplace incremental
compilation is generating object code at runtime. This gives the compiler
the opportunity to gather runtime statistics and generate optimized code
accordingly. All systems that take advantage of runtime statistics that I
know of require a two-stage process consisting of the manual gathering of
profiling information followed by an optimizing compilation. Integrating
these two steps at runtime would yield a system that only compiles what
needs to be compiled and even adapts to changing patterns in the input
data. The only commonly used, related technique that I know of is
Smalltalk's backpatching. Is there any recent work that I don't know of?


Thomas.
--


Post a followup to this message

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