Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mimsy!oddjob!gargoyle!ihnp4!alberta!ubc-vision!attvcr!jroberts
From: jroberts@attvcr.UUCP (John Roberts)
Newsgroups: comp.arch
Subject: Re: Phys vs Virtual Addr Caches
Message-ID: <697@attvcr.UUCP>
Date: Fri, 17-Jul-87 12:07:21 EDT
Article-I.D.: attvcr.697
Posted: Fri Jul 17 12:07:21 1987
Date-Received: Sat, 18-Jul-87 18:47:07 EDT
References: <3904@spool.WISC.EDU>
Organization: AT&T Canada, Vancouver, BC
Lines: 21
Summary: Exists already!

In article <3904@spool.WISC.EDU>, lm@cottage.WISC.EDU (Larry McVoy) writes:
> Here's a question.  Why do people build their caches to respond to physical
> addresses instead of virtual addresses?  Another way to state the question
> is: why not put the VM -> PM translation logic next to (in parallel with)
> the data cache, rather than before it?
> 
> Am I missing something or is this the wave of the future?  

Actually, the 3B2/600 (and I would imagine many other machines) use a
virtual cache scheme.  In the case of the 3B2, its 6K partitioned as
4K instruction and 2K data (I think).  As to how the potential pitfalls
of this scheme are handled, I don't know.  Perhaps someone with more
detailed knowledge will post something.

BTW, the 600 will have a multi-processor board this fall.  It's a slave,
but it still may complicate things.

-- 
John M. Roberts            AT&T Canada  Vancouver  BC
(604) 689-8911             {ihnp4!alberta,uw-beaver}!ubc-vision!attvcr!jroberts
What! Me Worry?		   attsayi fsh!would