jgh@root.co.uk (Jeremy G Harris) (10/21/87)
Could someone remind me of the arguments against caching in physical space? I was thinking about how the 29000 really cries out for an i-cache and it hit me that, because of the onboard address translation, it could not be a virtual-address cache. Cheers, Jeremy -- Jeremy Harris jgh@root.co.uk
tim@amdcad.AMD.COM (Tim Olson) (10/26/87)
In article <443@root44.co.uk> jgh@root.co.uk (Jeremy G Harris) writes: | Could someone remind me of the arguments against caching in physical space? | | I was thinking about how the 29000 really cries out for an i-cache and it | hit me that, because of the onboard address translation, it could not be | a virtual-address cache. Actually, physical caches are the most "natural" and have the least amount of design headaches. Virtual caches are used on processors with external MMUs to get around adding "wait-states" for translation, but they have to be designed to overcome problems associated with: * context switch the cache must be flushed or process-id tags must be included. * aliasing Two virtual addresses may map to the same physical address; the cache must be prevented from caching both addresses to maintain consistancy. * consistancy in multiprocessing implementations -- Tim Olson Advanced Micro Devices (tim@amdcad.amd.com)
aglew@ccvaxa.UUCP (10/28/87)
..> Caching in physical vs. virtual space. The basic reason to do caching by virtual address is speed, if your cache is tightly bound to your system: it means that you can start a cache access before doing a virtual-to-physical translation. Various people have pointed out that if you are lucky, you can start the cache access with bits of the virtual address that aren't affected by the translation; and then, of course, there is AMD, whose "carefully tuned pipeline architecture" eliminates the need to do almost any work at all :-). Apart from that a physical cache wins just about hands-down over a virtual cache: it is easier to keep consistent, easier to share among multiple processes, and so on. Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms.arpa I always felt that disclaimers were silly and affected, but there are people who let themselves be affected by silly things, so: my opinions are my own, and not the opinions of my employer, or any other organisation with which I am affiliated. I indicate my employer only so that other people may account for any possible bias I may have towards my employer's products or systems.