Path: utzoo!attcan!lsuc!maccs!cs4g6ag From: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) Newsgroups: comp.sys.ibm.pc Subject: Re: Why The Move To RISC Architectures? ('386 vs. RISC) Message-ID: <26083220.22927@maccs.dcss.mcmaster.ca> Date: 22 Mar 90 02:02:07 GMT References: <28011@cup.portal.com> Reply-To: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) Organization: McMaster University, Hamilton, Ontario Lines: 66 In article <28011@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: $Also, since the 80386 has a more complex instruction set and does $more work in a given instruction than does a typical RISC chip, $does comparing MIPS figures between RISC and non-RISC $architectures really tell you anything of worth? Well, if you're counting in native MIPS, no. If you're using VAX MIPS (which really aren't MIPS on anything other than a VAX), then yes. $Finally, why is everyone so excited about RISC? Why the move to $simplicity in microprocessor instruction sets? You would think $that the trend would be just the opposite - toward more and more $complex instruction sets - in order to increase the execution $speed of very high-level instructions by putting them in silicon $and in order to make implementation of high-level language $constructs easier. The reason is that RISC architectures run faster. Typically, it has been found that a given program implemented for a RISC processor takes around 30% more instructions, but the average instruction operates 3-5 times faster. Overall, then, you get at least a 2x increase in speed for a given clock rate. This is why RISC excites so many people. As for complex instructions ... RISC architectures typically have very efficient subroutine-calling methods specifically for such purposes. For example, a CISC chip would have a multiply instruction, whereas a RISC chip would have a multiply step instruction that implements one step in the multiplication. Each compiler would have in its library a subroutine that uses this multiply step instruction as the heart of a multiplication routine, and this subroutine is linked in using the efficient subroutine calling mechanism. The same idea is applied to other complex instructions - you use a subroutine from your compiler's library (which the compiler would put in automatically for you, just as a C compiler for a system with no floating point coprocessor automatically puts in a call to its own floating-point emulator) instead of a highly-complex instruction. This leads to another advantage - a given-size CISC chip has a very large (often over 50%) portion devoted to decoding instructions. On a RISC chip, the decoding logic is far smaller, leaving room for a barrel shifter, an on-chip cache, an on-chip MMU, or whatever - stuff that boosts performance. So, all in all, the complexity of high-level language constructs is partially built into the architecture of a CISC chip, whereas it's left up to the compiler in a RISC architecture. (Also, compilers for RISC systems generally have more optimization in them for such things as register usage - RISC chips usually have large numbers of registers - and to maximize the advantages of pipelined execution). This article, of course, is just a very, very brief overview; there are a lot of questions and answers about RISC that there just isn't room to discuss here (I did a seminar on RISC in a course last term, and had a _lot_ of trouble keeping the amount of material down to the 20 minute limit; I could go on for hours about RISC). If you want a lively discussion of RISC architectures, try reading comp.arch - this sort of topic pops up pretty frequently over there, so you won't have to read for long. Also, try looking through your local/campus library for computer architecture books and magazines. You'll find answers to all of your RISC questions are available there. -- Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca = "\nI'm only an undergraduate!!!\n"; **************************************************************************** "So sorry, I never meant to break your heart ... but you broke mine."