Re: [PATCH] EHCI driver - USB 2.0 support - alignment...

[Aleš Nesrsta]

Hi Vladimir,
see below...

> > Currently I have only note to discussed "packed" attribute "problem":
> > ...
> > 2. AFAIK (but maybe it is not true, maybe it was never true...?)
> > compilers are using default alignment of variables usually according to
> > native length of CPU "word". So, as we have 64-bit machines now, it
> > could be only question of time when compilers will use 64 bits alignment
> > as default.
> Reading and writing into a byte aligned on word doesn't bring any
> advantage and wastes memory and decreases portability so no compiler
> will ever do it.
> The whole reason to align is because of performance advantages and
> instruction availability.

Aah, it looks like we are both speaking about different things !
I am talking about alignment of structure MEMBERS.
You are probably talking about alignment of WHOLE STRUCTURE.

First to alignment of whole structure:
Structure(s), we are talking about, are special structures related to HW 
which must be in any case aligned to 32 BYTES.
This is solved by grub_memalign allocation in driver code. I.e., structure 
will never 1 BYTE or 1 WORD aligned, so there should not be any performance 
problem.

Now to alignment of members in structure:
In these special HW related structures are DWORD variables which must be 
placed in memory immediately one after another without any space between 
them.
I.e., offsets of structure members in structure should look like that:
0x00000000    variable1
0x00000004    variable2
0x00000008    variable3
0x0000000c    variable4
I am afraid new compilers in future can use default alignment 64 bits, so 
offsets of structure members in structure can, without any attribute, look 
like that:
0x00000000    variable1
0x00000008    variable2
0x00000010    variable3
0x00000018    variable4
To prevent this wrong situation, I am using "packed" attribute for 
structure - it will prevent any change of structure members alignment in 
future. Independent of default compiler alignment, the variables will be 
placed in memory immediately one after another. As all variables are of 
DWORD type and whole structure (begin of structure) is always aligned to 32 
bytes (i.e. to multiple of DWORD), there also should not be any problem with 
performance.

Even if it looks maybe little bit confusing and surprising, using of 
"packed" attribute for whole structure does mean it is applied for any 
member of structure (and not for whole structure) alignment - according e.g. 
this
( http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html ):
"...
packed
This attribute, attached to struct or union type definition, specifies that 
each member (other than zero-width bitfields) of the structure or union is 
placed to minimize the memory required. When attached to an enum definition, 
it indicates that the smallest integral type should be used.
Specifying this attribute for struct and union types is equivalent to 
specifying the packed attribute on each of the structure or union members. 
Specifying the -fshort-enums flag on the line is equivalent to specifying 
the packed attribute on all enum definitions.

..."

Best regards
Ales

> --
> Regards
> Vladimir 'φ-coder/phcoder' Serbinenko

Best regards
Ales