Path: utzoo!attcan!uunet!ncrlnk!ncrcae!ece-csc!mcnc!xanth!nic.MR.NET!tank!uxc!uxc.cso.uiuc.edu!urbsdc!aglew
From: aglew@urbsdc.Urbana.Gould.COM
Newsgroups: comp.arch
Subject: Re: VLIW (was please re-send mail)
Message-ID: <28200234@urbsdc>
Date: 11 Nov 88 01:08:00 GMT
References: <70@armada.UUCP>
Lines: 56
Nf-ID: #R:armada.UUCP:70:urbsdc:28200234:000:2528
Nf-From: urbsdc.Urbana.Gould.COM!aglew    Nov 10 19:08:00 1988


>..> 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!
>
>Eric Lee Green    ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg
>          Snail Mail P.O. Box 92191 Lafayette, LA 70509              

Ummh, what is to prevent a VLIW from having a multiply instruction
(doesn't MULTIFLOW, Bob?).

And what is to prevent version 1 of the machine having a multiply
instruction that does two bits at a time, taking ~16 cycles,
while version 2 does 8 bits at a time, taking ~4 cycles, for a 32
bit word?
    IE. what is to prevent execution units that are already in the
VLIW from changing theit timings.

Ditto especially for the memory system. 

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.

Binary compatibility will be an issue until (1) there is a standard
machine independent distribution format for software; (2) until there
is a standard way of handling multi-machine executables; (3) when
the problems of process migration between inhomogenous machines
are either solved, or considered unimportant.



Andy "Krazy" Glew. 
at: Motorola Microcomputer Division, Champaign-Urbana Development Center
    (formerly Gould CSD Urbana Software Development Center).
mail: 1101 E. University, Urbana, Illinois 61801, USA.
email: (Gould addresses will persist for a while)
    aglew@gould.com     	    - preferred, if you have MX records
    aglew@fang.gould.com     	    - if you don't
    ...!uunet!uiucuxc!ccvaxa!aglew  - paths may still be the only way
   
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.

PS. I promise to shorten this .signature soon.