Re: modify gcc to handle byteorder issue automatically

[Jim Wilson <wilson at tuliptree dot org>]

This issue has come up before a number of times.  I'm not convinced that
it is a good idea.

The basic approach here would be to add an attribute or a set of 
attributes to describe endianness.  When we convert trees to RTL, if we 
notice an endianness mismatch between the data and the target, then we 
do byteswapping.

I think this is likely to be a significant amount of work.  In the 
general case, layout of bytes depends on endianness (byte order), word 
size, and word endianness (word order).  We need all of this info for 
the data we are reading in order to read it correctly.  Also, some 
targets use different word endianness for different types, arm for 
instance uses different word order for long long and double for 
historical reasons, so the byte swapping depends on the data types. 
This is just for basic types like int and float.  When you consider 
structure types, things get a lot more complicated, as we need even more 
info about structure layout to handle structures correctly.  We also 
need bit reversing to handle bit-fields.  This is all so complicated 
that it seems like trying to do this in the compiler is a bad idea.  We 
end up with something so complicated that it can't be implemented 
correctly if we try to handle the general case.  If we simplify it to 
handle only special cases, then it is likely that we will get bug 
reports because users have trouble understanding exactly which cases are 
supposed to work and which aren't.

It seems easier to let users handle this in their own applications rather
than handling it in the compiler.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com