Structure layout in big/little endian modes

David Brown david@westcontrol.com
Thu Nov 24 12:31:00 GMT 2011


On 23/11/2011 19:33, Владимир Андреев wrote:
> Hello all!
>
> I have some lack of understanding how to write endianness independent
> definition of structure, which contains bit fields.
>
> For example, field, containing endpoint address in endpoint descriptor
> of USB device, can be defined as follow:
>
> struct EndpointAddress
> {
>      UnsignedByte EndpointNumber: 4;
>      UnsignedByte: 3;
>      UnsignedByte TransferDirection: 1;
> };
>
> All USB descriptors have little endian byte order (and filling
> starting from least significant bit). If I would run some code which
> uses such definition on big endian CPU, I will get incorrect result.
>
> Can I tell GCC to use for layout big/little endian mode without manual
> changing structure layout for target CPU?
>

Unfortunately, no.

It would be /really/ nice if there were a gcc attribute that could 
specify that.  Ideally you'd have something like 
"__attribute__((bitorder(lsbfirst)))", with other options such as 
"msbfirst", and "native".  I don't know whether that would involve major 
effort, or whether it could be handled as a simple front-end 
manipulation (basically treating the definition as though you'd included 
all implicit padding bits, and then reversed the order).

Note that you can't call this "little-endian bit ordering" and 
"big-endian bit ordering" - the bit ordering is independent of the 
endianness.

One issue to consider, however, is bitfields that are greater than one 
byte - do they change endianness?  There are a number of options to 
consider.

A related issue is endianness of data - and I think that would be even 
more useful as an attribute, but would involve many more changes.  I 
have seen such an idea on other compilers, so it certainly can be done.


I couldn't see any enhancement requests for something like this in the 
bugzilla list, but I'm sure it is something that could be useful to many 
people (especially for embedded programming).  Perhaps it is worth adding?



More information about the Gcc-help mailing list