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.

Then things start geting even more complicated if the architecture has a
relaxed memory model where loads and stores can be re-ordered with
respect to each other and pass each other such as Alpha or SPARC.  

=========================================================================
Eduardo Horvath				eeh@one-o.com
	"I need to find a pithy new quote." -- me