I didn't convert LL/SC architectures so as to "encourage" them
to do atomic_add_unless natively. Here is my probably-wrong attempt
for powerpc.
Should I bring this up on the arch list? (IIRC cross posting
between there and lkml is discouraged)
You should bring this up on the arch list or it is likely to be missed by people
who would give you useful feedback.
+static __inline__ int atomic_add_unless(atomic_t *v, int a, int u)
+{
+ int t;
+ int dummy;
+
+ __asm__ __volatile__ (
+ LWSYNC_ON_SMP
I realize to preserve the behavior you currently get with the cmpxchg currently
used to implement atomic_add_unless that you feel the need to put in an lwsync &
isync. But I would point out that neither is necessary to actually atomic add
unless. They are simply so cmpxchg can be overloaded to be used as both a lock
and unlock primitive. If atomic_add_unless isn't being used as a locking
primitive somewhere I would love for these to be dropped.
+"1: lwarx %0,0,%2 # atomic_add_unless\n\
+ cmpw 0,%0,%4 \n\
This is just personal preference, but I find it more readable to use the
simplified mnemonic:
cmpw %0, %4
+ beq- 2f \n\
+ add %1,%3,%0 \n"
Why use a separate register here? Why not reuse %0 instead of using %1?
Registers are valuable.
+ PPC405_ERR77(0,%2)
+" stwcx. %1,0,%2 \n\
+ bne- 1b \n"
+ ISYNC_ON_SMP
+ "\n\
+2:"
+ : "=&r" (t), "=&r" (dummy)
+ : "r" (&v->counter), "r" (a), "r" (u)
+ : "cc", "memory");
+
+ return likely(t != u);
+}
+
#define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
