Re: Pros and cons of high-level intermediate languages

ssp@csl36h.csl.ncsu.edu (Santosh Pande) writes:
> I am interested in knowing the pros and cons of using an
>intermediate language (IL) in general. In particular I find 'C' has been
>used extensively as the IL in many situations: Modula, SISAL, AT&T Cfront
>for C++ etc.


My comment is based on using C as an IL for compiling LambdaProlog.
However, the specifics of LambdaProlog do not matter here.


boehm@parc.xerox.com (Hans Boehm):
> I know of three problems:
> a) (the one I'd personally most like to see fixed) The treatment of source
> languages that require garbage collection is tricky. It appears that the
> only way not to lose appreciably in performance (and this is a bit
> controversial) is to use a conservative garbage collector.


We use another way. All the memory management has been packaged into an
abstract memory. What the generated C programs do is to use this memory.


> b) Languages such as Scheme that "require" tail recursion elimination are
> problematic.


Like Prolog, LambdaProlog has a procedural semantics. Though we map
LambdaProlog procedures (predicates) on C functions, we do not map
LambdaProlog procedure calls on C function calls. In other words, we do
not map LambdaProlog stack on the C stack. We use instead the abstract
memory mentioned above.


My general idea is that when two concepts are only approximately
equivalent it is asking for problems to try mapping one onto the other.


> c) It's hard to efficiently implement a
> compilation strategy that allocates activation records in the heap. Some
> of the cleverer implementations of first-class-continuations are hard to
> express in C code.


The abstract memory again does the job. Our execution scheme is
continuation based. The continuations (there are four of them because of
non-determinism and other things) are all first-class objects.


I like to add a fourth problem:


d) There is no first-class label data-type. One can neither store and
read labels, nor goto stored labels. I know about switch-statements, but
it usually breaks the structure of the generated code. For this problem,
PL/1 would be a far better IL.


An optimistic final note. On one hand, the generated code seems to break
the admitted dimensions of human programming: huge identifiers made of
several layers of prefixes, tags or module names, huge expression (e.g. in
our scheme the unification subprogram of every clause is made in a single
conjunctive expression (&&)), etc. On the other hand, it is hard knowing
the limits of an actual C compiler. However, we never met them. In our
experiments, we only met problems with cpp.


Olivier Ridoux
(ridoux@irisa.fr)
--

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