Path: utzoo!attcan!uunet!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!brutus.cs.uiuc.edu!psuvax1!rutgers!att!tsdiag!pedsga!petsd!tinton!dan From: dan@tinton.UUCP Newsgroups: comp.sys.ibm.pc Subject: Re: Why The Move To RISC Architectures? ('386 vs. RISC) Message-ID: <1990Mar27.192822.19315@tinton> Date: 27 Mar 90 19:28:22 GMT References: <28011@cup.portal.com> <1990Mar20.233504.4946@seri.gov> Reply-To: dan@tinton.UUCP (Daniel Masi ) Organization: Concurrent Computer Corp., Tinton Falls, N.J. Lines: 89 In article <1990Mar20.233504.4946@seri.gov> marshall@wind55.UUCP writes: >Will@cup.portal.com (Will E Estes) writes: > >>Finally, why is everyone so excited about RISC? > >Just a wild guess. Hardware guys like RISC, software guys like CISC. Actually, the *software* world seems to contain the large portion of RISC proponents. >RISC puts the work on the shoulders of the software folks. It is >easier to impliment RISC in hardware. WRONG. It simply changes the 'type' of work to be done. Given a certain board area for a processor board in a system, the board will be filled with chips, regardless of whether the CPU chipset is RISC or CISC. The hardware complexity of the BOARD is the same, with the following exception: RISC parts tend to run at higher clock freqs than their CISC counterparts, thus making it HARDER to design a RISC-based board. As for the hardware complexity of the chipset, it's probably a toss. The RISC chips are a design challenge in that they run at very high clock rates. Also, typically these parts have a hardwired instruction set, while I believe that CISC parts are usually microcoded (of course, I could be wrong...). >If I were developing software in assembler, I'd probably hate RISC. The software people actually have an easier time of it with RISC. a) you have less instructions to remember, and thus spend less time thumbing through the manual to try to find out whether the STRING_MOVE_CONVERT_ASCII_TO_INT_VECTOR_MULTIPLY instruction sets the carry flag. b) there are no superfast and glizzy instructions; thus, there is no temptation to badly structure a software system to try to make use of said instruction. this is important if you want to port the software system to another platform. c) if there are CISC-type functions that you commonly want to use, you can code them once and keep them around as a source library, similar to a library of commonly-used C routines that you may keep around. If you go to another platform, this library is probably straightforward (although time-consuming) to translate, since it is made up of rudimentary instructions that most likely have a one-to-one equivalent in the new instruction set. Admitedly, RISC takes a lot of the 'art and glamour' out of assembly programming. However, it is this artful use of complicated assembly instructions that causes software systems to be complicated, unreliably, unmaintainable, and nonportable. The simplification of the instruction set frees you up to apply your art at a higher level. >It is probably harder to write a compiler for RISC. HUH? Assuming you don't care about the performance of the generated code, it is a wash. If you do care, then RISC is the clear winner. The code generation section of the compiler (the only part of the compiler that will be drastically different between the two versions) is much less complex. This is basically because it has less to choose from. TRUE RISC, by my way of thinking, says that all instructions take equal time, and this time is not data-dependant. It is clearly easier to write a code generator/optimizer based on this assumption. Some commercial RISC parts do not have equal time per instruction, but it is close (much more so than typical CISC), and it is data-independant, which one can imagine is an important assumption for simlifying code generators. >If you use high-level languages, you may not care. >Users probably don't care unless one costs more for the same application >performance (which is all that really counts). Yes, you WILL care, even if you use high-level languages. The downside of RISC is that it is memory-hungry (for every complex machine instruction that you may have used in a CISC system, you may need 10 or 20 RISC instructions). The code that a compiler generates will take more memory space in a RISC system. Some estimate up to twice the space. This translates into more main memory for your system, as well as more disk storage space. Also, memory will be more expensive, since the typical RISC part will run faster and thus need higher memory speeds (or cache) to satisfy its faster instruction fetch rate. >Marshall L. Buhl, Jr. EMAIL: marshall@wind55.seri.gov ---------------------------------------------------------------- Dan Masi (dan@tinton.tinton.ccur.com) 201-758-7699 Concurrent Computer Corp. 106 Apple Street Tinton Falls, NJ 07724