Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!think!ames!ucbcad!ucbvax!decvax!decwrl!pyramid!amdahl!dlb!auspyr!sci!kenm
From: kenm@sci.UUCP (Ken McElvain)
Newsgroups: comp.arch
Subject: Re: Phys vs Virtual Addr Caches
Message-ID: <7483@sci.UUCP>
Date: Fri, 17-Jul-87 16:25:42 EDT
Article-I.D.: sci.7483
Posted: Fri Jul 17 16:25:42 1987
Date-Received: Sun, 19-Jul-87 00:44:51 EDT
References: <3904@spool.WISC.EDU>
Organization: Silicon Compilers Systems Corp. San Jose, Ca
Lines: 29
Summary: cache set size

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.

There are quite a few machines that use virtual addresses for the data
cache (Amdahl,Sun,..).  That way the translation is only needed for
cache misses.  This creates major problems if the virtual address
space can be aliased (Two virtual addresses mapping to one physical address)
because IO is usually done with physical addresses and a reverse
translation is needed.  This is apparently not insoluable since the
Amdahl has this problem.   Multi-processor systems will have a like
problem.

Another thing you can do is to limit the cache set size to the virtual
page size.  Then the address translation can happen at the same time
as the tag set access and finish in time to compare with the output
of the tag rams.  This doesn't work too well with machines with small
page sizes like a Vax but can be reasonable if the page size is ~4Kb
and up.

Ken McElvain
decwrl!sci!kenm