On Tue, Feb 09, 1999 at 09:56:49AM -0800, Eduardo E. Horvath wrote:
> On Tue, 9 Feb 1999, Ignatios Souvatzis wrote:
> 
> > - Some people said the MIPS ABI for the cache synchronization provides
> > enough functionality, and 3rd-party programs (that need it) are likely to
> > know how to use it, so we should not invent a new interface. (Jason Thorpe
> > expressed this earlier on this list).
> > 
> > [[I feel this is a valid argument. Additionally whatever I wanted to do with
> > this work can be done with the MIPS ABI.
> 
> >From what I know about the MIPS ABI I do not feel that it is sufficient
> to handle all possible cache/CPU architectures.  You can have any
> combination of:
> 
> 	physical 	or 	virtual
> 	split 		or 	unified
> 	writeback 	or 	write through
> 	snoopy		or	not snoopy
> 	Uni-processor	or	MP
> 
> And with multiple cache levels you can have different combinations at each
> level.  Let's take a nasty example of a non-snoopy split virtual
> write-back cache on an MP system, which is probably the nastiest of the
> bunch.  
> 
> When generating new JIT code you need to a way to do I$/D$
> synchronization.  You need to communicate this to all the other CPUs to have them
> invalidate their D$ *and* I$ also.  
> 
> When spinning on a lock the CPU doing the spinning needs to invalidate its
> D$, and the CPU who grabs/releases the lock needs to force the store of
> the lock through its D$ and store buffers to RAM.

Uhm, no. Real CPUs (I've read a lot of PPC documentation in the last year) have
special primitives to build synchronization code... and were not, you could 
always create a system call to deal with this.

	-is