baskett@decwrl.UUCP (Forest Baskett) (11/12/84)
Peter Deutsch implies that a virtual address cache is the fastest kind, other things being equal (they never are). While there may be some truth to such an assertion, there are a sufficient number of interesting cases where it is possible for a real address cache to match the required performance of a virtual address cache that it is probably safer to assert that a virtual address cache is the simpliest fast cache. If you do your real address lookup in parallel with your cache lookup, you have only one level of latching just before the tag comparison to differentiate the two cases. Since the translation cache is often smaller than the instruction/data cache, technology will often make it faster so the extra level of latching may be covered up, too. This all works out with relative ease if your page size is large enough compared to your cache size. If you want to support multiple virtual address spaces, particularly in the case of multiprocessing, the extra complexity of a real address cache may be worth it. Forest Baskett - Western Research Laboratory - Digital Equipment Corporation
bcase@uiucdcs.UUCP (11/22/84)
[bug lunch] > Peter Deutsch implies that a virtual address cache is the fastest kind, other > things being equal (they never are). While there may be some truth to such an > assertion, there are a sufficient number of interesting cases where it is > possible for a real address cache to match the required performance of a > virtual address cache that it is probably safer to assert that a virtual > address cache is the simpliest fast cache. If you do your real address > lookup in parallel with your cache lookup, you have only one level of > latching just before the tag comparison to differentiate the two cases. > Since the translation cache is often smaller than the instruction/data cache, > technology will often make it faster so the extra level of latching may be > covered up, too. I am not ready to dispute your argument, but I don't think I understand: Doesn't the virtual address (in a real-address-taged cache) have to go through one level of mapping before it can be looked up in the cache tags? If so, then this would seem to say that a real address cache is slower than a virtual cache, but like I said, I don't think I understand your argument yet. Are you saying that the translation can be done very quickly with a small TLB (I agree here), and that it is so fast that the cache isn't slowed down (I'll have to think about this one)? Or are you saying that with a slight modification of the cache tag lookup procedure, the cache can lookup the real address and the cache tag at the same time (this sounds like what you are saying)? If you can, would you elaborate? -- Always looking for new ideas....