davidsen@steinmetz.ge.com (Wm. E. Davidsen Jr) (03/24/89)
Would someone like to describe the less obvious features of cache types in terms of real estate, design problems, etc? I see lots of allusions but damn few hard facts. Unless you disagree with these, they've been mentioned many times: virtual: fast, no address translation needed physical: no need to flush on context switch no aliasing problems -- bill davidsen (wedu@crd.GE.COM) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
tim@crackle.amd.com (Tim Olson) (03/25/89)
In article <13413@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: | Would someone like to describe the less obvious features of cache types | in terms of real estate, design problems, etc? I see lots of allusions | but damn few hard facts. | | Unless you disagree with these, they've been mentioned many times: | virtual: | fast, no address translation needed | physical: | no need to flush on context switch | no aliasing problems Also add: physical: easier to design in multiprocessing features, such as bus-snooping & ownership; virtual caches may require reverse translation maps. can be accessed in parallel with MMU translation if cache-line indecies are taken from the untranslated address bits (I believe the 88200 does this). This can allow physical caches to be as fast as virtual. -- Tim Olson Advanced Micro Devices (tim@amd.com)
carlton@betelgeuse (Mike Carlton) (03/25/89)
In article <24974@amdcad.AMD.COM> tim@amd.com (Tim Olson) writes: >In article <13413@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >| Would someone like to describe the less obvious features of cache types >| in terms of real estate, design problems, etc? I see lots of allusions >| but damn few hard facts. ... > >Also add: > physical: > easier to design in multiprocessing features, such as > bus-snooping & ownership; virtual caches may require reverse > translation maps. To stand up for virtual caches, I don't think it has to be that bad. You can do snooping coherency on virtual addresses. Or if you are running inverted page tables, the physical to virtual translation is trivial. > > can be accessed in parallel with MMU translation if cache-line > indecies are taken from the untranslated address bits (I > believe the 88200 does this). This can allow physical caches > to be as fast as virtual. True, but this gets harder as your cache grows. In particular, the page size must be large enough to contain those untranslated bits. E.g. a direct-mapped, byte-addresed cache (the worst case), requires a page size at least as large as the cache (i.e. 64K pages for a 64K cache) for this trick to work. As memory sizes grow the trend is to larger caches, but how large a page size is acceptable? Increasing the set associativity reduces the required page size, but slows the cache access. > -- Tim Olson > Advanced Micro Devices > (tim@amd.com) -- Mike Carlton, UC Berkeley Computer Science Home: carlton@ji.berkeley.edu or ...!ucbvax!ji!carlton