Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!agate!bionet!apple!vsi1!wyse!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: RISC v. CISC Message-ID: <7841@winchester.mips.COM> Date: 8 Nov 88 08:09:33 GMT References: <156@gloom.UUCP> <890@cps3xx.UUCP> <10194@cup.portal.com> <754@wsccs.UUCP> <473@oracle.UUCP> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 79 In article <473@oracle.UUCP> csimmons@oracle.UUCP (Charles Simmons) writes: >In article <754@wsccs.UUCP> dharvey@wsccs.UUCP (David Harvey) writes: >>...... And miracle of miracles, we learn that >>over 70% of computing costs are software. It seems like hardware types >>should be designing their end of the deal to reduce it at the other end. >Hmmm... Bad example. The 8086 is an extremely unorthogonal >architechture. The 68000 isn't very orthogonal (there are two >different kinds of registers). RISC chips tend to be extremely >orthogonal. Thus, this example would suggest that RISC designers >are reducing the software complexity, and that it would be easier >to get something up and running on a RISC than on a 68000 (much >less an Intel chip). Yes, for sure: it's absolutely weird that people ahve decided that you must work much harder in software for RISCs: IT'S NOT THAT YOU NEED MORE COMPLICATED SOFTWARE FOR A RISC THAN A CISC, IT'S THAT WELL-DESIGNED RISCS OFFER MORE AND EASIER OPPURTUNITIES FOR OPTIMIZATION THAN SOME CISCs: a) You spend less time on weird-case selection and analysis. (should I do an add, or should I use weird-address-mode XX?) (registers x,y,z, and Q are needed for funny-instruction ZZ) b) You usually have more registers, and more orthogonal ones, hence global register allocation has more to work with, and you can think about things like interprocedural allocation (because you have a useful number of registers), whereas if you've only got half-a-dozen, you don't even think about it. c) It is usually easier to do pipeline reorganization, given the above, plus lack of things like condition codes. You don't HAVE to do much of this, but you can. At MIPS, the first reorganizer was written in a couple weeks. We had C/Pascal compilers generating reasonable code BEFORE the architecture was completely frozen (work really got started December 84/January 85, and we could run generated+linked executables through our MIPS->VAX object code converter around mid-year. A compiled UNIX was running on a simulator 11/85, and the compilers bootstrapped thru themselves successfully about the same time, including lots of optimization. Admittedly, MIPS didn't start from scratch, but used the work from Stanford. Nevertheless, reasonable code was generated pretty early.) As a datapoint, consider that an 8MHz R2000 (in a "5-mips" M/500), with global optimization omitted, and NoRegs, yields 8,800 1.1 Dhrystones, which is nowhere near the 13,000 it gets with -O3....but still faster than most CISC micro implementations. So, good optimization is worth having, but what you get without it isn't bad. (You also get 5900 DP Kwhets on a 12.5MHz R2000, which likewise is not awful.) In addition, let me observe, that certainly on machines of the MIPS, HP PA, 88K, SPARC ilk: a) It is probably simpler to write assembler code (at least compared with S/360s, PDP-11s, Vaxen, 3Bs, 68Ks , in my experience, and other people, not at MIPS, who've had experience with both MIPS and other architectures) b) The simpler machines often help things like: debuggers the object-code-to-object-code translators like we or Ardent use. (The profiling and architectural analysis of these are incredibly productive; they may exist on CISCs, but if so, not many.) object formats (like dense line number tables, not so easy to do with variable-length instructions) Anyway, the bottom line is: In many RISCs, some hardware functionality has moved to software, but the REQUIRED software is mostly straightforward and modular (like doing * or / in software), although it can get pretty tricky (like the more complex versions of doing these), but it's still modular. Clean RISCs give optimizing compilers more leverage, but it is pretty easy to generate at least reasonable code for them. -- -john mashey DISCLAIMER: UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086