Re: UNCOL

pardo@cs.washington.edu (David Keppel)
21 May 1996 16:20:59 -0400

          From comp.compilers

Related articles
Re: Java virtual machine as target language for C/C++ kik@zia.cray.com (1996-05-08)
Re: Java virtual machine as target language for C/C++ rfg@monkeys.com (1996-05-19)
Re: Java virtual machine as target language for C/C++ pardo@cs.washington.edu (1996-05-19)
Re: UNCOL pardo@cs.washington.edu (1996-05-21)
Re: UNCOL patrick_d_logan@ccm.hf.intel.com (Patrick Logan) (1996-05-26)
Re: UNCOL dmason@scs.ryerson.ca (1996-06-08)
Re: UNCOL dave@occl-cam.demon.co.uk (Dave Lloyd) (1996-06-13)
| List of all articles for this month |
From: pardo@cs.washington.edu (David Keppel)
Newsgroups: comp.compilers
Date: 21 May 1996 16:20:59 -0400
Organization: Computer Science & Engineering, U of Washington, Seattle
References: 96-05-061 96-05-119 96-05-133
Keywords: Java, UNCOL

pardo@cs.washington.edu wrote:
>>[UNCOL says you *can* use a common virtual machine language, but it
>> also says there will be a performance penalty.]


John Levine (the moderator) wrote:
>[UNCOL-ish systems seem to work OK if you have a single source
> language, e.g. Smalltalk, or a single target, e.g. multiple compilers
> sharing a back end. It's when you try NxM that you get heat death.]


He's right, folks, I should clarify my earlier comments:


I believe that it should be workable to use a single IR for several
similar source languages and several similar back ends. For example,
one IR for Algol-class languages on 32-bit flat-address machines,
another IR for Smalltalk/SELF-class languages on microcontrollers (and
lest you think that's silly, there's a ST-80 variant that runs in 64K
of RAM on a Z-80). Thus, MxN languages is hard, but M/10 x N/10
languages might be both tractable and give reasonable efficiency (for
values of "reasonable" still less than single-source single-target
translation).


My "proof of concept" is the GNU CC compiler, which I recall has or has
had front ends written for C, C++ and FORTRAN (did I hear a rumor about
COBOL? Pascal?) and back ends for a wide variety of 32-bit processors.
The GNU CC IR contains constructs for a wide variety of "basic"
operations, plus a modest number of operations for language-specific
features (e.g., complex for FORTRAN, up-level addressing for Ada and
Pascal, ...). I belive the Multiflow compiler also supports multiple
front- and back-ends. As John points out, there are source language
constructs that GNU CC won't be able to take advantage of because the
IR doesn't represent the needed information. But in keeping with the
"some performance penalty", I think the code quality is still fair
across the range of intended sources and targets.


However, I predict heat death when somebody tries to use GNU CC to,
say, compile SELF :^)


To summarize, UNCOL is a hard problem; subsets are easier to solve; and
it is hard to provide both high efficiency and, at the same time, a
convincing argument that successful translation on one platform will
imply successful translation on other platforms.


;-D on ( Okay, okay: I'll say UNCOL! ) Pardo
--


Post a followup to this message

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