VLIW pre-history
|
From: Jason Lee Eckhardt on 17 May 2007 11:07 In article <f2gih2$7o2$1(a)gal.iecc.com>, John L <johnl(a)iecc.com> wrote: >>> Sounds reasonable to me. So an i860 qualifies? >> >>Hunting around the web, although I could not find any detailed >>description of the i860 instruction set > >Gee, I have the programming manual right here on the shelf. You >never know when it might come in handy. > >>architectures from Philips noted that the i860 could switch to a mode >>where it fetched instructions in pairs, such that one instruction had >>to be for the integer unit, and the other for the floating-point unit. > >Right. There was also explicit pipelining in the FP unit so that in >pipelined mode, the result an instruction put into the register was >from the inputs three instructions ago. It was reasonably easy to >write efficient routines for dot products that did a multiply and add >of the elements of an array, but it was major challenge to keep the >CPU busy with more complex algorithms. In this respect (manually advanced pipelines), the i860's FP unit was remarkably similar to the FPS AP120B. However, instead of using two different operations in a long instruction word to drive the multipler and adder (as in the AP), the i860 used a single 32-bit operation with 32 different opcode combinations that specified the datapaths between the multiplier, adder, and their inputs. A fascinating design, but daunting for the novice programmer or naive compiler. I spent a few years hand crafting code for it, and writing compiler back-ends for it. Alot of fun for a compiler dweeb or mathlib guy. I'm curious if Alan Charlesworth (who posted in this thread as well) had any contact with the i860 designers wrt to the FP unit? Or did the designers borrow the ideas independently? Does Les Kohn lurk here, or Sai Wai Fu? I've always wanted to know the design details-- the IEEE Spectrum article in 1989 talks more about staffing, as opposed to the technical details. >You could make a plausible argument that the 860 was the world's >narrowest VLIW. I would agree, at least when the i860 is in dual-instruction mode. Fisher might also. In his own (recent, 1998) words: "Does the object code actually have to have wide instructions in it for an implementation to be a VLIW? Not to me...I can tell the extent to which they follow this philosophy..." Where "this philosophy" is: "To me, the part of VLIW that mattered then and matters now is the philosophy that one should get a lot of ILP in a processor without asking the hardware to do much to locate and schedule it. As with anything of this sort, there is a spectrum. I think of an implementation that expects operations to have to been arranged so it can trivially put them in parallel at run-time is a good embodiment of this philosphy." That certainly describes the i860 in dual-instruction mode, where the compiler or programmer is entirely responsible for discovering and specifying the parallelism. Back in 1983, however, Fisher seemed to place a little more emphasis on the "very long" part of the name than he does now: "A VLIW looks like very parallel horizontal microcode...has the following properties: - There is one central control unit issuing a single long instruction word per cycle. - Each long instruction consists of many tightly coupled independent operations. ..." Also, I can no longer remember where I read it, but he mentioned that VLIW's should be easy compiler targets, and he therefore did not think manually advanced pipelines were a feature of VLIW's (like the AP-120B and i860). Interesting, then, that the 1983 paper mentions working on another code generator for their research VLIW compiler that targets the FPS 164 (a follow-on to the AP). jason.
From: Eugene Miya on 17 May 2007 18:49 In article <1179341902.908432.86790(a)q75g2000hsh.googlegroups.com>, Quadibloc <jsavard(a)ecn.ab.ca> wrote: >Eugene Miya wrote: >> Mark, you would know better, but I've even heard the Stretch (7030) as a >> precursor VLIW. >. >I certainly would tend to agree that the Stretch isn't a precursor of >VLIW. But it's possible HARVEST might have been one. Well, I wouldn't know. Take this up with Eric. On what basis do you think it might be? --
From: Eugene Miya on 17 May 2007 18:53 In article <qhfy5wz7tx.fsf(a)ruckus.brouhaha.com>, Eric Smith <eric(a)brouhaha.com> wrote: >Eugene Miya wrote: >> Mark, you would know better, but I've even heard the Stretch (7030) as a >> precursor VLIW. > >Definitely not. There are some unusual aspects to the intruction set, >and the hardware does use some parallelism, but the instruction set >operates purely sequentially and does not use fields to control >separate functional units. My position is that I don't regard of these pre-Trace machines as VLIW. But go after John. Actually N. who programmed on the Harvest, I saw yesterday. I could have gotten an opinion from him but the wireless at Stanford was flakey yesterday. I'm not a fan of VLIW and Multiflow went under before I had a chance to site visit them. I think the cost-benefit (ROI) isn't there. --
From: Quadibloc on 17 May 2007 21:42 Eugene Miya wrote: > Well, I wouldn't know. Take this up with Eric. > On what basis do you think it might be? There are HARVEST manuals on Al Kossow's site now. I haven't been able to make enough sense out of them to have a definite opinion, but it is at least possible for this machine to be similar to a dataflow architecture. John Savard
From: Eric Smith on 17 May 2007 22:21
eugene(a)cse.ucsc.edu (Eugene Miya) writes: > My position is that I don't regard of these pre-Trace machines as VLIW. > But go after John. Actually N. who programmed on the Harvest, I saw > yesterday. The Harvest system (IBM 7950) is a superset of the Stretch system (IBM 7030). The Stretch processor (IBM 7101 Central Processing Unit) was not at all like a VLIW. The Harvest coprocessor (IBM 7951 Processing Unit) was very unusual and perhaps vaguely VLIWish. |