You may want to avoid assembly magics:
static __inline__ void
__clear_bit_unlock(int const nr, volatile void * const addr)
{
volatile __u32 * const m = (volatile __u32 *) addr + (nr >> 5);
*m &= ~(1 << (nr & 0x1f));
}
GCC compiles volatile loads with ".acq" and stores with ".rel".
E.g. the following program:
int lo = 3;
main()
{
__clear_bit_unlock(1, &lo);
}
compiles into (NOP-s removed):
4000000000000680 <main>:0b 70 e0 03 00 24 [MMI] addl r14=120,r1;;
4000000000000686: f0 00 38 60 21 00 ld4.acq r15=[r14]
4000000000000690: 0a 78 f4 1f 2c 22 [MMI] and r15=-3,r15;;
4000000000000696: 00 78 38 60 23 00 st4.rel [r14]=r15
40000000000006ac: 08 00 84 00 br.ret.sptk.many
b0;;
Actually, we don't need a load with ".acq". A somewhat less readable code:
static __inline__ void
__clear_bit_unlock(int const nr, void * const addr)
{
__u32 * const p = (__u32 *) addr + (nr >> 5);
* (volatile __u32 *) p = *p & ~(1 << (nr & 0x1f));
}
gives you:
4000000000000680 <main>:0b 70 e0 03 00 24 [MMI] addl r14=120,r1;;
4000000000000686: f0 00 38 20 20 00 ld4 r15=[r14]
4000000000000690: 0a 78 f4 1f 2c 22 [MMI] and r15=-3,r15;;
4000000000000696: 00 78 38 60 23 00 st4.rel [r14]=r15
40000000000006ac: 08 00 84 00 br.ret.sptk.many
b0;;
that can be slightly more efficient.
Another remark:
We are adding more variants of existing funtions, e.g.:
clear_bit()
__clear_bit()
I've got problems with hidden semantics.
Just reading the source (where they are used), I simply cannot guess
if a primitive is atomic or not, if it is with some fencing or w/o.
Cannot we have some "speaking names"? E.g.: bit_unlock_Natomic_rel()
Zoltan Menyhart
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
