Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!prls!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.sys.m68k Subject: Re: The New Chips Message-ID: <1442@winchester.mips.COM> Date: 30 Jan 88 04:53:32 GMT References: <4746@watdragon.waterloo.edu> <1430@husc2.UUCP> <686@uthub.toronto.edu> <1417@winchester.mips.COM> <5683@iuvax.UUCP> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 53 In article <5683@iuvax.UUCP> bobmon@iuvax.UUCP (Bobmon) writes: >to John Mashey (whose return address didn't work) -- >OK, You've confused me by the following article (exerpts from comp.sys.ibm.pc). >You seem to assume that RISC machines require relatively few clock cycles >per "vax-mip". This would suggest that the instruction set is closely >matched to the things the benchmarks do ("vax-mip-instructions"?). >I thought that one principle of RISC was that simpler instructions could >run fast enough to allow using more of them to get the job done. This would >mean (to me, anyway) more clocks per "vax-mip", albeit at a higher clock speed. >Would you please explain why Lower cycles/vax-mip means more RISCiness? A better way to state this is: at a given clock speed, make the computer do as much real work as possible. The clock speed tends to be a function of technology, which improves over time. RISC designers believe that, at the same clock speed, a well-engineered RISC should run faster than a CISC, using the following theory: a) A RISC may well use more instructions than the CISC. b) However, the RISC instructions use enough less cycles/instruction that the total cycle count is lower. c) The RISC may well use less hardware to do instructions, and hence, save hardware for other speed-enhancing operations. Anyway, the typical goal of designers is to find that mythical "optimal point", where everything you have pays for itself, and you're not missing something that would pay for itself. More RISCiness: there are a lot of attributes people have used to decide whether or not something is a RISC (like "every machine designed since 1983 is a RISC...:-)). The reasons I like the one I described are: a) The numbers are something you can determine by knowing a machine's clock rate, and running user-level benchmarks. I.e., this is a number you can measure in an objective way, without needing instruction + cache + mmu simulators, or hardware probes. b) Lower numbers usually correlate with machines called RISCs. Of course, it is quite possible (as Motorola has pointed out, and has IBM, DEC, etc have done for years on large machines), it is quite possible to lower the cycles/mip number for ANY machine by throwing hardware at it, usually by improving pipelining, improving the memory hierarchy, etc. For example, I suspect the biggest win in the 68030 is the 3->2 cycle bus interface change. The RISC argument says that a well-designed RISC gets the performance without burning up the silicon area, so it can use it for other things, and also takes less time to redesign for faster technologies. For more on this, this topic gets discussed over in comp.arch a lot more, and there are plenty of reasonable articles on the topic. -- -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