Re: UNCOL = Uncool?

Fergus wrote:
> Efficiency is becoming less and less important, and things like
> interoperability and code reuse are becoming more and more important.
. . .
> 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.


While sometimes the faster processor argument is sometimes overplayed,
in this case I think Fergus is right. For most languages on most
targets you don't care about the slight performance hit that using an
UNCOL enforces. That's why the TSI, MIPS, and Gnu suites have been
successful over the years (since the early 80's in fact). Most of the
time, just being able to use the language of choice on the platform of
choice is all anyone cares about.


Moreover, with any of the above choices one gets an "optimizing"
compiler for each of the supported languages for just the price of a
single code generator port. That's a lot cheaper than writing
n-optimizing compilers for your target. Further, an optimizing UNCOL
based compiler might produce better code for your target than an
unoptimizing native compiler (which might be the other viable choice
given "time-to-market" and other considerations). It is no surprise
that many hardware vendors have chosen various UNCOL based compiler
suites as their basic compilation system.


Some compiler researchers have found the same argument works for them
in its own way. If I recall correctly, Mercury outputs C (with gcc
extensions) (or did at one point) as its UNCOL. The original VCS
compiler from Synopsys output C also. I'm working on a compiler
project that outputs C++ as it's UNCOL. I'm sure the list goes on.


That, of course, brings this discussion full-cycle (or ties it with
another). C can be used as an UNCOL, although it can impose a
penalty. However, that cost is much cheaper than the cost of no
compiler at all.


Hope this helps,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
3 Proctor Street voice : (508) 435-5016
Hopkinton, MA 01748 USA fax : (508) 435-4847 (24 hours)

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