Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uunet!hsi!mfci!colwell From: colwell@mfci.UUCP (Robert Colwell) Newsgroups: comp.arch Subject: Re: VLIW Architecture Keywords: VLIW Message-ID: <1071@m3.mfci.UUCP> Date: 9 Oct 89 13:33:10 GMT References: <251FCB3F.12366@maccs.dcss.mcmaster.ca> <1050@m3.mfci.UUCP> <13050@pur-ee.UUCP> <1630@l.cc.purdue.edu> <1989Oct5.025841.2046@esegue.segue.boston.ma.us> <3449@alliant.Alliant.COM> Sender: colwell@mfci.UUCP Reply-To: colwell@mfci.UUCP (Robert Colwell) Organization: Multiflow Computer Inc., Branford Ct. 06405 Lines: 131 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