[avr-gcc-list] Re: External EEPROM verses internal EEPROM data handling

[David Brown]

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?