avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel O'Connor
Subject: Re: [avr-gcc-list] Re: External EEPROM verses internal EEPROM data handling
Date: Tue, 5 May 2009 08:17:11 +0930
User-agent: KMail/1.9.10

On Mon, 4 May 2009, David Brown wrote:
> 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

According to the GCC info page it isn't a hint, although it doesn't say 
it's a cast iron guarantee either.

> 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

Explicit padding is different to packed, it uses up more space to 
maintain the native alignment. Explicit padding still doesn't guarantee 
some new architecure you port to will do what you expect (hence you 
need -Wpadded).

> 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?

Well... It's OK because GCC is ubiquitous and free and for micros 
writing compiler neutral code is effectively impossible anyway.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]