Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request From: hedrick@geneva.rutgers.edu (Charles Hedrick) Newsgroups: comp.sys.sun Subject: Re: Is RISC faster Message-ID: Date: 22 Feb 89 10:17:48 GMT References: <15686@mimsy.UUCP> Sender: usenet@rice.edu Organization: Rutgers Univ., New Brunswick, N.J. Lines: 19 Approved: Sun-Spots@rice.edu Original-Date: 12 Feb 89 03:45:25 GMT X-Sun-Spots-Digest: Volume 7, Issue 164, message 1 of 9 I'm always wary of acronym games. Only marketeers like them. You get speed when the instructions that you use most run fast. There are several ways to do this. RISC is one approach. In its pure form (and most commercial RISC systems are not pure) it simplifies the instruction set (particularly addressing modes) so that all instructions that can be made to work in a single cycle. Thus some CISC instructions end up being replaced by several RISC instructions. The reason it works out is that normally you don't really need to use all those fancy instructions and addressing modes. That is, on average you don't really have to use 3 RISC instructions for every CISC instruction. In effect RISC wins because the CISC machine has to have extra complexity to handle fancy cases that aren't really needed in practice. However there are other approaches to going fast. We're starting to see chips that implement more traditional instruction sets, but make the common instructions execute in one cycle. Final results still depend upon the quality of design and execution -- as well as the compilers available for them -- at least as much as on things such as RISC vs. CISC. I think it's very interesting to know the approaches adopted by various designs, but I certainly wouldn't buy or not buy a product because it was RISC.