Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cornell.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!houxm!vax135!cornell!hal
From: hal@cornell.UUCP (Hal Perkins)
Newsgroups: net.micro.68k,net.arch
Subject: Re: RISC
Message-ID: <2335@cornell.UUCP>
Date: Sun, 9-Jun-85 15:32:36 EDT
Article-I.D.: cornell.2335
Posted: Sun Jun  9 15:32:36 1985
Date-Received: Mon, 10-Jun-85 22:07:50 EDT
References: <639@vax2.fluke.UUCP> <2743@nsc.UUCP> <576@terak.UUCP> <1590@amdahl.UUCP> <1303@hammer.UUCP> <601@terak.UUCP>
Reply-To: hal@gvax.UUCP (Hal Perkins)
Organization: Cornell Univ. CS Dept.
Lines: 18
Xref: watmath net.micro.68k:892 net.arch:1352
Summary: 

In article <601@terak.UUCP> doug@terak.UUCP (Doug Pardee) writes:
>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...

Now just a moment...  The Berkeley chips were built by academic folks
using conservative design rules, etc.  If they had been built by
experienced professional chip designers using state-of-the-art
technology they would have been a lot faster.  It's not fair to pick on
the relatively slow clock cycle of the experimental chips -- they were
built to prove a point (which they did), not to produce a product.
(I'm not making this up -- if you read some of the RISC papers by
Patterson and friends, et. al., they make the same point.)

Hal Perkins                         UUCP: {decvax|vax135|...}!cornell!hal
Cornell Computer Science            ARPA: hal@cornell  BITNET: hal@crnlcs