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