On 8/5/05, Glynn Clements <[EMAIL PROTECTED]> wrote:
>
> Steve Graegert wrote:
>
> > > Thanks for your prompt response and the valuable information. But I
> > > tried following on Linux 32-bit gcc 2.96
> > > struct temp {
> > > long long i;
> > > char c;
> > > } and sizeof(struct temp) gave 12 not 16.
> >
> > Hmm, I have no access to a 32-bit machine right now, but I am running
> > GCC 3.4.2 on SPARC and sizeof(temp) gives 16 as expected.
>
> long long is likely to be 8-byte aligned on 64-bit systems and 4-byte
> aligned on 32-bit systems.
Agree. Interestingly, Microsofts VCC (was quite curious, so I did a
quick test) aligns long long on an 8-byte boundary resulting in a size
of 16 for the structure given above. (Yes it's a 32-bit machine.)
Don't know the reason for that, since the ABI for i386 does not
mention this case explicitly.
> > One thing a could think of is that on 32-bit machines it makes no
> > sense to pad to 16 bytes since the natural word size (size of internal
> > registers) is 4 bytes resulting in an unnecessary read operation to
> > fetch the rest of the structure that is useless anyway.
>
> Aligment is determined by the granularity of RAM access. E.g. 32-bit
> systems tend to have RAM organised as 32-bit words; reading a 32-bit
> value which issn't aligned requires reading two adjacent words,
> shifting and OR-ing them together to obtain the desired value.
Yes, sure, but why would Microsoft's C compiler generate code that
results in a fully despensable read operation for the padded word? (I
know this is a Linux programming list, but the question seems related
to the overall topic of data alignment in memory.)
Regards
\Steve
--
Steve Graegert <[EMAIL PROTECTED]>
Software Consultancy {C/C++ && Java && .NET}
Mobile: +49 (176) 21248869
Office: +49 (9131) 7126409
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming"
in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
