Subject: Re: more on cache ops... What are they actually supposed to do?
To: None <jeffs@geocast.com>
From: Chris G. Demetriou <cgd@sibyte.com>
List: port-mips
Date: 06/19/2000 17:53:19
Jeff Smith <jeffs@geocast.com> writes:
> Each of your e-mails has a ton of things in it.

yes.  This is basically a case of going through the code, trying to
figure out what, exactly, a new set of cache op functions must do, and
being amazed at the situation that's there.  (The most amazing things
are the obvious inconsistencies, e.g. "assumes 16-byte cache lines"
when it actually assumes 16-byte primary cache lines and 32-byte
secondary cache lines, and the fact that some of the functions used
for the same purpose have dissimilar documentation of their supposed
arguments.)


> For the first part, there are a lot of cache op
> varieties for the various platforms.  I don't think
> the current set-up is that bad.

certainly, there are a few varieties.  In the future, there will
undoubtedly be many more, though, and the existing code isn't
well-suited to that.  I think i disagree about 'that bad', because the
existing source encodes a lot of assumptions, does not document them,
and does not provide any flexible way to avoid them.


How about we nail down the basics, specifically, what are the
assumptions, requirements, and intended uses of the functions which
implement the:

	MachFlushCache
	MachFlushDCache
	MachFlushIcache

functionality?

As far as I can tell, a basic functional description of these
functions goes something like:

	MachFlushCache: flushes the entire cache system, including
	primary and secondary I and D caches.

	MachFlushDCache: flushes the given virtual(?)
	[address,address+size] range from any (primary, secondary,
	tertiary) d-cache.

	MachFlushICache: flushes the given virtual(?)
	[address,address+size] range from any (primary, secondary,
	tertiary) i-cache.

(That touches nothing of the actual calling conventions, e.g. the
'must not touch v0' bit for FlushICache for instance, nor of the
assumptions about cache line size.)

Is that rough functional description correct?

If so, on what basis is it "more correct," or even correct, to use the
'index' ops rather than the 'hit' ops to do the latter two functions?


To follow up on one of my previous questions, about the use of the
MachFlush[ID]Cache routines on mips1: they're used with different
arguments, based on other checks of whether or not the CPU is mips1
vs. mips3.  Is there any reason the code uses the same #defined name
to wrap functions which take such radically different arguments?



cgd