On Jan 9, 2006, at 6:50 AM, Garrett D'Amore wrote:

> This is a good point.  I think Manuel's take on this is that the  
> platform code should be aware of this and do the "right" thing.   
> (I.e. insert whatever code is necessary to force the ordering.)
>
> I think this would be efficient and not a concern in any case.  My  
> concern was for those platforms (again, mainly MIPS because that's  
> what I'm working on) where the barrier is inplemented as a global  
> cache flush.

In general, I don't like the notion of relating memory barriers and  
cache operations.  A cache is a cache, and making a region cacheable  
implies all sorts of other possibly spooky things (i.e. the  
assumption that the region is "memory-like").  Barriers affect the  
order in which bus cycles are issued, and apply equally to cached as  
well as uncached regions.

> Now I had not considered whether any MIPS parts would reorder  
> memory accesses -- I don't think they do, otherwise things would be  
> horribly busted today, based upon what Manuel has already said  
> (namely that many drivers assume implicit barriers/ordering.)

Not sure about the SiByte parts... if we supported a MIPS part that  
did memory reordering, that would be the one... Chris will have to  
chime in :-)

That said, it very well could be platform-dependent whether or not  
memory reordering occurs on uncached space, and that could certainly  
make things works by side-effect (e.g. in the ARM universe, it's not  
possible to be bufferable-but-non-cacheable).

-- thorpej