tore@sfd.uit.no (Tore Larsen) (06/11/90)
The june 1st Computerworld Norway brought an article by Don Omondi wa Radoli concerning DEC. In the article Radoli refers to a statement by Ken Olsen saying that DEC expects to offer a "RISC-y VAX" (Not my term!) within two years. Can anyone confirm if Ken Olson really has made this statement. If true, what does he mean by a RISC-y VAX and what are the consequences for DEC's commitment to the MIPS architecture? --Tore
fnddr@acad3.fai.alaska.edu (06/12/90)
In article <1990Jun10.170616.6606@hod.uit.no>, tore@sfd.uit.no (Tore Larsen) writes... >The june 1st Computerworld Norway brought an article by Don Omondi wa Radoli >concerning DEC. In the article Radoli refers to a statement by Ken Olsen >saying that DEC expects to offer a "RISC-y VAX" (Not my term!) within two >years. Can anyone confirm if Ken Olson really has made this statement. > >If true, what does he mean by a RISC-y VAX and what are the consequences >for DEC's commitment to the MIPS architecture? > > >--Tore In the March 13, 1990 PC Magazine's "Abort, Retry, Fail?" humor page, they have the following under the heading, "At That Speed, They'd Better Be Part of a _Really_ Complex Instruction Set:" DEC officials also said that as many as 80 percent of VAX instructions on the VAX 9000 can be executed in one second, giving VMS customers a better perspective on the VAX architecture as compared with RISC systems. - Digital Review, October 30, 1989 While this statement seems plausible for the VAX architectures I've been using the last several years, I presume they mean "...can be executed in one cycle." Since executing all instructions in one cycle is a (the?) definition of RISC, perhaps this is what they have in mind for a RISC-y VAX...getting more of the instruction set to execute in a single cycle. Even so, I doubt DEC will drop the Mips chips anytime soon, since the Mips-based products are all that DEC has that are competitive with Sun and IBM on a $/MIPS basis. I think a Mips R6000-based machine can almost match the VAX 9000 in VUPS for about 1/10 the cost*, so it will be interesting to see how these product lines develop... *I haven't seen detailed specs on the VAX 9000 (haven't really been looking) but I think comparing costs and benchmarks for the 9000 and the Mips RC6280 might be an enlightening exercise. Don Rice Internet: fnddr@acad3.fai.alaska.edu Geophysical Institute E-mail: fnddr@alaska.bitnet University of Alaska Phone: (907) 474-7569 Fairbanks, AK 99775 Loran: 64.86N 212.16E
SLSW2@cc.usu.edu (Roger Ivie) (06/12/90)
In article <1990Jun11.172604.22994@hayes.fai.alaska.edu>, fnddr@acad3.fai.alaska.edu writes: > While this statement seems plausible for the VAX architectures I've been using > the last several years, I presume they mean "...can be executed in one cycle." > Since executing all instructions in one cycle is a (the?) definition of RISC, > perhaps this is what they have in mind for a RISC-y VAX...getting more of the > instruction set to execute in a single cycle. Actually, there's another interpretation. Recall that even now MicroVAXes don't execute the complete instruction set; the CRC instruction, for instance, is emulated by software. The hardware simply provides hardware assist to emulation routines to execute these instructions. A RISCy VAX could imply even more emulation done by software. The core machine would execute some small subset of the instruction set (perhaps those that can reasonably be done in one cycle) and the remaining instructions would be interpreted. Just think! It would be capable of executing the entire VAX instruction set (by helping to interpret what it can't run) AND it would execute those instructions that it actually runs in a single cycle! Wouldn't that be fun for the marketing people to build literature around? -- =============================================================================== Roger Ivie 35 S 300 W Logan, Ut. 84321 (801) 752-8633 ===============================================================================
seymour@milton.acs.washington.edu (Richard Seymour) (06/15/90)
another thing the DEC people are (justifiably) proud of is that the 9000 takes fewer internal cycles to execute most instructions. my vague memory of the engineer's talk was: the 780 took an average of 11 cycles to execute instructions the 9000 takes about 6 to 8 -- and they're much faster cycles. The RISCness was from breaking the data and instruction flow down, and (i believe) using faster ALUs, etc. multiple times, rather than a broad-complex path to perform the steps of execution. Sorta like the 1962 SDS 930 family (the "first" Silicon-based computer priced below $100,000. Done by using the same ALU for address and data calculations -- "Silicon cost three times as much as Germanium, so they used each part three times to reduce the part count by a factor of three".) --dick
don@zl2tnm.gp.govt.nz (Don Stokes) (06/15/90)
SLSW2@cc.usu.edu (Roger Ivie) writes: > Actually, there's another interpretation. Recall that even now MicroVAXes > don't execute the complete instruction set; the CRC instruction, for instance > is emulated by software. The hardware simply provides hardware assist to > emulation routines to execute these instructions. > > A RISCy VAX could imply even more emulation done by software. The core machin > would execute some small subset of the instruction set (perhaps those that > can reasonably be done in one cycle) and the remaining instructions would > be interpreted. Hmmm. I don't have it on me at present (it's at work), but my VAX Architecture Handbook has a whole chapter on subset systems. It defines a "core" set of instructions, without which a processor is not a VAX.... It's a fairly large set, just leaving out some of the more estoeric and/or complex instructions (larger FP modes, character string instructions, POLYx etc). Mind you, to make code *really* fly on a VAX, you tend to have to treat the thing as a RISC anyway -- keep as much as possible in registers, use single operand instructions when you can't, intersperse memory instructions with register only ones etc. I gather the FORTRAN compiler tends to do this, even though the instrucuction set "seems" optimised towards FORTRAN..... Don Stokes, ZL2TNM / / Home: don@zl2tnm.gp.govt.nz Systems Programmer /GP/ Government Printing Office Work: don@gp.govt.nz __________________/ /__Wellington, New Zealand_____or:_PSI%(5301)47000028::DON