Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site terak.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!hao!noao!terak!doug From: doug@terak.UUCP (Doug Pardee) Newsgroups: net.micro.68k,net.arch Subject: Re: RISC Message-ID: <601@terak.UUCP> Date: Fri, 7-Jun-85 13:50:46 EDT Article-I.D.: terak.601 Posted: Fri Jun 7 13:50:46 1985 Date-Received: Sun, 9-Jun-85 03:32:28 EDT References: <639@vax2.fluke.UUCP> <2743@nsc.UUCP> <576@terak.UUCP> <1590@amdahl.UUCP> <1303@hammer.UUCP> Organization: Terak Corporation, Scottsdale, AZ, USA Lines: 41 Xref: watmath net.micro.68k:889 net.arch:1347 > Some folks have decided that RISC means that you eliminate the > microcode and directly decode the operations. This is too narrow of a > view. An elephant is much like a tree, or is it a rope, or is it a snake... If we're going to talk about RISC, we'd better decide what we're going to call RISC. Is RISC: 1) a way to save silicon real estate on single-chip cpus? or 2) a concept that's equally applicable to board-level cpus? Is RISC: 1) strictly limited instruction set, essentially microcode level? or 2) any cpu without "useless" instructions? (define "useless") or 3) any cpu with oodles of registers? For the moment, I'm going to talk about non-microcoded single-chip cpus with strictly limited instruction sets. Something you'd put in a TTL system with dynamic RAMs. I've come to the conclusion that for this kind of RISC, its time has passed. It made a lot of sense in the late '70s when cpu cycles were 250-400 ns and memory cycles were 300-400 ns. But since then the cpu manufacturers have concentrated on speed while the memory manufacturers concentrated on capacity. With cpu cycles now at 60-100 ns and memory cycles at 225-325 ns, the way to improve speed in a system is to decrease memory cycles, not cpu cycles. That means making instructions even *more* complex, so that each instruction fetched does as much work as possible. At 100 ns per cpu cycle, you can afford to let the cpu do a lot of work that isn't always needed, because you can throw away *half* of it and still have the cpu be faster than if you fetched the microinstructions from main memory (using 120 ns access/220 ns cycle time 256K DRAMs). By the way, the Berkeley RISC-II chip has a 330 ns cpu cycle time. The 10 MHz NS32016 can do a 32-bit register-to-register signed multiply in 8.3 usec. The RISC-II cpu would have to be able to do the multiply in only 25 cpu cycles in order to compete. All the cache in the world ain't gonna help... -- Doug Pardee -- Terak Corp. -- !{ihnp4,seismo,decvax}!noao!terak!doug ^^^^^--- soon to be CalComp