incremental compilation via shared library

dave@yost.com (Dave Yost)
Wed, 25 Aug 1993 18:14:20 GMT

          From comp.compilers

Related articles
incremental compilation via shared library dave@yost.com (1993-08-25)
Re: incremental compilation via shared library cliffc@rice.edu (1993-08-29)
incremental compilation via shared library brent@jade.ssd.csd.harris.com (1993-08-30)
Re: incremental compilation via shared library pardo@cs.washington.edu (1993-09-02)
Re: incremental compilation via shared library assmann@prosun.first.gmd.de (1993-09-03)
Re: incremental compilation via shared library brett@digits.enet.dec.com (1993-09-07)
Re: incremental compilation via shared library pop@dcs.gla.ac.uk (pop) (1993-09-07)
[6 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers,gnu.misc.discuss,comp.lang.c,comp.object
From: dave@yost.com (Dave Yost)
Keywords: design, OOP, question
Organization: Dave Yost's house
Date: Wed, 25 Aug 1993 18:14:20 GMT

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.


--
    Dave Yost
            @ .COM
--


Post a followup to this message

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