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: <6416@cbmvax.UUCP>
Date: 29 Mar 89 01:16:47 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> <22974@ames.arc.nasa.gov>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 20

In article <22974@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes:
>Things are getting to a very interesting stage, however.  I guess it is just
>my big machine history showing again, but I keep wondering why, with a decent
>sized register file, it wouldn't make more sense to put all FP/ALU hardware on
>the same chip as the control unit, along with the instruction cache, 
>and leave the MMU, and the data cache (which is almost always going to be 
>larger than what you can put
>on a chip no matter how large the chips get), to an external implementation.

	The problem with this is that off-chip access is slower than on-chip,
due to signal load and pad static-protection capacitance.  If someone can do
away with some or most of the pad capacitance, then off-chip caches become
the way to go.  As it is, it's a balancing act, and things like branch-target
internal caches become very useful, with external caches to supply straight
instruction streams and data (or internal I & D caches, if you can fit
signifigant ones on-chip, or it's being designed for a small-chip-count
application).

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