[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] Bit-field packing order changed between avrgcc implem
From: |
Georg-Johann Lay |
Subject: |
Re: [avr-gcc-list] Bit-field packing order changed between avrgcc implementations |
Date: |
Sun, 02 Dec 2012 19:09:58 +0100 |
User-agent: |
Thunderbird 2.0.0.24 (Windows/20100228) |
Juergen Harms schrieb:
Some weeks ago I finally replaced an outdated tarball-installed
version of avrgcc by an rpm installed recent version (avrgcc-4.7.2).
What AVR Libc does it use?
Surprisingly, this replacement brought a change of the bit-field
packing order (my application is a distributed system with AT90CAN
Would you be more specific, e.g. provide a test case that shows this?
With the following C code
struct
{
unsigned b0 :1;
unsigned b1 :1;
unsigned b2 :1;
unsigned b3 :1;
unsigned b4 :1;
unsigned b5 :1;
unsigned b6 :1;
unsigned b7 :1;
} b;
void f1 (void)
{
b.b7 = 1;
}
the compilation result in foo.s is
f1:
lds r24,b
ori r24,lo8(1<<7)
sts b,r24
ret
if compiled with 4.7.2 as
$ avr-gcc -c foo.c -Os -mmcu=atmega88 -save-temps
which shows that .b7 ob struct b is accessed as bit 7. Same with 4.8.0.
With 4.6, 4.5, 4.3 and 3.4, for example, the code is the same but just
printed in a slightly different way:
f1:
lds r24,b
ori r24,lo8(-128)
sts b,r24
Moreover, the generated code is the same if struct b is packed.
nodes; the limited length of CAN messages forces me to use some
packed structures in the communication between nodes). With some
nodes having been compiled before the change, some after, the
consequences are evident.
Where is the evidence? Please show a test case. You can work out a
minimal test case that can be compiled by others, i.e. does not refer to
headers. The test needs not to link like in my example above.
Or you can compile you code with -save-temps and attach the precompiled
C source *.i. This also can be compiler by others.
Moreover, it is helpful to see what the compiler prints if -v is added
while your code is compiled (shows host OS, subcommands, options,
version, etc.)
My internode protocol is carefully designed to allow maximum
independence of node software evolution - but I now realise that the
bit-field packing order is an implicit part of this protocol. The
standards are clear that this is implementation and platform
dependant. I nevertheless want to continue using the ease of
Even thought it is implementation defined, the implementation is not
supposed to be changed arbitrarily or without notifying the users in the
release notes.
compiler-supported packing/unpacking - I am ready to bet on changes
occuring very unfrequently and live with this risk, but with added
control.
Because the layout has not be changed in the compiler, and by test case
examples shows this, your problem is somewhere else.
Question: can somebody suggest some way to tell - say when running
make - what packing order has been used and to detect if a change has
happened? Otherwise I need to implement a run-time test that strikes
at node initialisation (for various reasons way beyond second-best).
When you port your CAN stuff to a new platform and need to factor out
endianess, you can compile and run a small test.
Or you can factor out the compiler / target platform. For avr-gcc a
test could be
#if defined __GNUC__ && defined __AVR__
/* Code for avr-gcc */
#else
/* Code for other compilers than avr-gcc */
# endif
Notice that there are fake-GCC compilers like LLVM that define __GNUC__
even though LLVM is not GCC.
Johann