> How about we nail down the basics, specifically,

Good plan.

>         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.

I think this is correct for newer processors (R4000+).  The R3000
may have been different.  I can look at my R3000 books at work tomorrow.
 
> 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?

I think this needs more thought, and measurement.  We definitely want
to support the Hit flavor for the dcache.  With more 2 way machines,
the expense of the hit op vs and index op when you have to perform
2 index ops changes.  What does SiByte have?  EEtimes didn't say :-)

> 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?

This is just bizzare.  Your right, this is not a good practice.  The
number of places that cache ops are called is actually small enough
that the things can be managed explicitly with a cleaner API.

jeffs