linux-mips
[Top] [All Lists]

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

To: Richard Sandiford <rsandifo@nildram.co.uk>, GCC Mailing List <gcc@gcc.gnu.org>
Subject: MIPS atomic memory operations (A.K.A PR 33479).
From: David Daney <ddaney@avtrex.com>
Date: Tue, 18 Sep 2007 17:12:48 -0700
Cc: linux-mips@linux-mips.org
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 1.5.0.12 (X11/20070719)
Richard,

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"                         \
  "\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.

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.

Any feedback from linux-mips people is also solicited.

Thanks,
David Daney

<Prev in Thread] Current Thread [Next in Thread>