From: bbx!bbx.basis.com!scott@unmvax.cs.unm.edu (Scott Amspoker)
Newsgroups: comp.compilers
Subject: Re: Pros and cons of high-level intermediate languages
Keywords: translator, design
Date: 22 Jul 92 15:54:48 GMT
Article-I.D.: comp.92-07-070
Reply-To: bbx!bbx.basis.com!scott@unmvax.cs.unm.edu (Scott Amspoker)
Organization: BASIS International, Ltd., Albuquerque NM USA

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.

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
     procedures).

   * Never approach such a project thinking that all you're doing is
     creating a "front end".  Treat it as you would any native code
     compiler.

   * 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.

-- 
Scott Amspoker
Basis International, Albuquerque, NM
scott@bbx.basis.com
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.