Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| 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] |
| 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
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.