Re: How about VLIW used as RISC?

nmm1@cus.cam.ac.uk (Nick Maclaren)
29 Apr 2004 12:04:51 -0400

          From comp.compilers

Related articles
How about VLIW used as RISC? ronald@interqos.com (2004-04-28)
Re: How about VLIW used as RISC? nmm1@cus.cam.ac.uk (2004-04-29)
Re: How about VLIW used as RISC? ricardo.b@zmail.pt (Ricardo Bugalho) (2004-04-29)
Re: How about VLIW used as RISC? torbenm@diku.dk (2004-04-29)
Re: How about VLIW used as RISC? MitchAlsup@aol.com (2004-04-29)
Re: How about VLIW used as RISC? alexc@std.com (Alex Colvin) (2004-05-02)
Re: How about VLIW used as RISC? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2004-05-02)
Re: How about VLIW used as RISC? stanlass@netins.net (Stan Lass) (2004-05-02)
[3 later articles]
| List of all articles for this month |
From: nmm1@cus.cam.ac.uk (Nick Maclaren)
Newsgroups: comp.arch,comp.compilers
Date: 29 Apr 2004 12:04:51 -0400
Organization: University of Cambridge, England
References: 04-04-088
Keywords: architecture
Posted-Date: 29 Apr 2004 12:04:51 EDT

Ron <ronald@interqos.com> wrote:
>We have simple scalar RISC and superscalar RISC but why there is few
>or no VLIW used as an RISC for general application? There is criticism
>about code density. However, as many has pointed out, modern VLIW has
>already used compression to remove NOOP instruction in the instruction
>packet. I guess 40-bit instruction is enough hold the additional
>control information, such as predicate bits, p bits(for indicating the
>last instruction of the instruction packet).


What do you mean by VLIW? If you mean packing multiple instructions
into one word, I am completely baffled why anyone thinks that it is
worth the effort in a world where multiple-issue is the norm. There
is a strong sense is which that sort of VLIW is simply a restrictive
form of multiple issue.


If you mean adding a whole lot of predication and other control data
onto an instruction, then (obviously) that is worth it if and only
if you can make good use of it. It is also a path back to some forms
of CISC, which may or may not suit your taste.


As usual, the devil is in the details, and whether a feature is good
or bad will depend more on how well it is done than its nature. We
have had good and bad RISC, CISC and VLIW.


>[Please try to keep this to compiler issues; comp.arch has a running
>flamefest on the Itanium that you're all welcome to join. -John]


It is quite possible to stir the embers of that without diverting
from compiler issues, but let's not ....


Regards,
Nick Maclaren.


Post a followup to this message

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