Messages in this thread | | | Date | Thu, 23 Dec 2010 16:22:45 -0800 | From | "H. Peter Anvin" <> | Subject | Re: [cpuops cmpxchg double V1 1/4] Generic support for this_cpu_cmpxchg_double |
| |
On 12/23/2010 04:16 PM, Christoph Lameter wrote: > On Wed, 22 Dec 2010, Tejun Heo wrote: > >>> I'm a bit confused on this one. The standard cmpxchg() takes a scalar >>> and a pointer, and returns a scalar. The equivalent for the "double" >>> variety would be to return a compound object, basically: >>> >>> struct double_ulong { >>> unsigned long v[2]; >>> }; >>> >>> ... which can be returned in registers on both i386 and x86-64. > > Really? How would that work? I tried with uint128 but could not get the > compiler to do the right thing. >
There are two return registers; two machine registers can be returned in registers. [u]int128 is poorly implemented in a lot of gcc versions, since it really hasn't been exercised. However, two-word structures should work. I do not believe a two-word *array* works, though.
>>> It's a bit clumsy from a type perspective, but I'm not sure that that is >>> a bad thing. Doing too much type genericity has caused us problems in >>> the past. >> >> Yeah, the above might be better too. Is there any reason to use >> cmpxchg_double on anything smaller? > > Yes. You may want to use cmpxchg_double on 32 bit entities for backwards > compatibilities sake or any other smaller unit size. But those could also > be realized using this_cpu_cmpxchg_<double the size> by just aggregating > the amount. > > If we can indeed pass 128 bit entities (as claimed by hpa) via registers > then the logical choice would be to do > > this_cpu_cmpxchg_16(pcp, old, new) > > instead of cmpxchg_double. All parameters would have to be bit. > Then we can avoid the strange cmpxchg_double semantics and can completely > avoid introducing those.
I'm not sure it works with passing in a structure.
-hpa
| |