Re: Using C as an UNCOL

Daniel C Wang wrote:
> Dave Lloyd <dave@occl-cam.demon.co.uk> 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).


Regards...


Darius
--

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