Re: incremental compilation via shared library

dave@yost.com (Dave Yost) writes:


>I don't travel these parts often, but I've been wondering...
>Isn't it time compilation became as easy as making a subroutine call?


>I think it would be great if there were shared libraries that
>offered incremental compilation services. You would call a
>service function and pass it a code object, which includes slots
>for:
> * Source code in one or more representations, e.g.
> * some visual representation
> * source C
> * preprocessed C
> * assembler
> * Abstract representation (AR) (a database) which holds
> * information needed for generating machine code
> * correspondences between source code and AR fragments
> * correspondences between AR fragments and offsets into
> machine code for execution visualization (a.k.a. debugging)
> and linking
> * warnings and error messages tied to their sites in the AR
> and thus to their sites in source code
> * Executable object code (for one or more target CPU architectures)
>Some services might include:
> * translate source from language syntax xyz into AR.
> This service, traditionally called the "front end" would be
> left for the implementor of the source language to provide,
> though translators for ISO C would proabably be widely available.
> * translate AR into machine code for one or more target CPU architectures
> * link two or more code objects together for common execution
> * disassemble AR into assembly source code
> * disassemble machine code into AR
> * control execution of the machine code (set breakpoints, step, etc.)


>A traditional batch compiler could be implemented as a shell
>that sends source text to some services from the shared library,
>then dumps out asm and/or object files.


>Compilation could become more ubiquitous and more interactive.
>Programming environments supporting incremental compilation could
>flourish--they could concentrate on making great tools for
>humans, starting at a much higher level.


>C is being used as a portable assembler today by compilers for
>such languages as Eiffel, Modula-3, C++, Scheme, etc. If we had
>an extensible, standardized object definition such as what I
>propose, with services made available in shared libraries,
>implementers of new languages could break free of the batch
>nature of existing C tools, and they could easily implement
>dynamic programming environments on top of existing compilation
>and debugging tools.


In principle this is a good idea, and some time before I had similar ideas.


Some years ago we implemented in our group (Institute of Informatics at the
Academy of Sciences) an incremental compiler for MODULA-2.


The complete programming environment consists of


- an editor: recognizes all the changes in the source text and administrates
    a mapping between text and tree


- an incremental compiler: replaces the changed subtrees by newly compiled
    ones (on statement level) and replaces the object code (on procedure
    level)


    In case of errors there was an immediate interaction between compiler
    and editor to simplify the error correction.


- a unparser: regenerates the source text from the attributed tree (to avoid
    a permanent map between source text and tree).


This approach worked very well. The compilation speed was normally many times
higher than before (increased from - say 1000 lines/minute to 10000 or so in
dependence from the changes in the text).


There exists a few other systems in the world working with a scheme similar
to this.


The main problems in such systems are the following:


1. You has to use always the same environment for updating your source text.
      This seems to be a simple thing but restricts your freedom. It's more
      difficult to reach consistency. Note: there are a lot of people in love
      with 'vi'.


2. The implementation of such systems is not so simple as people thinks.
      Especially in the case of any errors it's sometimes a little difficult
      to avoid inconsistent states.


3. The most interesting thing in incremental compilers is the high
      compilation speed to avoid waiting time (== lost time). Some people say:
      the current hardware is so very fast that all such tricks are not necessary.
      I'm not convinced by this argument because I'm dayly waiting a lot of
      minutes for the results of compilation processes.


4. There are many possibilities to increase the speed of compilers
      (see Lecture Notes of Computer Science 371). I have the impression that
      the compilers will be slower every day than faster. This is a little
      surprising. The available resources don't help in using very efficient
      data structures and algorithms.


5. But I'm using C and develop a Fortran 90 compiler. Both languages are much
      more difficult as MODULA-2. C uses the terrible preprocessing. I think
      there are no possibilities to avoid this step if you want to develop
      an incremental C compiler.


      And Fortran 90 is a language with distributed declarations. It should be
      difficult to implement a truly incremental compiler (for declarations
      also).


I'm not happy that from my experience I have to say that incremental compilers
have a bad future. Sorry!


By the way: in principle it should be possible to distribute to interested
users a copy of our incremental compiler. It runs on PC's under DOS.
The system is untouched for years and therefore only usable to gather
experiences in incremental compilation.


I hope this will help to conclude the discussion about incremental compilation
(or to animate?).


Best regards


Werner Assmann


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Werner Assmann
Gesellschaft fuer Mathematik und Datenverarbeitung mbH
Forschungsinstitut fuer Rechner- und Softwaretechnologie (FIRST)
Rudower Chaussee 5
D - 12489 Berlin
Germany


Telefon: (49-30) 63921909
Telefax: (49-30) 63921805
email: assmann@first.gmd.de
--

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