Daniel O'Connor wrote:
On Mon, 4 May 2009, David Brown wrote:
Daniel O'Connor wrote:
On Mon, 4 May 2009, Bob Paddock wrote:
uint16_t voltage[24]; // adc counts of 24
channels in an array } ED; // total data = 58 bytes
Because of issues of structure packing it is better to define
structure items from
the largest to the smallest, ie. uint16_t should be first. This
is more important
on 32bit processors and up than on the 8bit AVRs.
You could just mark the struct as packed, eg..
typedef struct eventdata {
...
} __attribute__ ((packed)) ED;
Or use the -wpadded warning flag, which will let you know if any
implicit padding has been added (I prefer to explicitly add padding
if it is required).
Of course, you don't get padding on an 8-bit AVR (except for bit
fields), but it's good to write portable code when practical.
Padding is going to be unportable between architectures.. May as well
take advantage of the compiler extensions. (IMO :)
If you want to be sure that your structures are identical across
different architectures, then -wpadded is essential. The packed
attribute is only a hint, not a guarantee, so you might still get
padding on some architectures. It is also possible that packed structs
are less efficient (again, not the case for the AVR) due to misaligned
accesses - implicit or explicit padding will help. I don't mean to say
that the packed attribute should not be used - it's an alternative to
explicit padding, depending on your needs. But I like to have -wpadded
enabled in any case. I suppose that gcc-specific warnings count as
compiler extensions too - and I too think compiler extensions are there
to be used. What's the point in having the world's best compiler, if
you don't take advantage of its features?
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
