VLIW pre-history
|
From: John L on 13 May 2007 20:38 >> VLIW isn't just wide microcode with multiple functional units. It's >> also the compiler techniques with trace scheduling and speculative >> execution that let it keep large numbers of units busy. > >That doesn't explain how I can look at a piece of hardware and >definitively state that it is or is not VLIW. I think it should >be possible to do that without looking at the software. Well, like I said, try programming it by hand, and if you can't, it must be VLIW. R's, John
From: Quadibloc on 13 May 2007 23:32 Eric Smith wrote: > That doesn't explain how I can look at a piece of hardware and > definitively state that it is or is not VLIW. I think it should > be possible to do that without looking at the software. .. Someone else, in a reply to one of my posts, has claimed that the System/360 Model 85 and its successors had capabilities I did not suspect a computer executing conventional instructions by means of microcode could have. So I may be mistaken in some of my thinking about this topic. But I would think that there is a very simple definition of VLIW. Instructions explicitly code for superscalar operation. Note that the Cyberplus from Control Data had multiple functional units which could all be busy at once, but did not have a large number of fast data memories that could be used as sources and destinations in the same instruction, so it functioned as a *dataflow* architecture. The term VLIW has since been applied to such things as a DSP from Texas Instruments that fetches eight instructions at once, with these instructions having a bit that indicates they can be executed in parallel with the preceding instruction. That may not have been what VLIW used to mean, but since it does permit superscalar operation, I think I have to accept that it is legitimate. And that the Itanium is also a VLIW machine. In the Model 85, the 370/165 and 370/168, and the 3033, even with progressive major improvements in the microcode, the I unit and E unit were overlapped with each other. They weren't superpipelined like a 360/91, 360/195 or 370/195. So although they had horizontal microcode, the I unit was still executing microinstructions for one instruction at a time. Possibly, the microinstructions had portions that had a delayed effect, but given the conventional instructions specified one operation at a time, I don't see how you could make even a 3033 do one add per cycle *and* one multiply per cycle, at least as long as you don't count the two adds for address arithmetic, for any length of time. Actually, even with the high-speed multiply feature, it only retired 12 bits of the multiplier at a time - just like the 360/91, from whence it came - but keeping *multiple functional units* fully busy on computations related to the problem isn't possible in that kind of classic microcoded architecture, no matter how horizontal the microcode. No more than one instruction - one basic operation - per cycle. Unless you count adding the exponent and multiplying the mantissa of a floating-point number in parallel - which the 85, and even the 65, did do - as superscalar. I wouldn't. Of course, had the 85 been used to execute microcode programs instead of 360 programs, then perhaps it could have been called a VLIW machine, because it could be off doing a 32-bit integer multiply *and* a character translate or an edit instruction at the same time in that case. Even the model 65 or the model 50 could be VLIW, if you consider the arithmetic ALU and the character ALU (not capable of addition to speed FP on the 50) as the two functional units capable of separate handling. But the 360 didn't come with "translate characters and do a vector multiply at the same time" instructions. John Savard
From: Del Cecchi on 13 May 2007 23:40 "Quadibloc" <jsavard(a)ecn.ab.ca> wrote in message news:1179113537.089454.4260(a)n59g2000hsh.googlegroups.com... > Eric Smith wrote: >> That doesn't explain how I can look at a piece of hardware and >> definitively state that it is or is not VLIW. I think it should >> be possible to do that without looking at the software. > . > Someone else, in a reply to one of my posts, has claimed that the > System/360 Model 85 and its successors had capabilities I did not > suspect a computer executing conventional instructions by means of > microcode could have. > > So I may be mistaken in some of my thinking about this topic. > > But I would think that there is a very simple definition of VLIW. > Instructions explicitly code for superscalar operation. > > Note that the Cyberplus from Control Data had multiple functional > units which could all be busy at once, but did not have a large number > of fast data memories that could be used as sources and destinations > in the same instruction, so it functioned as a *dataflow* > architecture. > > The term VLIW has since been applied to such things as a DSP from > Texas Instruments that fetches eight instructions at once, with these > instructions having a bit that indicates they can be executed in > parallel with the preceding instruction. That may not have been what > VLIW used to mean, but since it does permit superscalar operation, I > think I have to accept that it is legitimate. And that the Itanium is > also a VLIW machine. > > In the Model 85, the 370/165 and 370/168, and the 3033, even with > progressive major improvements in the microcode, the I unit and E unit > were overlapped with each other. They weren't superpipelined like a > 360/91, 360/195 or 370/195. > > So although they had horizontal microcode, the I unit was still > executing microinstructions for one instruction at a time. Possibly, > the microinstructions had portions that had a delayed effect, but > given the conventional instructions specified one operation at a time, > I don't see how you could make even a 3033 do one add per cycle *and* > one multiply per cycle, at least as long as you don't count the two > adds for address arithmetic, for any length of time. > > Actually, even with the high-speed multiply feature, it only retired > 12 bits of the multiplier at a time - just like the 360/91, from > whence it came - but keeping *multiple functional units* fully busy on > computations related to the problem isn't possible in that kind of > classic microcoded architecture, no matter how horizontal the > microcode. > > No more than one instruction - one basic operation - per cycle. > > Unless you count adding the exponent and multiplying the mantissa of a > floating-point number in parallel - which the 85, and even the 65, did > do - as superscalar. I wouldn't. > > Of course, had the 85 been used to execute microcode programs instead > of 360 programs, then perhaps it could have been called a VLIW > machine, because it could be off doing a 32-bit integer multiply *and* > a character translate or an edit instruction at the same time in that > case. Even the model 65 or the model 50 could be VLIW, if you consider > the arithmetic ALU and the character ALU (not capable of addition to > speed FP on the 50) as the two functional units capable of separate > handling. > > But the 360 didn't come with "translate characters and do a vector > multiply at the same time" instructions. > > John Savard I wonder how few square millimeters of 65nm silicon it would take to reproduce the 360/86 cpu netlist, including cache and everything. maybe 3 or 4? >
From: Anne & Lynn Wheeler on 14 May 2007 00:24 Quadibloc <jsavard(a)ecn.ab.ca> writes: > Actually, even with the high-speed multiply feature, it only retired > 12 bits of the multiplier at a time - just like the 360/91, from > whence it came - but keeping *multiple functional units* fully busy on > computations related to the problem isn't possible in that kind of > classic microcoded architecture, no matter how horizontal the > microcode. > > No more than one instruction - one basic operation - per cycle. it would appear that the original question/issue is being changed in real time???? so now with a great deal of such confusion and obfuscation then take itanium wide-word and call it VLIW ... unless somebody happen chance to port one of the i86 370 emulators to itanium ... and used it to (also) emulate (non superscaler) 370 instruction ... and then forever forth it would no longer be permissable to claim itanium wide-word was VLIW. the original issue was whether or not the horizontal microcode capability used in various highend 370 processors, various mainframe channel units, and mainframe disk controllers, could be considered equivalent to VLIW with its highly parallel execution. the original issue had nothing at all to do with specific machines where horizontal microcode was used to emualtion 370 instructions .... and/or whether or not those 370 instructions emulated appeared to be superscaler. then there was description of horizontal microcode which meets the definition. now it appears that if the horizontal microcode was used to emulate 370 opcodes ... and if the emulated 370 execution wasn't superscaler .... then the parallel, superscaler operations performed by the horizontal microcode couldn't meet the definition of VLIW. what happens if the same/similar horizontal microcode for implementing highly parallel operations other than emulation of 370 instruction .... for instance integrated channel i/o operation and/or disk controller units doing highly parallel operation????? So the situation now appears that if horizontal microcode was used to emualte 370 instructions ... and the 370 instructions didn't meet somebody's definition of parallel, superscaler ... then the horizontal microcode capability that was used in the implementation ... also couldn't be considered parallel, superscaler. However, if the same exact microcode engine ... with the same exact horizonal microcode instructions capability was used to implement highly parallel operations that weren't 370 instruction execution emulation .... but other types of parallel superscaler operations ... would it be allowed that operational horizontal micrcode be VLIW?????? at which point ... would it then be that horizontal microcode would be equivalent to VLIW when it was used in a program to do something other than 370 instruction execution ... but the same horizontal microcode engine/instructions would not be equivalent to VLIW when the horizontal micrcode program was emulating 370 instructions. To some extent the limitation on the execution of 370 superscaler .... wasn't so much a limitation of the superscaler capability of the horizontal microcode ... but a limitation of the hardware resources that were available to the horizontal micrcode programer for the emulation of 370 instructions. i.e. my understanding was that the original issue was whether or not the horizontal microcode used in these various hardware engines were VLIW .... as opposed to whether or not a specific application (370 instruction emulation) implemented with horizontal micrcode might be considered VLIW. so now with a great deal of such confusion and obfuscation then take itanium wide-word and call it VLIW ... unless somebody happen chance to port one of the i86 370 emulators to itanium ... and used it to (also) emulate (non superscaler) 370 instruction ... and then forever forth it would no longer be permissable to claim itanium wide-word was VLIW. re: http://www.garlic.com/~lynn/2007j.html#84 VLIW pre-history http://www.garlic.com/~lynn/2007j.html#95 VLIW pre-history http://www.garlic.com/~lynn/2007j.html#96 VLIW pre-history http://www.garlic.com/~lynn/2007j.html#97 VLIW pre-history http://www.garlic.com/~lynn/2007k.html#1 VLIW pre-history
From: Anne & Lynn Wheeler on 14 May 2007 01:22
Anne & Lynn Wheeler <lynn(a)garlic.com> writes: > so now with a great deal of such confusion and obfuscation then take > itanium wide-word and call it VLIW ... unless somebody happen chance to > port one of the i86 370 emulators to itanium ... and used it to (also) > emulate (non superscaler) 370 instruction ... and then forever forth it > would no longer be permissable to claim itanium wide-word was VLIW. re: http://www.garlic.com/~lynn/2007k.html#6 VLIW pre-history some itanium references possibly being considered VLIW Inventing Itanium: How HP Labs Helped Create the Next-Generation Chip Architecture http://www.hpl.hp.com/news/2001/apr-jun/itanium.html Itanium is Intel's future http://www.infoworld.com/article/04/09/10/37OPcurve_1.html Analysis and Characterization of Intel Itanium Instruction Bundles for Improving VLIW Processor Performance http://portal.acm.org/citation.cfm?id=1136267 about a decade ago we had a look at some of the issues of porting i86 370 emulator to itanium ... and while itanium may be considered vliw .... the 370 emulated execution on itanium wasn't vliw &/or superscaler. re: http://www.garlic.com/~lynn/2007j.html#84 VLIW pre-history http://www.garlic.com/~lynn/2007j.html#95 VLIW pre-history http://www.garlic.com/~lynn/2007j.html#96 VLIW pre-history http://www.garlic.com/~lynn/2007j.html#97 VLIW pre-history http://www.garlic.com/~lynn/2007k.html#1 VLIW pre-history |