On Sun, Mar 27, 2005 at 01:23:20AM +0100, Lennart Augustsson wrote:
> >I think we want a MI function to stop the processor from reordering
> >instructions too. There is potentially a similar problem in the esiop(4)
> >driver than the one I had with xen. I could abuse bus_space_barrier()
> >for this but it's not quite right either.
> >
> >If we don't want the compiler to reorder instructions, I don't think we 
> >want
> >to CPU to do it.
> 
> You may want to disallow the compiler to reorder, but allow the CPU to.
> E.g., when programming with threads on a single CPU.  The CPU reordering
> (on an x86) never changes how the processor sees the memory if it is the
> only client of the memory.

Sure, this is also why I didn't change all __insn_barrier() to x86_lfence()
in xen/. But even on single-CPU systems you need to dissalow the CPU
reordering, for example when talking with a device.

> 
> So I think there is a case for both.  And yes, of course we want MI ways
> of doing it.  There is a whole range of possible fences one can imagine
> and they carry different costs depending on the platform.

Then we badly need to define theses, yes. And maybe refine the
bus_space_barrier() too ? From sparc64/bus.h:
        /*                            
         * We have a bit of a problem with the bus_space_barrier()
         * interface.  It defines a read barrier and a write barrier
         * which really don't map to the 7 different types of memory
         * barriers in the SPARC v9 instruction set.
         */

So just "BUS_SPACE_BARRIER_READ/WRITE" isn't enouth :)

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--