Jason R Thorpe <thorpej@zembu.com> writes:
> I think the problem here is that we're calling it an "I-cache flush",
> when what it really means is "I-cache invalidate".

I'm not convinced of that.  what you really mean is "make the
'instruction stream' consistent with the 'data stream'," i.e. what's
provided by the Alpha IMB PALcode call, with the addition of a range
of addresses for efficiency.  8-)

There's no reason, for instance, to invalidate the I-cache if it's
being kept coherent.  (I don't know of implementations that do that,
it's just that, if they did, you don't necessarily want the I-cache to
be invalidated.)


> We should settle on a decent naming scheme, here.  I would suggest:
> 
> 	Clean -- write-back (if necessary), but do not invalidate.
> 	Flush -- write-back (if necessary), and invalidate
> 	Invalidate -- not NOT perform any write-back, and invalidate

I think i'd change 'Clean' to 'Sync', leaving you:

	ISync
	DSync
	DFlush
	DInval(idate)

further:

* Sync should be allowed to invalidate if necessary, and
* Invalidate should be allowed to write-back if necessary.

(you kinda hinted at this, but don't actually state it.  Sync not
invalidating, and Invalidate not writing back, are performance
optimizations...)

(Of course, this all means that in an initial implementation could
just do Flush... which is what we have now, eh?  8-)


Anyway...


cgd