Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!husc6!spdcc!m2c!ulowell!apollo!fdr From: fdr@apollo.uucp (Franklin Reynolds) Newsgroups: comp.arch Subject: Re: Phys vs Virtual Addr Caches Message-ID: <361d2599.ccb2@apollo.uucp> Date: Fri, 17-Jul-87 09:48:00 EDT Article-I.D.: apollo.361d2599.ccb2 Posted: Fri Jul 17 09:48:00 1987 Date-Received: Sat, 18-Jul-87 13:58:14 EDT References: <3904@spool.WISC.EDU> Reply-To: fdr@apollo.UUCP (Franklin Reynolds) Organization: Apollo Computer, Chelmsford, MA Lines: 25 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? > >If you cache virtual addresses you can present the address to the cache >as soon as it is generated, no delay do translation. At the same time you >are doing the cache lookup you can be doing the translation in case there >is a miss. This idea has merit and some people already build virtual caches. Isn't the 68020 Icache virtual? I have heard rumors that the caches of the 68030 will be virtual. However, virtual caches are tricky. In order to avoid excessive cache flushing you usually have to include some sort of address space identification tag for each entry. You also have to decide whether you want to be able to support the ability to different virtual addresses to the same physical address (a very useful feature for systems that support shared memory or mapped files). Franklin Reynolds, Apollo Computer fdr@apollo.uucp mit-eddie!apollo!fdr