Path: utzoo!attcan!uunet!yale!mfci!colwell
From: colwell@mfci.UUCP (Robert Colwell)
Newsgroups: comp.arch
Subject: Re: VLIW
Message-ID: <555@m3.mfci.UUCP>
Date: 12 Nov 88 18:30:46 GMT
References: <70@armada.UUCP> <28200234@urbsdc>
Sender: colwell@mfci.UUCP
Reply-To: colwell@mfci.UUCP (Robert Colwell)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 46

In article <28200234@urbsdc> aglew@urbsdc.Urbana.Gould.COM writes:
>
>>..> Peter da Silva makes the plea for scoreboarding being better
>>..> than VLIW, "because the next version of the machine is likely
>>..> to have a different mix of instruction timings."
>>
>>The next version of the machine have different instruction timings?
>>How? Remember, a VLIW is effectively executing microcode. Multiplies
>>on a CISC processor, currently implemented in microcode, can be
>>speeded up by adding a hardware multiplier. But adding a new
>>functional unit like that to a VLIW effectively makes the instruction,
>>err, control word longer. You'll have to re-compile to take advantage
>>of it anyhow!
>
>Ummh, what is to prevent a VLIW from having a multiply instruction
>(doesn't MULTIFLOW, Bob?).

Yes, we do have integer multiply (in fact, they're implemented in
those great big AMD/Cypress chips).

>    IE. what is to prevent execution units that are already in the
>VLIW from changing theit timings.

Not a thing.  And if you've made your compiler table-driven, where
all the significant pipe lengths and resource usages in the machine
reside in one table, it's not hard at all to retarget the compiler.
And further, it's relatively easy to experiment with what the effects
on performance would be if one could shorten a pipe here or add a
register file port there.

>VLIW and techniques such as scoreboarding are not mutually exclusive
>- it is possible to combine them, although whether such is worthwhile
>is the subject of ongoing research. So far, I'd guess that the evidence
>says that VLIW+scoreboarding doesn't win you much performance, but
>it can give you binary compatibility.

Yes, that's one way to get binary compatibility, similar in spirit to
the Vax's 11-compatibility mode.  Kinda high price to pay, though,
considering I could have used that hardware to buy higher performance
on recompiled code for the same hardware cost (and less design time,
since the scoreboard would be no trivial design to get right.)

Bob Colwell            mfci!colwell@uunet.uucp
Multiflow Computer
175 N. Main St.
Branford, CT 06405     203-488-6090