On 10/13/2011 02:36 PM, John McCall wrote: > >> 1) >> Actually, the generic interface breaks if the atomic type is not the same >> size as the base type. >> >> void __atomic_exchange (size_t size, void *ptr, void *expected, void >> *desired,...); >> >> in reality, from GCC's point of view, it currently doesn't distinguish an >> atomic type from the base type, it just sees: >> void __atomic_exchange(T *ptr, T *expected, T *desired, …) >> >> if 'expected' and 'desired' were different sizes than 'ptr', we'd need >> another size parameter and have to deal with padding code, and I'm not >> prepared to go down that road just yet. > I'm not sure why you're implementing this intrinsic without having _Atomic > types yet. The intrinsic should really be taking an _Atomic(T)* and two Ts. > That also conveniently removes the need for a size parameter. > > Obviously, it's your call, but…
Well, the size parameter only exists for the external library where there is one entry point and it needs to be able to operate on all different sizes of objects. Within the the compiler we simply see the types and know what the sizes are... in fact, when calling the external routine, the size has to be added by looking at the type. GCC's existing __sync atomic primitives simply operate on a hunk of memory, and these primitives map down to registers. All lock free instruction sequences are going to require equal sized register to operate on. The new __atomic primitives build on top of those, and add the memory model. The next release will probably see the old __sync routines implemented in terms of the new __atomic routines rather than the way it is now. When there is a well defined _Atomic modifier which actually changes the size, its simple enough to layer this on top of whats there and detect the first parameter is a different size, and DTRT, whatever that turns out to be. There is no point in holding up this release or existing users when this underlying work is required anyway. I expect that when _Atomic(T) and T are different sizes, its the caller thats going to have to do any padding to make them match, not the atomic routine itself... well, I suppose even that may be up for debate at this point. Andrew _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
