Re: [lwip-users] Struct packing/alignment problems

[Timmy Brolin]

K.J. Mansley wrote:

> On Tue, 2004-05-04 at 18:02, Timmy Brolin wrote:
>  
>
> > Jani Monoses wrote:
> >    
> >
> > > without the PACK directives all those u16s would be put at 4 byte
> > > boundaries, not what we want.
> > >
> > >      
> > Why would they be put on 4 byte boundaries? The natural boundary of u16s 
> > is 2 bytes, not 4 bytes. Putting a u16 on a 4 byte boundary changes nothing.
> >    
>
> Try this:
>
> http://www.linuxdevices.com/eljonline/issue09/5783l3.html
>
> with the associated explanation (scroll down to "listing 3")
> http://www.linuxdevices.com/cgi-bin/printerfriendly.cgi?id=AT5340618290
>
> Compilers can, and will, insert gaps between structure elements in order
> to make accessing those fields more efficient.  This is particularly
> true on RISC processors such as ARMs (I think) where accessing something
> on a 32bit boundary can be done more efficiently than an 8bit boundary.
>
> That's what the __attribute__((packed)) directive is for: if it wasn't
> necessary, why is it so prevalent?  Have a grep through the linux kernel
> headers for more examples.
>
> Kieran
The reason the compiler inserted padding in the example on 
linuxdevices.com is because the struct fields were unaligned!
Assuming char is 8bit, short is 16 and int is 32, field b is unaligned. 
The complier inserts one byte padding between field a and b to remedy this.
And there is no performance difference in accessing a 16bit variable 
from a 2byte boundary or a 4byte boundary. Obviously you have not 
programmed much assembly :)
The struct from the linuxdevices.com example:

struct foo {
      char     a;
      short    b;
      int      c;
};

/Timmy