Re: How about VLIW used as RISC?

Ricardo Bugalho <>
8 May 2004 21:08:09 -0400

          From comp.compilers

Related articles
[3 earlier articles]
Re: How about VLIW used as RISC? (2004-04-29)
Re: How about VLIW used as RISC? (2004-04-29)
Re: How about VLIW used as RISC? (Alex Colvin) (2004-05-02)
Re: How about VLIW used as RISC? (glen herrmannsfeldt) (2004-05-02)
Re: How about VLIW used as RISC? (Stan Lass) (2004-05-02)
Re: How about VLIW used as RISC? (Sander Vesik) (2004-05-08)
Re: How about VLIW used as RISC? (Ricardo Bugalho) (2004-05-08)
Re: How about VLIW used as RISC? (glen herrmannsfeldt) (2004-05-09)
| List of all articles for this month |

From: Ricardo Bugalho <>
Newsgroups: comp.arch,comp.compilers
Date: 8 May 2004 21:08:09 -0400
Organization: Netvisao, A sua Internet por Cabo
References: 04-04-088 04-04-104 04-05-006
Keywords: architecture
Posted-Date: 08 May 2004 21:08:09 EDT

On Sun, 02 May 2004 21:49:59 -0400, glen herrmannsfeldt wrote:


> It seems that VLIW, even more than RISC, requires the compiler to know
> too much about implementation details.

CISC, RISC or VLIW, the simpler compiler can get by just by knowing
the ISA. But a VLIW ISA will have aspects that in RISC are just
implementation details. But for more sofisticated, optmizing
compilers, I don't think there are many differences. Just guessing

> I suggest, then, compiling to an intermediate representation close to,
> but not exactly, what the hardware needs to execute. An implementation
> independent representation. At program load time the code is examined
> and adapted to the specific implementation. For example, the
> appropriate number of branch delay slots are filled in, and instructions
> are reordered based on implementation specific timing.
> The final result may be VLIW, where each word contains many RISC type
> instructions that can be executed at the same time.

Sounds like what Transmeta is doing.

Anyway, I think it's useless to discuss compilers when the problem
lies below. At least in my book, VLIW differs from RISC only by
grouping multiple instruction in one large, fixed size, instruction
word with rules about what types of instruction may apper where and in
what combinations in the instruction word and with parallel semantics
for instructions within the instruction word.

For a CPU designed to execute exactly one instruction
word in order, it has three advantages I can think off:
a) In limited forms, it's possible to have different length instructions
without the decoding complexity of CISC. The most common benefit is
support for large immediated.
b) The rules about what kind and where instructions may be in the
instruction word make the scheduling simpler.
c) The parallel semantics also make the schedulling simpler.

But sooner or later, as the world evolves, you may find out that 1
instruction word (N instructions) per cycle isn't the ideal anymore
and your next generation CPU should be capable of executing more or
less than X instruction words per cycle, with X being a rational
number different than one (and greater than zero). Then advantage c)
becomes a problem. And b) goes out the window if X isn't integer.

That's why VLIW is only used when it's fairly easy to move to a new ISA
when needed.


Post a followup to this message

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