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

          From comp.compilers

Related articles
UNCOL = Uncool? (SRS) (2000-10-19)
Re: UNCOL = Uncool? (Daniel C. Wang) (2000-10-22)
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:42:56 -0400
Organization: Computer Science, University of Melbourne
References: 00-10-139 00-10-150 00-10-180
Keywords: UNCOL

Daniel C. Wang <> wrote

>Whatever it is.. it only has to be "sufficiently general" and I believe that
>there have been sufficiently general UNCOL's. The the idea of an UNCOL need
>not be frowned upon as "impossible".
>Look at Transmeta's approach They are using x86 as and "UNCOL" of sorts for
>their various different VLIW processors. So even x86 is "sufficiently
>general" for VLIW processors cores.

and our moderator replied

>[It has to be sufficiently general to handle some range of source
>languages and some range of target languages efficiently enough that
>people would want to use the compiler that results. If the only
>source languages you care about are C and Fortran, and the targets are
>32 bit little-endian byte addressed micros, it's not a hard job. If
>the source languages also include Cobol and Common Lisp, we don't know
>how to do it.
>I don't see Transmeta as very relevant since part of their goal is
>specifically to run x86 code so their system is tuned to make that work
>well. Source language semantics look like a harder problem than code
>generation anyway. -John]

I think our moderator missed the point here. x86 machine code is
Transmeta's UNCOL, not their source or target language. There are, as
we all well know, many compilers for many different source languages
to x86 machine code. the range of source languages is as broad as you
could imagine. And Transmeta is building dynamic compilers that
compile from x86 machine code to various different VLIW processor
targets. I guess the range of targets is fairly small at this point
(i.e. one for each different chip model that Transmeta ships), but it
is nevertheless "sufficiently general" for Transmeta's purposes.

Whether Transmeta is handling this range of source and target
languages efficiently enough that people want to use their chips is a
good question. Transmeta have chosen to compete for the low-power
market rather than the raw speed market. Whether they will be
commercially successful in the long run is unknown, but they seem to
be doing OK so far.
Fergus Henderson <> | "I have always known that the pursuit
                                                                        | of excellence is a lethal habit"
WWW: <> | -- the last words of T. S. Garp.
[Hmmn. Implementing a virtual machine code on a variety of back end hardware
isn't new, IBM's been doing it on S/38 and AS/400 for many years with great
success. It still seems to me that this is more x86 emulation, not really
UNCOL, but I agree that we're nearing the hair-splitting stage. And I'd
be really surprised if any of the Transmeta VLIWs weren't byte addressed
little endian machines, and fairly surprised if the word size wasn't 32
bits. -John]

Post a followup to this message

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