josh@polaris.UUCP (10/14/86)
In article <882@Shasta.STANFORD.EDU> simoni@Shasta.UUCP (Richard Simoni) writes: >This doesn't necessarily follow. Address translation is often done in >parallel with cache access by using only the low-order bits of the virtual >address (i.e., the bits that indicate the offset within the page) to address >the cache. This is possible because these offset bits do not change in >the virtual-to-physical mapping. When the cache access is complete, the >tag (which is a physical page number) is compared with the result of the >address translation (which happened in parallel with the cache access) to >see if a hit occurred in the cache. > >The problem with this scheme is that it can be difficult to build a large >cache since the page size limits the number of bits that can be used to >address the cache. The size of the cache can be increased by making the >cache set-associative and/or by increasing the page size (thereby >increasing the number of bits that can address the cache). ... The largest cache that can be implemented in this way is the product of the degree of set associativity and the page size. Larger caches can be implemented but you will sometimes have to take some extra cycles if you've "guessed" wrong (by using some of the virtual address bits before translation) about where things are. In the IBM 3090, the page size is 4K, the degree of set associativity is 4 and the cache size is 64K. Therefore the problem arises and is addressed (oops, sorry 'bout that) by comparing all 16 (!) real address tags and taking some small amount of extra time when the thing you want isn't exactly where you expected it to be. See the article on the 3090 in a recent issue of the IBM Systems Journal by Stu Tucker (Vol. 25, No. 1, 1986, pp. 4-19 "The IBM 3090 System: an Overview"). -- Josh Knight, IBM T.J. Watson Research josh@ibm.com, josh@yktvmh.bitnet, ...!philabs!polaris!josh