From: "Dominic Sweetman" <dom@algor.co.uk>
> Carsten Langgaard (carstenl@mips.com) writes:
>
> > I think we have a problem with the PREF instructions spread out in the
> > memcpy function.
>
> Not really. The MIPS32 manual (for example):
>
> "PREF does not cause addressing-related exceptions. If it does happen
> to raise an exception condition, the exception condition is
> ignored. If an addressing-related exception condition is raised and
> ignored, no data movement occurs."
>
> PREF never generates a memory operation for a location with an
> uncached memory access type."
>
> For a Linux user program, at least, memory pages are "memory-like":
> reads are guaranteed to be side-effect free, so any outlying
> prefetches are harmless. It's hard to see any circumstance where an
> accessible cacheable location would lead to bad side-effects on read.
In case Carsten's reply wasn't clear enough, there is a loophole
in the spec: kseg0. There is no TLB access to cause a TLB
exception (which would suppress the operation and be nullifed),
If the prefetch address is correctly aligned, so that there is no
address exception. In typical use, kseg0 is cacheable, which
means that the second paragraph you quote does not apply.
A prefetch to a well-formed, cacheable kseg0 address which
has no primary storage behind it (e.g. 0x04000000 on a system
with 64M of physical memory) should, according to the spec,
cause a cache fill to be initiated for the line at that address,
which will result in a bus error, if not a flat-out system hang.
Regards,
Kevin K.
