Re: Intermediate Representation

Eric Muller <muller@procope.pa.dec.com>
Tue, 14 Aug 90 16:38:03 GMT

          From comp.compilers

Related articles
[12 earlier articles]
Re: Intermediate Representation jouvelot@brokaw.lcs.mit.edu (1990-08-12)
Re: Intermediate Representation convex!csmith@uunet.UU.NET (1990-08-12)
Re: Intermediate Representation preston@titan.rice.edu (1990-08-13)
Re: Intermediate Representation preston@titan.rice.edu (1990-08-13)
Re: Intermediate Representation jouvelot@brokaw.lcs.mit.edu (1990-08-13)
Re: Intermediate Representation marti@antares.inf.ethz.ch (1990-08-13)
Re: Intermediate Representation muller@procope.pa.dec.com (Eric Muller) (1990-08-14)
Re: Intermediate Representation pd@complex.Eng.Sun.COM (1990-08-15)
Re: Intermediate Representation staff@cadlab.sublink.org (1990-08-18)
Re: Intermediate Representation ok@goanna.cs.rmit.OZ.AU (1990-08-20)
intermediate representation han@cs.rochester.edu (1991-02-20)
Re: intermediate representation lavinus@csgrad.cs.vt.edu (1991-02-22)
Re: intermediate representation mike@vlsivie.tuwien.ac.at (1991-02-23)
[3 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: Eric Muller <muller@procope.pa.dec.com>
Keywords: C, modula, code, translator
Organization: DEC Systems Research Center
Date: Tue, 14 Aug 90 16:38:03 GMT

In article <1990Aug13.214614.16644@esegue.segue.boston.ma.us>, marti@antares.inf.ethz.ch writes:


|> Many language designers/implementors have turned to using C as an
|> intermediate representation language, for example in the following
|> research projects and/or products:
|> ...
|> - Modula-3 compilers developed at DEC SRC and the (now defunct?) Olivetti
|> Research Center
|>
|> Compilation speed using C as an IRL may not be overwhelming, but this
|> solution is certainly portable. Of course, the quality of the generated
|> machine code depends substantially on on the C compiler used as a backend.


I am working on the SRC Modula-3 system. Bill Kalsow wrote most of the
compiler before I joined and he chose C to achieve portability. This
certainly works: our system runs on VAX/Ultrix, DECstation/Ultrix,
SPARC/SunOs, Apollo DN 4500/DomainOs, IBM R6000/AIX 3.1, AIX/PS2, IBM RT/IBM
4.3, HP 9000/300/HP-UX, without too much pain.


However, we do not view C as an intermediate language, but rather as a
portable assembler. The compiler maintains a private AST as the intermediate
representation.


The speed of compilation is not too bad: the Modula-3 to C compilation time
is of the same order as the C to .o compilation. The quality of generated
code depends a lot on the quality of the C compiler. This should not be very
surprising, as we are trying to have a simple compiler: many intermediate
expressions become separate assignments in C, for example. I have compared
the assembly generated for equivalent Modula-3 and C programs, using the -O2
optimizations of /bin/cc on a DECstation; in many cases, the same assembly
is generated. We may spend some time to further improve that aspect.


One of the advantages of generating C is that we can assume some runtime
support. Modula-3 has exceptions and requires the presence of a Thread
module (lightweight processes). setjmp/longjmp are enough to implement that.


My own conclusion is that generating C or using a native back-end does not
influence that much the quality of the generated code. Choosing one way or
the other is a compromise between compilation speed and portability.


Eric Muller.
------------------------------------------------------------------------------
System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193
--


Post a followup to this message

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