Path: utzoo!mnetor!uunet!yale!mfci!root From: root@mfci.UUCP (SuperUser) Newsgroups: comp.arch Subject: Re: RISC a short answer?? Message-ID: <383@m3.mfci.UUCP> Date: 4 May 88 13:06:13 GMT References: <1036@nusdhub.UUCP> <1988May3.224604.2252@utzoo.uucp> Reply-To: mfci!colwell@uunet.UUCP (Robert Colwell) Organization: Multiflow Computer Inc., Branford Ct. 06405 Lines: 57 In article <1988May3.224604.2252@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >> Can someone give me [short answer style] a description >> of what "RISC" means... > >Many people confuse things that are often characteristics of current RISC >designs with the fundamental underlying idea, which is: > > Keep the instruction set simple. > >Most instructions actually executed are simple even if the instruction set >is complex. Leaving out the complexity makes it easier to make the simple >stuff fast. Since the simple stuff accounts for most of the execution >anyway, the result is faster machines. > >This is *not* the same as "throw the complexity into the software", since >a simple instruction set frequently makes compilers etc. *simpler*, other >things being equal. >-- >NASA is to spaceflight as | Henry Spencer @ U of Toronto Zoology >the Post Office is to mail. | {ihnp4,decvax,uunet!mnetor}!utzoo!henry I consider this a good explanation of what RISC was, circa 1981-1983. But if that's ALL you consider RISC to be, then I think you're missing some very important things. A simple instruction set makes a simple compiler *possible*, but so what? If you implement a simple compiler and I implement one that utilizes my highly-pipelined RISC machine better, my object code will run considerably faster than yours. (And if I didn't pipeline it, I've already lost the battle.) Only if we're not interested in performance does your case hold, and while there are large areas of the computer design space for which that premise is valid, like high-reliability systems, it's performance that drives RISC designs. And compilers that must manage at compile-time what hardware interlocks used to do at run-time are simple no longer. It's just a price you pay for performance. Your point about making simple stuff fast is legit. The way I look at is this: if your basic technology allows a register-to-register operation in X ns, and adding some fancy instruction would require you to lengthen that period to X+e, then you had better be really sure that your new instruction is worth it, because you'll be penalizing something like 70% of the executed instructions for the ability to occasionally invoke the slow one. In a lecture he gave at CMU in 1984, John Cocke was willing to extend this principle all the way down to the one extra gate you need to allow a microcoded set of complex operators to co-reside in a CPU with the hardwired set that implemented loads, adds, and so on. Personally, I wouldn't go that far, because I think it's often the case that something else, like on/off chip delays, rear their ugly heads before that extra gate forces a longer critical path, but that doesn't exonerate designers from considering this problem. Bob Colwell mfci!colwell@uunet.uucp Multiflow Computer 175 N. Main St. Branford, CT 06405 203-488-6090