Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!uiucdcs!uxc.cso.uiuc.edu!urbsdc!aglew
From: aglew@urbsdc.Urbana.Gould.COM
Newsgroups: comp.arch
Subject: Re: SPARC and multiprocessing
Message-ID: <28200138@urbsdc>
Date: 5 May 88 04:04:00 GMT
References: <51321@sun.uucp>
Lines: 25
Nf-ID: #R:sun.uucp:51321:urbsdc:28200138:000:1462
Nf-From: urbsdc.Urbana.Gould.COM!aglew    May  4 23:04:00 1988


>	Another problem, is simply the implementation of the reverse TLB -
>	what happens when the reverse TLB misses?  Which set of page tables
>	should the TLB walk?

If we are still talking about virtual caches, then you don't need a reverse TLB.
What you do is have two sets of cache directories, one physical, one virtual.
Use the virtual directory on local access to the cache.
Use the physical directory when snooping on the bus.
The bus carries physical addresses, not virtual.

The virtual/physical synonym problem can be solved in several ways.
(1) arrange the cache so all virtual addresses for the same physical location
map to the same set. Requires a bit of work when replacing synonyms in the 
same set, but is better than having to search the entire cache.
(2) still use a virtual to physical translation, but take it off the critical
path. Ie. access the cache using the virtual address, assuming that there are
no synonyms. But, at the same time, initiate the virtual to physical 
translation. Later, on the next cycle if your TLB is fast enough, or much later
if the TLB misses (may have to stall processor, but TLB misses are rare),
when you've got the physical address see if there was already such a location
in cache - backup and repair if stale data was read.
(3) Arrange with the OS so that condition (1) is satisfied, or even to maintain
the invariant that there are no synonyms, or that synonyms are used in
carefully controlled situations.