Re: Pros and cons of high-level intermediate languages

bbx!bbx.basis.com!scott@unmvax.cs.unm.edu (Scott Amspoker)
Wed, 22 Jul 1992 15:54:48 GMT

          From comp.compilers

Related articles
Pros and cons of high-level intermediate languages ssp@csl36h.csl.ncsu.edu (1992-07-20)
Re: Pros and cons of high-level intermediate languages boehm@parc.xerox.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 bbx!bbx.basis.com!scott@unmvax.cs.unm.edu (1992-07-22)
Re: Pros and cons of high-level intermediate languages shankar@sgi.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 fjh@munta.cs.mu.OZ.AU (1992-07-23)
Re: Pros and cons of high-level intermediate languages tmb@idiap.ch (1992-07-23)
Re: Pros and cons of high-level intermediate languages henry@zoo.toronto.edu (1992-07-23)
Re: Pros and cons of high-level intermediate languages tarvydas@tsctrl.guild.org (1992-07-23)
[24 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: bbx!bbx.basis.com!scott@unmvax.cs.unm.edu (Scott Amspoker)
Organization: BASIS International, Ltd., Albuquerque NM USA
Date: Wed, 22 Jul 1992 15:54:48 GMT
References: 92-07-064 92-07-068
Keywords: translator, design

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


Post a followup to this message

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