Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!ncrlnk!ncr-mpd!Chuck.Phillips From: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) Newsgroups: comp.sys.amiga.hardware Subject: Re: RISC Amiga WHat's RISC? Message-ID: Date: 12 Nov 90 12:43:02 GMT References: <39367@ut-emx.uucp> <15759@cbmvax.commodore.com> <1990Nov9.222501.21238@engin.umich.edu> Sender: uucp@ncr-mpd.FtCollins.NCR.COM Organization: NCR Microelectronics, Ft. Collins, CO Lines: 63 In-reply-to: milamber@caen.engin.umich.edu's message of 9 Nov 90 22:25:01 GMT >>>>> On 9 Nov 90 22:25:01 GMT, milamber@caen.engin.umich.edu (Daryl Scott Cantrell) said: Daryl> RISC == Reduced Instruction Set Computing. Just a few months ago, I thought that also. (I was then a RISC basher, BTW.) As it turns out, RISC is a misnomer. The cornerstone of RISC is ruthless _quantitative_ analysis; features (instructions, cache, etc.) are only added as they prove themselves _quantitatively_ (cost/performance) when executing _real programs_. If you _really_ want to get a handle on what RISC is all about, read: "Computer Architecture - A Quantitative Approach" Hennessy & Patterson ISBN: 1-55860-069-8 Morgan Kaufman Publishers Other than the examples where RISC always (surprise, surprise:-) beats CISC and little acknowledgement that CISC _can_ be piplined, the book appears to present an impartial, thorough examination of various cost/performance tradeoffs. There is much food for thought here. (NOTE: I'm only halfway through the book so far, so add some grains of salt.) Merely reducing the instruction set doesn't necessarily buy you much. If it did, we'd all be using 6502s with 50MHz clocks. "So why is it called 'RISC'?" you ask. Beats me. Instruction set size is only one of many variables, as is explained in H&P's book. Daryl> Of course, RISC will never really be that much faster than CISC Daryl> because CISC chips can always bail out.. By pipelining their Daryl> architecture for the "most-used" instructions that RISC chips Daryl> implement, and still having the higher-level functions available as Daryl> microcode, which would be much slower than the optimized Daryl> instructions but still faster than RISC implementations. I'm not sure one way or the other on this. The example of taking this approach (with which I'm familiar) is the MicroVAX, which is noticably slower than its extremely CISC predecessors (the 780 and 785), which are in turn, noticably slower than several RISC machines all at the same clock speed. It may turn out someday that the very fastest single processor machines are super CISC, but their cost/performance is almost certain to be much poorer than that of simple RISC. Daryl> Motorola seems to be doing exactly this with the 68040, ... Are they, _really_ taking this approach? I ask because I don't know either. Daryl> I've seen 1.2-1.3 cyc/ins all over the place.. Ditto for the 80486. (No flames, please:-) However, there are current RISC processors that manage to average _less_ than 1 cycle per instruction. (I've even heard of 1/2-1/3 Cycles Per Instruction peak performance. How _do_ they do that?) The future of computer architecture looks to be very interesting. The only thing _I'd_ bet money on is an increase in multi-processor systems. Just my $0.02, -- Chuck Phillips MS440 NCR Microelectronics chuck.phillips%ftcollins.ncr.com 2001 Danfield Ct. Ft. Collins, CO. 80525 ...uunet!ncrlnk!ncr-mpd!bach!chuckp