PSARC 2009/039 prefetch interfaces

[James Carlson]

Paul Durrant writes:
> James Carlson wrote:
> > 
> > void prefetch_read_once(void *)
> > void prefetch_read_many(void *)
> > void prefetch_wrote_once(void *)
> > void prefetch_write_many(void *)
> > 
> > (With the odd write/wrote distinction and with the arguments not
> > const'd the way I would ordinarily have expected.)
> > 
> > Is this it?
> > 
> 
> It should be prefetch_write_once(void *)

That's better.

> and I don't believe const is 
> appropriate here since the pointers are most likely to be to data that 
> would ordinarily change (DMA buffers in my use case).

The function itself doesn't actually cause that to happen, though; the
hardware does.  Even if you didn't mess with the prefetch, these
buffer content changes would *still* appear.  The compiler needn't
assume that the buffer changes as a specific synchronous effect of
that function.

Instead, _your_ code needs to be aware of the fact that there's an
unseen hand that's twiddling the bits, which is the definition of the
'volatile' keyword.  You need 'volatile' on your pointers to generate
correct code, but I don't think these functions need writability to
operate.

In fact, as a very narrow use-case, consider a read-only device.  Your
pointer would be something like "const volatile uchar_t *", to
indicate that your code can't write to it (const) and that references
can't be optimized because it changes in ways not obvious in the code
(volatile).

Anyway, I think that's probably a nit for the prefetch_read_*
functions.  After fixing "wrote" to "write," I'll give it a +1.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677