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