Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!amdcad!crackle!tim
From: tim@crackle.amd.com (Tim Olson)
Newsgroups: comp.arch
Subject: Virtual caches & PIDs [was Re: i860 CPU information]
Message-ID: <24869@amdcad.AMD.COM>
Date: 16 Mar 89 01:25:09 GMT
References: <1895@oakhill.UUCP> <21570@shemp.CS.UCLA.EDU> <3024@alliant.Alliant.COM> <15213@winchester.mips.COM> <706@m3.mfci.UUCP> <21795@shemp.CS.UCLA.EDU>
Sender: news@amdcad.AMD.COM
Reply-To: tim@amd.com (Tim Olson)
Distribution: usa
Organization: Advanced Micro Devices, Inc. Sunnyvale CA
Lines: 27
Summary:
Expires:
Sender:
Followup-To:

In article <21795@shemp.CS.UCLA.EDU> loving@cs.ucla.edu (Mike Loving) writes:
| In article <15213@winchester.mips.COM> mash@mips.COM (John Mashey) writes:
| >As I posted in <15016@winchester>, you have to flush the caches
| >on context-switch in a single CPU, much less a multiprocessor.
| 
| 
| A popular misconception.  It is NOT necessary to flush the cache on a context
| switch.  If your cache is physically addressed and you do not include PIDs in
| the tags, then yes you do have to.  An example circumventing this is the new
| HP machines which use a virtually addressed (no address xlat delay) cache and
| do not flush the cache on context switches.

The context (no pun intended ;-) of John Mashey's posting was the i860,
which must have its caches flushed on context switches, even in
uniprocessor configurations.

I believe you have swapped the terms "physically" and "virtually" above
-- you need PIDs in *virtually* addressed caches to avoid address
aliasing problems.  This assumes that you have a write-through cache. 

Has anyone tried to use virtual, copy-back caches with PIDs to prevent
flushing like the i860 requires?  Problems of how to save modified data,
as well as the consistency of shared memory come to mind...

	-- Tim Olson
	Advanced Micro Devices
	(tim@amd.com)