Requirements for IL's

eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig)
Fri, 31 Jul 1992 21:16:47 GMT

          From comp.compilers

Related articles
Re: Pros and cons of high-level intermediate languages tarvydas@tsctrl.guild.org (1992-07-23)
Re: Pros and cons of high-level intermediate languages gat@forsight.jpl.nasa.gov (1992-07-29)
Requirements for IL's eifrig@beanworld.cs.jhu.edu (1992-07-31)
Re: Requirements for IL's boehm@parc.xerox.com (1992-08-03)
| List of all articles for this month |

Newsgroups: comp.compilers
From: eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig)
Organization: The Johns Hopkins University CS Department
Date: Fri, 31 Jul 1992 21:16:47 GMT
References: 92-07-107 92-07-082
Keywords: translator, design

There's been quite a bit of talk recently concerning the pro's and
con's of using C as an intermediate language. One thing that can't be
denied, however, is that compilers for non-trivial languages (like ML and
Common Lisp) have been made using C as an intermediate language, and that
these compilers have achieved a fair degree of efficiency, sometimes even
surpasing compilers producing machine code directly (for some classes of
input programs.)


To me, this seems strong evidence that the use of architecture-
independent intermediate language for multiple source languages is a
reasonable approach to compiler design, even if C is not the best IM
language to use.


Which naturally brings me to my question: what features do people
feel an intermediate language should have? And what level of abstraction
should the language aim for? Which optimizations should be performed by
the source-to-IM compiler, and which to the IM-to-object compiler?


One idea that pops into my head is a language designed for
implementing CPS-based compilers: it would use a "continuation call"
(basically a non- returning, parameterized jump) as its only control
feature, but otherwise be very similar to C. Aggregate data structures
(aka "structs") would be supported, but the language would be weakly
typed. An automatic heap would be provided, with implicit garbage
collection.


The IM-to-object compiler would be responsible for register
allocation and common-subexpression elimination, since these optimizations
are highly dependent on the target architecture. Everything else is up to
the source-to-IM compiler.


This is basically C, with the addition of a garbage-collected
heap, and the elimination of the run-time stack.


Comments?


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Jack Eifrig (eifrig@cs.jhu.edu) The Johns Hopkins University, C.S. Dept.
[Universal intermediate languages have a long and not very happy history,
ranging from the original UNCOL in the 1950s to the current OSF ANDF. -John]
--


Post a followup to this message

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