On Thu, 31 Jan 2002, Maciej W. Rozycki wrote:
> Hmm, wmb() is pretty clearly defined. The current implementation does
> not enforce strict ordering and is thus incorrect. Note that the R4400
> manual explicitly states a cached write can bypass an uncached one, hence
> the CPU may exploit weak ordering under certain circumstances. The "sync"
> instruction was specifically defined to avoid such a risk.
Yes, you are correct. I suppose *mb() must also work correctly with the
cache flush macros - didn't think about that one!
I'm afraid I don't have any manuals for any of the MIPS chips just 3rd
party ones SB1, RM7K and SR71000 - which is why I have some many
odd questions. :>
> > No, a sync will still empty the write buffer. It may halt the pipeline for
> > many (~80 perhaps) cycles while posted write data is dumped to the system
> > controller.
>
> Then it's an implementation bug. For a CPU in the UP mode "sync" is only
> defined to prevent write and read reordering -- there is nothing about
> flushing.
Did some more research + phoning.. RM7K is definately documented to dump
the write buffer on 'sync'. The RM7K guide even has an example (7.8.5)
where it implies that sync also forces a write back of any dirty cache
lines - gah! (Hard to belive though..)
Sandcraft tells me that sync only waits for outstanding reads on their
chips - so it is very cheap. Writebacks from cached and uncached writes
are never put out of program order.
Sorry my viewpoint is skewed by this small sampling of processors :<
> You need an "mb()", since you are changing the access type, so you need to
> synchronize both kinds.
OK.
> I don't understand what the purpose of the above code is, except that it
> wastes a cycle. Please elaborate.
There was a miscommunication on my part, please ignore it.
I hope Ralf accepts your patch, I think it will be good to have.
Jason