Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!helios.ee.lbl.gov!ncis.llnl.gov!lll-winken!uunet!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: RISC as a "technology window"?
Message-ID: <6415@cbmvax.UUCP>
Date: 29 Mar 89 01:11:44 GMT
References: <1552@vicom.COM> <15690@cup.portal.com> <1562@vicom.COM> <15702@clover.ICO.ISC.COM> <27681@apple.Apple.COM> <15695@winchester.mips.COM>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 33

In article <15695@winchester.mips.COM> mash@mips.COM (John Mashey) writes:
>>> In article <37196@bbn.COM>, slackey@bbn.com (Stan Lackey) writes:
>>> > RISC is indeed a technology window, driven largely by the amount of
>>> > stuff you can fit in a chip...
>....
>Seriously, I doubt that anyone has silicon to burn.  In particular,
>the faster the chips get, the more it hurts you to go off chip.
>Bigger on-chip caches [I, D, or TLB] keep you on-chip more, and are
>therefore good.  With more hardware, you can make integer multiplies go
>faster, make FP go faster, and maybe put in some multiple FP units,
>a la CDC 6600s [and these things chew up area]. Note that Intel, with
>a million transistors, said the space budget didn't leave room for
>an IEEE divide..... (Compcon paper).

	Quite true.  If CPUs continue to get faster (at the process level -
smaller in design rules) The relative overhead for off-chip access will
increase.  I think this will cause one of two things to happen, or maybe
a compromise between them: 1) Bigger caches, or more sophisticated caches;
2) More complex (relatively) instructions, either addressing modes or things
like multiple ALUs for address calculation or ..., in an attempt to reduce
the number of off-chip fetches.

	I think the i860 is a step down this path.

>	c) If you double the size of a giant-monster-chip, its yield
>		might get a lot worse...

	P(good 2-cpu chip) = P(good 1-cpu chip) ** 2

or something close to that.

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup