Would float point format be affected by big-endian and little endian?

Question

I know the integer format would be different between big-endian machine and little-endian machine, is it the same for float point format (IEEE 754)?

score 17 · Accepted Answer · edited Apr 18 '22 at 16:55

17

The IEEE754 specification for floating point numbers simply doesn't cover the endianness problem. Floating point numbers therefore may use different representations on different machines and, in theory, it's even possible that for two processors integer endianness is the same and floating point is different or vice-versa.

See this wikipedia article for more information.

edited Apr 18 '22 at 16:55

Artemis

2,553
7
21
36

answered Mar 09 '11 at 07:36

6502

112,025
15
165
265

score 5 · Answer 2 · answered Mar 09 '11 at 07:47

5

If you have a Linux box, you'll probably have /usr/include/ieee754.h... (note the #ifs)

...
union ieee754_float
  {
    float f;

    /* This is the IEEE 754 single-precision format.  */
    struct
      {
#if     __BYTE_ORDER == __BIG_ENDIAN
        unsigned int negative:1;
        unsigned int exponent:8;
        unsigned int mantissa:23;
#endif                          /* Big endian.  */
#if     __BYTE_ORDER == __LITTLE_ENDIAN
        unsigned int mantissa:23;
        unsigned int exponent:8;
        unsigned int negative:1;
#endif                          /* Little endian.  */
      } ieee;
  ...

answered Mar 09 '11 at 07:47

Tony Delroy

102,968
15
177
252

5

The bit order, endianess and alignment of bit fields aren't specified by the standard, so that compiler switch really doesn't do anything useful. With this code you are merely involving a third system-specific factor on top of endianess and floating point implementation, namely the compiler-specific implementation of bit fields. In addition, the compiler may add any number of padding bytes to the bit field, and to the union as well. – Lundin Mar 09 '11 at 07:56
@Lundin: quite right, it's all just too hard... that's why Linux doesn't work and isn't portable. Oh well, nice try Linus ;-). – Tony Delroy Mar 09 '11 at 08:08
1

@Tony I wanted to point out that some Linux-/GCC-specific bit field is irrelevant to a general C programming discussion about floating point format. As a sidenote, Linux is portable merely because the ports use hardware and C compilers that are suitable for Linux code, and not the other way around as would be the norm for any truly portable software. – Lundin Mar 09 '11 at 08:39
2

@Lundin: the discussion is about whether endianness affects the memory layout of real numbers... how is it irrelevant to show an example of a header that's been written to explicitly change the field ordering based on the endianness? It's not a question about the universality of the example, the point is that *any* such header that works on at least one big- and one little-endian system proves the formats are endian-sensitive.... – Tony Delroy Mar 09 '11 at 08:50
@Tony See my first comment. Because of the poor support by the C standard, there is no guarantee that the bit field will place the bits according to any given endianess. Thus there is a 50% chance that the example is wrong and will not work for any given system. I have posted some pseudo-code for a portable version of the same as an answer below. – Lundin Mar 09 '11 at 13:01
1

@Lundin: I fully accept that it's not guaranteed to work... that's not the point. It's simply confirmation of a need. Anyway, this isn't doing either of us any good apparently, so I'll let readers nuts over it if they choose.... – Tony Delroy Mar 09 '11 at 13:21

score 1 · Answer 3 · answered Mar 09 '11 at 07:38

1

Endianness issues arise as soon as you consider something as made up of smaller units. The way the smaller units are arranged may change.

Then if you care about variations in FP format, you must be aware that IEEE 754 doesn't describe a FP representation (even if it one diagram suggest one), and there is at least one more variation than the one related to endianness: the bit denoting signaling subnormals is interpreted differently in different implementation.

answered Mar 09 '11 at 07:38

AProgrammer

51,233
8
91
143

Re “you must be aware that IEEE 754 doesn't describe a FP representation”: It defines maps to bit strings, so that aspect, excluding representation of whether at NaN is signaling, is defined, leaving undefined the map from the bit string to storage order. – Eric Postpischil Apr 18 '22 at 17:01

Would float point format be affected by big-endian and little endian?

3 Answers3

Linked