[Mpi-forum] why (int)0x4c000101 ?

[Dave Goodell]

To the OP's original question, this isn't really the right venue to discuss this sort of thing.  This list is for discussing MPI standardization issues, not implementation issues for specific MPI implementations.  If you wish to discuss this sort of thing further, please do so on mpich-discuss at mcs.anl.gov or users at open-mpi.org.


On May 28, 2012, at 12:51 AM GMT+09:00, Jeff Hammond wrote:

> One will observe that information appears to be coded in those values.
> You see that the third-to-last hex-digit indicates the number of bytes
> in the type, with the exception of long double, which uses c=12 when
> the type is actually 16 bytes.  I don't know why this is, but it
> doesn't really matter since there is only one built-in type of this
> size.  Inspecting the first- and second-to-list hex-digits indicates
> that signed and unsigned types often (but not always) differ by only
> one bit.

FWIW, it's encoding the type size in the second least significant byte.  That is, the value given by ((type & 0x0000ff00) >> 8).

As for "long double", on some platforms this actually is an 80-bit "double extended" floating point type corresponding to the actual width of x86 floating point registers.  80 bits is only 10 bytes (0xa in hexadecimal), but compilers store it in a 12-byte slot in order to keep all of the values 4-byte aligned.

-Dave