This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: modify gcc to handle byteorder issue automatically

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,

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]