Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!microsoft!w-colinp
From: w-colinp@microsoft.UUCP (Colin Plumb)
Newsgroups: comp.arch
Subject: Re: RISC as a "technology window"?
Message-ID: <51@microsoft.UUCP>
Date: 24 Mar 89 14:00:21 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: w-colinp@microsoft.uucp (Colin Plumb)
Organization: very little
Lines: 28

lamaster@ames.arc.nasa.gov (Hugh LaMaster) wrote:
> So, my question is:  If you ASSUME that you have to have high speed
> arithmetic, what is the best way to partition functions between chips?
> I believe that the best way is Control, ALU/FPU, and instruction cache
> on one chip, and data cache/MMU on another chip.  Why doesn't the market
> agree with me?

Well, given that latency to memory is a serious problem these days, and
that MMU address translation is often on the critical path, moving
it off-chip doesn't sound like such a good idea.

I think the MIPS approach is the best: MMU and cache *control* on chip;
the actual data (which can be a trifle slower) can be put in external
SRAM.  SRAMs have a large market, so even ultra-fast ones are comparatively
cheap.  Associative memory is much more expensive.

I've said it before: I'm *astounded* nobody else has used this idea.
It's such a great Win.  Cache control is the custom bit, so do it
in custom logic.  With all the rest of the custom logic: on the
microprocessor.  Cache RAM is very generic.  So don't re-invent the
wheel.

Has anyone out there (other than MIPS, of course) considered this scheme
and then rejected it?  Is my enthusiasm blind to some Great Problem?
-- 
	-Colin (uunet!microsoft!w-colinp)

"Don't listen to me.  I never do." - The Doctor