Re: UNCOL again, was A microcontroller-centric, target-neutral

johnl@iecc.com (John R. Levine)
25 Jul 2003 21:18:39 -0400

          From comp.compilers

Related articles
A microcontroller-centric, target-neutral programming language petegray@ieee.org (Pete Gray) (2003-07-15)
Re: A microcontroller-centric, target-neutral programming language mark.piffer@chello.at (2003-07-21)
Re: A microcontroller-centric, target-neutral programming language petegray@ieee.org (Pete Gray) (2003-07-23)
Re: UNCOL again, was A microcontroller-centric, target-neutral johnl@iecc.com (2003-07-25)
| List of all articles for this month |

From: johnl@iecc.com (John R. Levine)
Newsgroups: comp.arch.embedded,comp.compilers
Date: 25 Jul 2003 21:18:39 -0400
Organization: I.E.C.C., Trumansburg NY USA
References: 03-07-103 03-07-159 03-07-165
Keywords: UNCOL, history
Posted-Date: 25 Jul 2003 21:18:39 EDT

>An additional (and significant) benefit to this design is that once a
>suitable n-code scheme is adopted, compilers for "other" high-level
>languages could be developed to generate n-code. The point here being that
>when these new compilers are developed, they will already be able to support
>targets for which "n-code to assembly language translators" have been
>developed.


This particular idea was invented in the 1950s under the name UNCOL.
The original UNCOL project failed, and similar attempts have failed
over and over in the past half-century, most recently as the ANDF
project.


The problem is that even with 50 years of work, we don't know how to
write an intermediate language that's simultaneously expressive enough
to capture an interesting set of source languages, while being
abstract enough to translate to efficient code for a wide range of
targets.


The usual trajectory of failure is that people start with a few
semantically similar source languages and architecturally similar
target architectures, and it works fine. (Building a system that can
compile C, C++, Fortran, and Ada to 32 bit byte addressed micros that
use ASCII character codes isn't hard. If that's what you need, use
GCC.)


They announce their results with wild enthusiasm. Then as they try to
add more languages and more targets, the intermediate code becomes
increasingly encrusted with special-case hacks until it dies of heat
death and its proponents slink away.


So please be sure you have an intermediate representation that handles
C++, Scheme, and Cobol, and can be translated to Itanium, Burroughs A
series, and IBM S/390 (with EBCDIC characters). If you can't, I
wouldn't bother.


Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner
"More Wiener schnitzel, please", said Tom, revealingly.


Post a followup to this message

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