Re: MIPS atomic memory operations (A.K.A PR 33479).

[Ralf Baechle <ralf@linux-mips.org>]

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