Re: [avr-gcc-list] Bit-field packing order changed between avrgcc implementations

[Juergen Harms]

Thank you for the extensive reply.

Versions:

The newly installed glibc and avr-gcc are 1.7.1 and 4.7.2 respectively, 
the old tarball versions were 1.6.1 and 4.2.2.

Evidence:

My evidence is clear, the data sent from the node compiled with the old 
compiler is received correctly (messages are only 8 bytes long, easy to 
dump) with the exception that the order of fields is inversed wrt to 
what is generated when I compile the sending node with the new version 
of the compiler - all is consistent. (For now, I cannot go back to the 
old compiler and double check by recompiling with it.)

Further evidence is (a) that once the sending node is re-compiled with 
the new compiler, the received data has the fields in the "correct" 
order, and (b) that the communication between nodes worked perfectly 
until I recompiled (only) the receiving node with the up-to-date compiler.

Would be interesting to re-install the old compiler and compare, as you 
suggest, the listing of the code it generates with the new code, but I 
dont have the time at present.

Solution:

My question was not on potential shakyness of my facts, but on a 
strategy how to deal with these facts.

Your mention of endianness reminded me of what I had learned about IP 
and made me consider a close-to-perfect solution, splitting the question 
in two:
(1) within each node, use whatever packing order the compiler deems OK, 
and access fields with all the comfort offered by C;
(2) before sending, and after receiving, program the mapping between the 
bit-fields locally used and the byte array that is sent/received: 
explicitely control the packing order (shifting, masking) that is used 
on the bus. In fact, that is very much how IP deals with endianness, 
mapping from and to network byte order - I will now have my own "bus 
bit-field order". (-
This is easy to implement (one single send/receive procedure in each 
node - the frequency of data transmission is low and the overhead can be 
neglected).

I learned a lesson: this an issue to be aware of when such a network is 
designed.

And, sorry, this has shifted from a gcc question to something that is 
better discussed on the AVR chat list.

Juergen