On Jun  3, 10:51pm, Michael L. Hitch wrote:
> On Jun  3,  3:22pm, Jonathan Stone wrote:
> > Hm.  can the mips3 "cache" insn handle physical addresses?
> 
>   "Sort of" ... the cache instruction takes a virtual address and
> translates it to a physical address using the TLB.  [I'd assume the
> TLB is only used for USEG and KSEG2 addresses, and the KSEG0 addresses
> map directly to the physical address.  KSEG1 addresses result in
> "undefined" operation.]
...
> > If it did, you could grovel, and then selectively writeback or
> > invalidate the physical pages.  (Virtual addresses arent quite enough,
> > since they could miss in the TLB.)
> > 
> > That's what michael and I had talked about doing for the cachectl
> > operations needed for (amongst other things) gcc/g++'s onstack
> > trampoline code, way back when.

  I think I do see a way this can be acomplished, but it's a bit nasty.

  The physical address would need to be converted to a KSEG0 address
and each possible cache line in the primary cache could be probed with
the cache "index load tag" operation.  Any entries that are tagged with
the given physical address could then be written back/invalidated by
the appropriate index operation.  For each given physical address, each
possible virtul index into the primary cache would need to be probed,
and the number of cache lines to check will vary depending in the
primary cache size [4 lines on the R4000 and 8 lines on the R4400, I
think].

  A "hit virtual" flush could be done the same way, using the virtual
address to compute the primary index, and testing the physical tag
to see if it matches the physical address.

-- 
Michael L. Hitch			mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA