CPP macro for Byte-order

[Richard Earnshaw]

> Richard Earnshaw <rearnsha@arm.com> writes:
> 
> | > 
> | > On the other hand, the gcc backends define BITS_BIG_ENDIAN,
> | > BYTES_BIG_ENDIAN, and WORDS_BIG_ENDIAN (you would want BYTES_BIG_ENDIAN to
> | > solve the problem of detecting NaNs and the like). 
> | 
> | It is a common mistake to confuse the INTEGER endian settings with the 
> | requirements for floating point numbers.  The two need not be related, and 
> | on many architectures aren't.
> | 
> | Please keep these separate.
> 
> I understand the conceptual difference with the two.  But _concretely_
> are there supported plateforms where they do actually differ?  What
> are your suggestions?

As has been pointed out already.  Yes it can be different on the ARM.  In 
fact, it is even more complex than that.

In the early days of the ARM architecture a floating point instruction set 
was defined, and eventually a co-processor for the core was added that 
implemented the core parts of that instruction set.  This instruction set 
is known as the FPA instructions and for doubles the exponent is held in 
the lowest addressed word (commonly known as the "Motorola ordering", 
though the chip is little endian).  However, the bit-ordering within the 
words is the normal little-endian.

To confuse matters further, ARM has recently introduced a new floating 
point instruction set (with more registers, and better implementation 
characteristics that lead to much better performance than was possible 
with the old instruction set).  For some reason the designers have changed 
the behaviour so that this instruction set follows the "natural" word 
ordering for floating point numbers (ie the exponent is in the same word 
as one would find on most other architectures, given the endianness of the 
system).

As to how to handle this, I think two new defines are needed: 
FLOAT_BITS_BIG_ENDIAN and FLOAT_WORDS_BIG_ENDIAN.  It isn't normally 
necessary to worry about the order of bytes in floating point numbers.  
You could also take a look at the code in gcc/real.[ch] and 
libiberty/floatformat.c.  Both of these files can handle a wide range of 
systems with peculiar behaviours.

R.