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