gnu@hoptoad.uucp (John Gilmore) (01/29/86)
In article <5100001@ccvaxa>, aglew@ccvaxa.UUCP writes: > Why did IBM not release news about the 801 until just about now? > Paranoid answer: because the 801 RISC approach was valid when VLSI > was young (just how long has Patterson's RISC group been going on) > but is no longer applicable... It's not clear whether RISC is a win or not -- we'll only see after they've been in the marketplace for a few years. It *is* an interesting idea; the catch is software. Can a complicated compiler generate correct code that is faster than what a very very smart microcode author could write and put into a non-RISC machine? Indeed, the microcode has to do more work (decode instructions, etc) but the human is smarter than the compiler. It's a horse race. > Microcode > was a lump that lay across the chip boundary - RISC placed this lump > outside because it couldn't all be fitted inside - maybe IBM can now > squeeze it all onto the chip?) RISC moves that boundary from "between the microcode and the ALU/sequencer" to "between the main memory and the ALU/sequencer". This is another factor that tends to make RISC lose, since it's always possible to build a small wide (microcode) memory faster than you can build a large main memory. But there are complications you can add to the large main memory such that *most* of what you reference ends up in a small fast memory -- cacheing. The "win" of less decoding overhead has to outweigh the "lose" of more main memory activity, (plus the cost of the more complex main memory) or RISC is not competitive. The technical info I've seen on the IBM RT PC so far doesn't mention cacheing (except page map cacheing) and the compiler technology sounds, from John Levine's message, pretty mundane. Also, the chips are old technology (NMOS with 2 power supplies and 2.4 watts of heat generated per chip -- each one requires a heat sink) compared to today's micros by commercial micro companies (Intel, Motorola). This, plus the deadbeat graphics and network hardware for the RT PC, makes it sound like they haven't shot their wad yet (in the usual IBM fashion) but are giving us a two year old product and seeing how many people will spend money on it before giving us this year's product. Don't ever forget that IBM's in business to make money, not to give you leading edge products. -- # I resisted cluttering my mail with signatures for years, but the mail relay # situation has gotten to where people can't reach me without it. Dammit! # John Gilmore {sun,ptsfa,lll-crg,nsc}!hoptoad!gnu jgilmore@lll-crg.arpa
brooks@lll-crg.ARpA (Eugene D. Brooks III) (01/29/86)
In article <449@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >It's not clear whether RISC is a win or not -- we'll only see after >they've been in the marketplace for a few years. It *is* an >interesting idea; the catch is software. Can a complicated compiler >generate correct code that is faster than what a very very smart >microcode author could write and put into a non-RISC machine? Indeed, >the microcode has to do more work (decode instructions, etc) but the >human is smarter than the compiler. It's a horse race. The RISC development to watch is the Clipper chip set from Fairchild. It is more up to date technology, has on chip floating point and seperate single chip cache and memory management support.
jer@peora.UUCP (J. Eric Roskos) (01/31/86)
> Indeed, the microcode has to do more work (decode instructions, etc) but > the human is smarter than the compiler. It's a horse race. Actually, in some microprogrammed machines, there are hardware assists for instruction decoding, so that all the microcode has to do is actually execute the instruction, not decode it. In such machines, the hardware decodes the instruction, sets up the operand addresses, looks up a starting address in a table based on the opcode, and starts the microprogram sequencer at the address it found in the table. However, you then have a tradeoff between speed and generality -- the machine is faster because it doesn't have to decode the instructions, but if you want a different instruction format, it's harder to do... Some of our earlier machines (e.g., the 3220) worked that way; I don't know anything about the current ones, though. -- UUCP: Ofc: jer@peora.UUCP Home: jer@jerpc.CCUR.UUCP CCUR DNS: peora, pesnta US Mail: MS 795; CONCURRENT Computer Corp. SDC; (A Perkin-Elmer Company) 2486 Sand Lake Road, Orlando, FL 32809-7642 xxxxx4xxx
mash@mips.UUCP (John Mashey) (01/31/86)
Eugene D. Brooks III (lll-crg!brooks) writes: > > The RISC development to watch is the Clipper chip set from Fairchild. > It is more up to date technology, has on chip floating point and seperate > single chip cache and memory management support. 1) One can argue the merits of one chip (set) over another, using many different criteria. Whether something is or isn't a RISC, or better, how RISCy it is, is only one attribute, and I wouldn't suggest that it is the primary one. 2) Nevertheless, this kind of discussion may confuse the issue, i.e., exactly what a RISC is and why gets terribly confused when people apply the term to radically different architectures. Fairchild's own literature [I have a lot of it] claims correctly that it applies some RISC ideas, not that it is a RISC. 3) A fundamental idea of RISC is to reduce the number of machine cycles per instruction (or better, per Mips-equivalent). Here are some numbers, (please don't niggle over fractions, this is all approximate): CHIP CLOCK Mips CLOCKS/Mips 68020 16Mhz 2 8 Clipper 33 5 6 ROMP 6 2 3 4) No one believes the 68020 is a RISC. Most people believe ROMP is a RISC [although be careful, it is of the "low-cost RISC" style, i.e., designed for efficient cacheless operation, rather than all-out performance.]. If you use the metric of clocks/mips, you can judge for yourself whether the Clipper is more like a ROMP or more like a 68020. 5) Why do people care about clocks/Mips? ANS: because the clock speed ends up being a fundamental limiting factor, especially as you cram more and more on a few chips. Be very careful to separate the effects of circuit technology from architecture: from the circuit side, faster clock = more impressive. From the architecture side, faster clock (for the same delivered performance) = LESS impressive. 6) Growth paths. I have no idea what IBM is up to. Nevertheless, one has to believe that a ROMP-style design has a lot more headroom for clock rate improvements than do the others listed. Here is a hypothetical question: if you can have a 5Mips Clipper at 33Mhz in 1986, when can you get one that might at go at, say, 10Mips, i.e., around 66Mhz? 7) The next month or so should be interesting. UNIFORUM has one RISC vs CISC debate. IEEE COMPCON (San Francisco, March 4-6) has the following free-for-all: a) a RISC vs CISC debate b) a full session (I think) on HP Spectrum, or whatever it will be called by then. c) a full session by Fairchild on Clipper and d) a full session by MIPS Computer Systems on our stuff [finally, out of the closet!] 8) Again, I emphasize again that I'm not proposing that RISC = GOOD, CISC = bad, but that one must look at every architecture on its own merits, rather than lumping a raft of rather different architectures under the same label. -- -john mashey UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash DDD: 415-960-1200 USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043
henry@utzoo.UUCP (Henry Spencer) (02/04/86)
> The RISC development to watch is the Clipper chip set from Fairchild. > It is more up to date technology, has on chip floating point and seperate > single chip cache and memory management support. It also has a price tag to make your hair stand on end. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
olsen@ll-xn.ARPA (Jim Olsen) (02/06/86)
>> The RISC development to watch is the Clipper chip set from Fairchild. >> It is more up to date technology, has on chip floating point and seperate >> single chip cache and memory management support. > > It also has a price tag to make your hair stand on end. Yes and no. The Clipper module provides CPU, Floating Point, MMU with TLB, and two caches. The price is steep, but you get a lot for it. -- Jim Olsen (olsen@ll-xn.arpa) ...!{decvax,lll-crg,seismo}!ll-xn!olsen