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.


Other languages for which compilers that target C exist are: Common Lisp,
Fortran, Scheme, ML, Sather, Eiffel, CLU, Mesa, Russell, ...


> Some of the reasons I can see in favor of such an approach are:
> ...


> However, such an approach might also suffer from:
> ...
> (2) Efficiency is dictated to a large degree by the target C
>Compiler,


This can often be a major advantage of using C as an IL. The manufacturer
usually supplies a decent C compiler, which was written with full
knowledge of machine pipeline constraints, etc. These are often not fully
available to somebody else.


> (3) Translation in some situations might involve clumsy data
>structures and thus loss of efficiency.


> The second reason is especially important because the many C
>Compilers seem to suffer from the tough problems of aliases and side
>effects in interprocedural analysis (except in some cases).


Note that this matters only for those optimizations that can't easily be
expressed at the C source level. Most of the above compilers, especially
for languages like Scheme, try to perform a reasonable number of higher
level optimizations before they generate the C code.


> Now my questions:
> (1) I am looking for examples in which using C as IL will lead to
>inefficiencies,


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. But the C
standard does not guarantee that C compiler optimizations are safe in the
presence of such a collector. Probably most such current implementations
don't fully address this problem, and use a conservative collector anyway,
and get away with it. (David Chase and I have some ideas on fixing this
with almost no cooperation from the C compiler. Details available on
request.)


b) Languages such as Scheme that "require" tail recursion elimination are
problematic. It's hard to perform that optimization at the C source level
without losing performance, or generating huge monolithic functions that
tend to exceed C compiler limits. 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.


My impression is that for vaguely Pascal-like languages (e.g. Mesa),
compiling through C generally loses very little performance, and may in
fact win, if it's done sufficiently carefully. For Scheme or ML-like
languages, life is a little harder. You either lose some performance, or
you have to make some other compromises.


> (2) I want to know whether any other language has been used as
>extensively as C for IL,
> (3) I want to learn about the efforts to evolve efficient ILs
>(just like IFs) for procedural languages.


>[In answer to question 2, I expect that there are a lot more langauges
>that use Fortran as intermediate code than ones that use C. Fortran has
>been around longer and lets you do lots of gross low level hacks that you
>always seem to want in intermediate code. -John]


This hasn't been true recently, I think. I can only come up with one or
two uses of Fortran as an intermediate language, and that is for rather
special purpose source languages.


Hans-J. Boehm
(boehm@parc.xerox.com)
--

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