[ofiwg] the problems with atomics

[Hefty, Sean]

libfabric defines several datatypes for atomic operations.  For the integer types, the size of the data type is included as part of the definition -- INT8/16/32/64.  For floating point types, no size is provided -- float/double/long double.  I have added sizes to float (32) and double (64).

Long double presents a wonderful challenge (i.e. mess).  On x86, a long double usually converts to an 80-bit value.  However, PPC and SPARC define something completely different (106-bits?).  IEEE defines a binary128 value, but in such a way that the 80-bit format is IEEE compliant, but PPC and SPARC are not.  And, of course, this allows a compiler to choose a long double to mean a 128-bit value.

But wait, there's more!  The amount of space allocate for a long double may be either 96 or 128 bits.  I'm not sure which alignment is more common, but I suspect 128-bit is for 64-bit platforms, and 96-bit is for 32-bit platforms.

Returning back to the problem, a datatype of 'long double' isn't particularly useful without a clear definition of the size of the type and its alignment.  The Long Double Challenge also suggests that libfabric should define multiple data types to cover the various cases.

Someone feel free to chime in here with a brilliant solution for handling this that doesn't and up with this sort of datatype explosion:

FI_LONG_DOUBLE_80BITS_ALIGNED_96,
FI_LONG_DOUBLE_80BITS_ALIGNED_128
FI_LONG_DOUBLE_96BITS_ALIGNED_96,
FI_LONG_DOUBLE_96BITS_ALIGNED_128,
FI_LONG_DOUBLE_128BITS_ALIGNED_128,
FI_LONG_DOUBLE_WEIRD_PPC_ALIGNED_128

(To be clear, the x86 80-bit format probably isn't any weirder than PPC.  The Intel architects probably just had more say in the IEEE standard.)  I'm not sure the size at the endpoints matters, versus the size in the packets and the alignment.

- Sean