Re: Using C as an UNCOL

Darius Blasband <>
21 Jun 1996 17:08:41 -0400

          From comp.compilers

Related articles
Re: Java virtual machine as target language for C/C++ (1996-05-08)
Re: Java virtual machine as target language for C/C++ (Daniel C. Wang) (1996-05-27)
Re: Using C as an UNCOL (Toon Moene) (1996-06-09)
Re: Using C as an UNCOL (Dave Lloyd) (1996-06-13)
Re: Using C as an UNCOL (Daniel C Wang) (1996-06-14)
Re: Using C as an UNCOL (1996-06-21)
Re: Using C as an UNCOL (Darius Blasband) (1996-06-21)
| List of all articles for this month |

From: Darius Blasband <>
Newsgroups: comp.compilers
Date: 21 Jun 1996 17:08:41 -0400
Organization: Phidani Software, Brussels
References: 96-05-061 96-05-163 96-06-044 96-06-054 96-06-066
Keywords: C, UNCOL

Daniel C Wang wrote:
> Dave Lloyd <> writes:
> {stuff deleted}
> > In summary, C is sufficient as an intermediate, but it is too poor for
> > high-performance compilers of larger languages.
> There are lots of langauges that don't need high-performance compilers and
> rather be portable. I'm personally of the opinion that for that large subset
> of langauges an UNCOL that has some of the same properties that makes C good
> for such a job with fixes for things that make C a pain is only a matter of
> engineering. So I'm puzzled why someone hasn't done it yet. Has ANDF and
> other failed attempts left such a bad taste in everyone's mouth?

I guess it depends on the kind of language. Mercury shows quite clearly that
when the language to compile is intrinsically different from the common
procedural languages we are used to, it takes quite a lot of low-level tricks
to generate good code, up to the point where they are badly dependant on gcc.
On the other hand, for more common languages (or at least, languages with a
more common procedural origin), generating C can prove very efficient.

YAFL is an OO language with garbage collector, but which remains a truly
Algol-like language when it comes to microscopic code (expressions,n loops,
etc...). Our compiler generates intermediate C code, where YAFL integers are
represented by plain C integers, expressions can be translated in a pretty
straightforward way, etc... I have no formal evidence of this, but my guess
is that there would be little to gain from generating native code directly,
except maybe for a few features that could not be mapped gracefully in C and
where one can expect a native implementation to be more efficient (For
instance, nested procedures and garbage collection handling - YAFL's GC is
precise, and requires that some information regarding the current state of
allocation is maintained at runtime).



Post a followup to this message

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