|Pros and cons of high-level intermediate languages firstname.lastname@example.org (1992-07-20)|
|Re: Pros and cons of high-level intermediate languages email@example.com (1992-07-21)|
|Re: Pros and cons of high-level intermediate languages chased@rbbb.Eng.Sun.COM (1992-07-21)|
|Re: Pros and cons of high-level intermediate languages firstname.lastname@example.org (1992-07-22)|
|Re: Pros and cons of high-level intermediate languages email@example.com (1992-07-23)|
|Re: Pros and cons of high-level intermediate languages Olivier.Ridoux@irisa.fr (1992-07-23)|
|Re: Pros and cons of high-level intermediate languages firstname.lastname@example.org.OZ.AU (1992-07-23)|
|Re: Pros and cons of high-level intermediate languages email@example.com (1992-07-23)|
|Re: Pros and cons of high-level intermediate languages firstname.lastname@example.org (1992-07-23)|
|Re: Pros and cons of high-level intermediate languages email@example.com (1992-07-23)|
|[24 later articles]|
|From:||firstname.lastname@example.org (Scott Amspoker)|
|Organization:||BASIS International, Ltd., Albuquerque NM USA|
|Date:||Wed, 22 Jul 1992 15:54:48 GMT|
email@example.com (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.
We've been using C as an IL for an object-oriented data processing
language which includes Mesa-style exception handling (quite elegant but
tricky to implement). Here are a few odds and ends we have discovered
about using C as an IL:
* Generating C code can sometimes be more tedious than generating
assembler. Identifiers generally must be preserved and properly
used and scoped in the C code. Structures have field names - not
merely a list of offsets. Also, you must either second guess the
host C implementation (i.e. alignment and sizeof() stuff) or
generate 100% symbolic code - either approach has its problems.
Local identifiers (especially typedefs) sometimes have to be moved
outside a procedure so they can be accessed by additional
compiler-generated procedures (or re-created locally within those
* Never approach such a project thinking that all you're doing is
creating a "front end". Treat it as you would any native code
* I quickly developed a deep appreciation for the C comma operator.
* The ANSI spec which renders stack variables unpredictable after
a longjump() sucks. This is solved by declaring them 'volatile'
but then you might lose bigtime in the optimizer.
* The lack of a global 'goto' makes certain things a little less
efficient. This is especially true for generating glue routines
to fix the "this" pointer enroute to a virtual method.
* Some C compilers can certainly improve the way they pass small
structures to and from functions.
All in all I think using C as an IL is a smart way to go for many, if not
most, applications. We have better things to do than to re-invent a
native code generator and its associated optimizer for each new platform.
It's true that there can be some performance penalties. Some of these
penalties can be blamed on C itself. However, most of them come from
using some of the high-level features provided by the "front end language"
which generates the C code. Such performance degradation can be minimized
by using a little common sense and is (IMHO) more than offset by the
productivity gains reaped from using high-level features. As usual, the
secret to success is to know where most of the work is being done and
concentrate on those areas.
Basis International, Albuquerque, NM
Return to the
Search the comp.compilers archives again.