[comp.arch] physical vs. virtual cache

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