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