🚀 go-pugleaf

In article <3449@alliant.Alliant.COM> lewitt@Alliant.COM (Martin Lewitt) writes:
>In article <1989Oct5.025841.2046@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes:
>*** much deleted ***
>>To return to the original argument, John Ellis' book doesn't concern itself
>>with specific instruction sets because at the time he wrote it, VLIWs
>>existed only on paper.  The concrete design of a VLIW happened only after
>>most of the rest of the Yale VLIW project left to build real hardware at
>>Multiflow.  I was at Yale at the time and the longest instruction word we
>>had was 36 bits in our DEC-20.  Or maybe 48 bits in a PDP-11.
>
>Ouch!!  Why don't the Floating Point System's AP120B and FPS-164 processors
>qualify as VLIW?  They were commercial products introduced in 1975 and 1981
>respectively:

FPS failed to realize a couple of key concepts, and this is why they don't
get to retrofit the "VLIW" label to their boxes (after all, Josh Fisher
invented this technology and came up with that label, so he gets to provide
the definition for VLIW).

The first concept is that you can't just invent whatever architecture and
instruction set comes to mind, or is easiest to build, or is cheapest.  You
must start with what the compiler wants to see as a target.  A trace-scheduling
compiler is hard enough to do that you certainly do not want to add to its
burdens without a compelling reason.

If you have only a wide-word (and I won't quibble about the actual width)
machine with parallel functional units then you're not even halfway there.

>The Multiflow machine was no mystery to FPS sales analysts.  It was the 
>FPS dream machine: UNIX, virtual memory, better compilers, etc.  We had 
>asked FPS to give us these features right from the beginning of the 164 
>back in 1981.  By the time, Multi-flow delivered, it was too, late,
>Convex, Alliant and FPS's own ECL machine, 264 were already on the scene,
>and the high end workstations arrived in short order.

Too late for whom or for what?  What a weird paragraph.

>It will be interesting to see if FPS gets the credit it deserves when the
>history is written, I doubt it.  Will the historians do any better than
>the contemporaries?  In 1985, an article about micro-programming appeared
>in Scientific American, written by a Stanford professor.  He anticipated
>the day when there would be commercial machines compiling directly to
>micro-code.  FPS had sold nearly 150 machines already.

There *is* a relationship between the FPS boxes and the VLIW work done at
Multiflow and Yale.  As Ellis reports, the FPS boxes showed what would be
wrong with a machine that was not designed at the outset to be a good target
for compiled code.  There are hot spot registers, the functional units are 
not decoupled at the instruction set level, the datapaths are not regular,
and there aren't enough registers to support the flops.  When you design a
machine to be completely scheduled at compile-time, it shows in the design.
Retrofitting a compiler to an existing architecture will never work.  The
influence that the FPS work had on the Multiflow machines was a negative
one -- we knew that was one approach which would not get us what we needed.

>Let's get the history right.
>       1) The first commercially available VLIW machine was the FPS-164,
>          not the Multiflow (by 6 years).

The FPS machines do indeed enjoy a unique place in the computer hall of
fame, but the label under the exhibit won't say VLIW, nor should it.
But the FPS machines were not statically scheduled and
controlled by the compiler.  They therefore don't qualify as VLIWs under 
Josh's definition of the term.  Feel free to make up some other name if
you want; "attached processor" has always seemed pretty appropriate to me.

The FPS designs also try to compress the instruction stream in a sub-optimal way, 
pre-combining certain operations (your "parallel micro-operations") in
much the same way (and for the same reasons) that CISCs did.  A VLIW,
on the other hand, completely decouples the control of all functional
units, and avoids the baggage of carrying around the whole instruction
word width during sequences of sequential code by using an encoding scheme
described in our IEEE Transactions paper.  This makes the compiler much
happier.  Ours smiles a lot.

>       2) The "first affordable supercomputer" was the FPS-164, not the
>	  Convex (by 4 years).  FPS was using the "affordable
>	  supercomputer" and "departmental supercomputing" phrases
>	  long before the Convex advertisements and literature took
>	  them up.

Agreed.  Although calling an attached processor a "computer" smacks of
marketing hype, to me.  And if your references to having a workable compiler
were legit, then why did Convex's first machine beat the 164, which had more
mflops under the hood?

>       3) The first commercially available machine to compile complete
>          HLL applications to micro-code was once again, the FPS-164
>          (well, actually the VAX since it was cross-compilation).

Yes, although with the cart before the horse this effort was largely 
doomed from the start.

>       4) The first commercially available machine to successfully exploit 
>          parallel processors automatically using "dusty deck", serial 
>          FORTRAN, the Alliant FX8, (by 4 years and counting).

"And counting"?  What does that mean?

>       5) The first commercially available RISC machine was the FPS-164.
>          (I'd love to see this one discussed, are VLIWs RISCy?)   8-)

What about the FPS-164 qualified it as a RISC?  You must have some interesting
definition of RISC.  From Hwang and Briggs: "The AP-120B and the FPS-164
are back-end attached arithmetic processors specially designed to process
large vectors or arrays (matrices) of data.  Operationally, these processors
must work with a host computer, which can be either a minicomputer (such as
the VAX-11 series) or a mainframe computer (IBM 308X series."  Whatever else
the RISC acronym implies, the "C" stands for computer, and to me, attached
processors aren't computers.

I think discussing VLIWs as RISCs is interesting, partly because it so aptly
illustrates why the early insistence on counting the number of instructions
before declaring something a RISC was so misguided.  The important thing is
to be able to implement the most-used ops such that they're as fast as can be,
which usually means they get hard-wired control.  If you can manage to implement
your design such that you get fast, hard-wired simple ops, but lots of them
in parallel (controlled by the wide word) then I think you've got the essence
of the RISC approach without ending up hamstrung by religious zealotry.

>I don't know if I've got the history right, I've only been in the industry
>since '81, so feel free to propose "minor" adjustments.  I'll gracelessly hide 
>out when the heavyweights start swinging.

Aw, you're just a baby.  You should have stated this earlier and I'd have 
used smaller words.  :-)

Bob Colwell               ..!uunet!mfci!colwell
Multiflow Computer     or colwell@multiflow.com
31 Business Park Dr.
Branford, CT 06405     203-488-6090