Re: UNCOL = Uncool? (Fergus Henderson)
26 Oct 2000 02:43:34 -0400

          From comp.compilers

Related articles
[2 earlier articles]
Re: UNCOL = Uncool? (2000-10-22)
Re: UNCOL = Uncool? (Peter Gammie) (2000-10-23)
Re: UNCOL = Uncool? (2000-10-23)
Re: UNCOL = Uncool? (Daniel C. Wang) (2000-10-23)
Re: UNCOL = Uncool? (Chris F Clark) (2000-10-23)
Re: UNCOL = Uncool? (2000-10-26)
Re: UNCOL = Uncool? (2000-10-26)
Re: UNCOL = Uncool? (Pred.) (2000-10-26)
Re: UNCOL = Uncool? (2000-10-26)
Re: UNCOL = Uncool? (Chris F Clark) (2000-10-31)
Re: UNCOL = Uncool? (2000-10-31)
Re: UNCOL = Uncool? (2000-11-04)
| List of all articles for this month |

From: (Fergus Henderson)
Newsgroups: comp.compilers
Date: 26 Oct 2000 02:43:34 -0400
Organization: Computer Science, University of Melbourne
References: 00-10-185
Keywords: UNCOL

Chris F Clark <> writes:

>The problems with UNCOL's are always in the details. Having worked on
>more than 1 multi-language, multi-target compiler, I have seen this
>first hand.
>the general solution is that one language is actually the
>core and all the others are simply appendages or warts.

Right. For .NET, C# is that core language; it was designed in
conjunction with the MSIL intermediate language and the common type
system, and pretty much every construct in C# maps fairly directly to
MSIL and pretty much every construct in MSIL can be expressed in C#.
In constrast, other languages may not map nearly so directly onto that
core. Even Microsoft's own Visual Basic has had to change quite a bit
in order to map more directly to MSIL.

So, the question is how well the other languages can be mapped to the
core language. Compiling from source L to target T via some
intermediate UNCOL is in general not going to be as efficient as a
native compiler from L to T could be, unless the UNCOL was designed
with L and T in mind. But if the difference is just a small matter of
efficiency, then it may not matter!

Efficiency is becoming less and less important, and things like
interoperability and code reuse are becoming more and more important.
These days no-one is really going to care that much if e.g. calls to
variable-argument functions are a little bit slow. We have incredibly
fast processors to throw at that problem.

So I think the trade-offs are shifting towards increasing acceptance
of UNCOLs of various kinds. And while mapping down to an UNCOL that
doesn't suit your source language may require some extra complexity,
the extra complexity required is often much less than what would be
required to write your own native code compiler and run-time system,
especially if you want to support multiple targets. And by reusing an
existing platform, you leverage the benefits of any future
improvements that are made to them.
Fergus Henderson <> | "I have always known that the pursuit
                                                                        | of excellence is a lethal habit"
WWW: <> | -- the last words of T. S. Garp.

Post a followup to this message

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