Dear Luigi Mantellini,
In message <b73e93990901281504k3940b356nbff298e137c0e...@mail.gmail.com> you
wrote:
>
> > We (i. e. all of us except you) do not have a problem.
>
> my question is: how can you be sure on this? I haven't used strange
Because I read the documentation?
> compilers or strange CFLAGS.. I just do "make" on a supported target
> (qemu_mips).
> I haven't any problem to correct my local source tree. I ask myself
> why gcc offers a packed atribute, ms-vc offers pragma packed, ...
There are cases where it makes a difference. Assume someting like
this:
struct foo { /* offset normal packed */
long l; /* 0 0 */
char c; /* 4 4 */
long x; /* 8 5 */
};
Here the alignment requirements are 4 byte for "l", 1 byte for "c",
and 4 byte for "x". The compiler will align all variables on 4 byte
addresses normaly, i. e. the offsets are 0, 4 and 8. With ""packed",
the natural alignment of "x" on a 4 byte border will be ignored, and
instead it will be "packed" immediately following the storage for the
"c" variable, i. e. resulting in offset 5. This may easily cause
problems on some architectures, but that's what you get when you ask
for it.
Now study the data structures used for netwrking - they are all
carefully crafted that the natural aligment "just fits", i. e. there
are no gaps between variables if they are aligned naturally.
Your compiler must be doing really stupid things here.
> the behavior is clear: in my environment, the default choice is to
> align fields on 32bit for speed reasons... and I like this by default
> for my applications.
What makes you think it would be faster if a 16 bit ("short") data
type was no aligned on a 32 bit border, but only on a 16 bit one?
I am not aware of a system where that would make any speed difference.
Same for 8 bit (char) data types - for these, alignment at 32 bit
offsets makes zero sense to me.
> I can ignore the problem using options like -Os (I will try tomorrow)
> or -fpack-struct or other global mechanisms or, pay attention on
> structures definitions to be sure that the structure size is compiler
> and cflags independent.
The currentcode has no such problems, standard conforming compilers
assumed.
> I see. I would like to understand why this structure is
> optimization-prof. I will study tomorrow...
Please read the docs.
> iso C doensn't require packing by default of the structures. To assume
We are not talking about "packing" here. We are just talking about
alignment and insertion of gaps to ensure natural alignment of data
types. This is a well documented area.
> that a structure is packed by default is not a good assumption. All
This is NOT packing! Please do not mix unrelated terms.
> which documentation should I read? iso c documents? gcc manuals? I
ISO C or GCC, whatever is more handy.
> Anyway, I don't want to talk about philosophy. I just noticed an
> anomaly and I wanted to share with the ML.
Sorry, but there is no anomaly. This is normal, (mostly) standard
conforming C code.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"When anyone says `theoretically,' they really mean `not really.'"
- David Parnas
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
