lkml.org 
[lkml]   [2009]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 2.6.32-rc1
[Eric Dumazet - Wed, Sep 30, 2009 at 05:57:25PM +0200]
...
|
| > +#define cmpxchg64(ptr, o, n) \
| > +({ \
| > + __typeof__(*(ptr)) __ret; \
| > + __typeof__(*(ptr)) __old = (o); \
| > + __typeof__(*(ptr)) __new = (n); \
| > + alternative_io("call cmpxchg8b_emu", \
| > + "lock; cmpxchg8b (%%esi)" , \
| > + X86_FEATURE_CX8, \
| > + "=A" (__ret), \
| > + "S" ((ptr)), "0" (__old), \
| > + "b" ((unsigned int)__new), \
| > + "c" ((unsigned int)(__new>>32))); \
|
|
| Note:
|
| lock; cmpxchg8b (%%esi)
|
| gives 4 bytes opcode : f0 0f c7 0e
| Because alternative (call cmpxchg8b_emu) uses 5 bytes, a nop will be added.
|
| Choosing ".byte 0xf0, 0x0f, 0xc7, 0x4e, 0x00" aka "lock cmpxchg8b 0x0(%esi)" is a litle bit better ?
|

Just curious why not "nop; lock; cmpxchg8b (%esi)"? lock itself is destructive
instruction with causes write buffers to flush data back and NOP itself will
be discarded by cpu internals so I suppose this form should be better. Though
I could miss something, and OTOH it's not a big deal. But still curious :)

-- Cyrill


\
 
 \ /
  Last update: 2009-09-30 18:17    [from the cache]
©2003-2011 Jasper Spaans