hedrick@geneva.rutgers.edu (Charles Hedrick) (02/22/89)
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.
richard@uunet.uu.net (Richard Bishopp) (02/22/89)
In article <15686@mimsy.UUCP> folta@tove.umd.edu (Wayne Folta) writes: >A co-worker and I were debating why RISC machines might be faster than >CISC (traditional) machines. I had just read an article that did some >UNIX benchmarks, and found RISC machines ran about 3 times faster than >CISC (a 68030-based machine, for example). > >The question is why. The name RISC is actually a bit of a misnomer (or misacronym?). RISC should be RICC - Reduced Instruction Cycle Computer. The only way for a computer to go faster is to execute an instruction in a shorter time. If you look at the CPU cycle time on a benchmark you should find the RISC machines have a considerably shorter CPU cycle. Another reason why RISC can be better is that the design of the CPU is simpler. In other words you can optimize some parts of the CPU to go faster. A limitation in a micro-coded machine is the cycle time to access the microcode memory and decode the instruction. Most RISC machines have some sort of internal ROM (or PLA) to decode instructions which is inherently faster than accessing off-chip memory of microcode. If the chips also have a large number of registers to store data you can reduce the external accesses to memory - besides memory is easy to make on a chip. I learnt all this while working at Acorn Computers (England) on the design of the ACORN RISC machine which I think is now being used by Olivetti in their laser printers etc. I have lots of references if anyone is interested. Richard Bishopp
AKONSTAM@TRINITY.BITNET (AARON KONSTAM) (02/22/89)
<Wayne Folta asks: Is Risc faster? (V7n142) The best place to find a clear and concise expalnation of why RISC machines are faster than CISC machines in the first two chapters of the book, "RISC Architecture" by Daniel Tabak, Research Studies Press(John Wiley ,1987). Briefly the reasons are as follows: a. 10% of the RISC chip is taken up with the control unit as opposed to 60% of the area of the MC68000. There are only a very few instructions (about 30 on most RISC machines) which execute in one clock cycle. They are fast enough that a set of RISC instructions that do the same job as one 68000 instruction execute faster than the 68000 instruction. b. RISC machines are however much slower in doing things like floating point instructions so they cheat and have floating point coprocessors to do the floating point arithmetic. c. The rest of the area on the RISC cpu chip are taken up by a larger number of registers. This allows more register-register processing instead of register-memory processing. d. Each process is given a register window for its local variables. These widows are made to overlap so that a calling process shares resgisters with the process it calls. By means of these shared registers arguments are passed between the processes (or really not passed so calls are executed faster). Ther is more to be said about this but I hope this is helpfull. AARON KONSTAM Trinity University 715 Stadium Dr. San Antonio, Tx 78284 (512)-736-7484 AKONSTAM.TRINITY.BITNET
aad@stepstone.com (Anthony A. Datri) (02/22/89)
In article <15686@mimsy.UUCP> folta@tove.umd.edu (Wayne Folta) writes: >A co-worker and I were debating why RISC machines might be faster than >CISC (traditional) machines. I had just read an article that did some >UNIX benchmarks, and found RISC machines ran about 3 times faster than >CISC (a 68030-based machine, for example). *WHICH* RISC machine? RISC is a general description of a style processor design, not a specific implementation. >The question is why. I had assumed that a RISC machine had a much smaller >and simpler instruction set. That is, fewer instructions, each of which >did simpler things than a CISC instruction set. True. >But how can this make a >machine that much faster? Is it because most CISC machines are >microcoded? I think microcoding is a seperate issue. One of the usual ideas about RISC machines is that all instructions execute in one cycle. >It seems to me that to accomplish the same work, the RISC machine would >just have to execute more instructions than the CISC machine. It often will. The idea is that you get a code generator that is really smart, and can output code that does fewer unnecessary things than your average ciscish code. I've heard that IBM's PL.8 compiler is one such. But on the other hand, your executables are often bigger, and that means you should have more memory, bigger disks, and that you spend more time paging and swapping things around. Followups to comp.arch [[ Agreed! Usenet people, please follow up to comp.arch. Non-Usenet people, I don't think there is a suitable forum. --wnl ]] Anthony A. Datri @SysAdmin(Stepstone Corporation) aad@stepstone.com stpstn!aad
hawkes@mips.com (John Hawkes) (03/08/89)
AKONSTAM@TRINITY.BITNET (AARON KONSTAM) writes: >b. RISC machines are however much slower in doing things like floating >point instructions so they cheat and have floating point coprocessors to >do the floating point arithmetic. Slower? Not necessarily. The MIPS R2010 and R3010 VLSI FP coprocessors execute an add in two cycles, a multiply in four or five cycles, and a divide in 12-19 cycles. The R3010 has a 40 nsec cycle. These coprocessors are pipelined and can concurrently execute multiple fp instructions (with some constraints). Other RISC architectures are similar. Cheating? There are at least two obvious advantages of using a coprocessor: you double the size of the available silicon for a given level of integration, and you make it potentially easier to design a functional unit which can execute in parallel with the main processor. >d. Each process is given a register window for its local variables. These >widows are made to overlap so that a calling process shares resgisters >with the process it calls. By means of these shared registers arguments >are passed between the processes (or really not passed so calls are >executed faster). Ther is more to be said about this but I hope this is >helpfull. This is a description of a Register Window architecture, which is not universal among RISC implementations. For example, SPARC uses Register Windows, MIPS doesn't. There are advantages and disadvantages to Register Windows, some architectural and some implementational. John Hawkes DISCLAIMER: <generic disclaimer, what do I know anyway, etc> {ames,decwrl,prls,pyramid}!mips!hawkes OR hawkes@mips.com
frode@uunet.uu.net (Frode Odegard) (03/08/89)
I think maybe National Semiconductor should be given some credit for their work on the 32532 and (the upcoming) 32764. This is CISC at its best, the instruction set has been exactly the same since good old 16032 (later renamed to 32016) came out out, only that the implementation has been vastly improved of course. Maybe Sun should have looked at NS? I'd pick NS over SPARC any day if I were to build a computer running high-level language applications. With RISC there is also the problem with generating good code. Some of the commercial RISC implementations are so "obscure" that the compiler writers have to make sure to insert "pause" instructions to avoid some nasty effects. With nice instruction sets like the one of the NS32000 family, compiler writers don't have to think in terms of what goes on INTERNALLY in the cpu. Maybe this isn't so bad with SPARC, I dunno. Sun having picked SPARC whoever, I think it is nice that they want people to make clones. Cheap SPARC clones would be nice, maybe Sun will be able to make the PC recolution happen all over again, only in the workstation world? At least this is what they're telling us... - Frode Frode L. Odegard Modula-2 CASE Systems NORWAY (EUROPE) Email: frode@m2cs.uu.no