On Tue, Sep 18, 2007 at 05:12:48PM -0700, David Daney wrote: > There seems to be a small problem with the MIPS atomic memory operations > patch I recently committed > (http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01290.html), in that on a > dual CPU machine it does not quite work. > > You can look at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33479#c3 for > more information. > > Here is the code in question (from mips.h): > > #define MIPS_COMPARE_AND_SWAP(SUFFIX, OP) \ > "%(%<%[sync\n" \ > "1:\tll" SUFFIX "\t%0,%1\n" \ > "\tbne\t%0,%2,2f\n" \ > "\t" OP "\t%@,%3\n" \ > "\tsc" SUFFIX "\t%@,%1\n" \ > "\tbeq\t%@,%.,1b\n" \ Please make this loop closure branch a branch-likely. This is necessary as a errata workaround for some processors. (I know silicon people hate me for keeping branch likely instruction alive this way but it's my job to make sure Linux and software are working without unpleasant surprises.) > "\tnop\n" \ > "2:%]%>%)" > > > > I guess my basic question is: Should MIPS_COMPARE_AND_SWAP have a > 'sync' after the 'sc'? I would have thought that 'sc' made the write > visible to all CPUs, but on the SB1 it appears not to be the case. The MIPS architecture specification specifies no memory model, so for portable code you need to make a worst case assumption which is weak ordering. Only on R4000 and R4400 SC and SCD did imply a SYNC operation. > If we do need to add another 'sync' should it go in the delay slot of > the branch? I would say yes because we would expect the branch to > rarely taken. Not when using a branch likely. Btw, I recently wrote an article about memory consistency which is at http://www.linux-mips.org/wiki/Memory_consistency. It gives a bit of an overview of things in general and on MIPS specifically. I request people with detailed knowledge of MIPS cores not specifically covered in that article to contribute. Ralf
