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.
> 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.
Some architectures (e.g. x86) can do unaligned access at the CPU
level, in which case unaligned access is merely a performance hit.
Other architectures (e.g. most RISC CPUs) can't; if you try to
read/write an unaligned address, the CPU generates an exception. In
this case, if you want to perform an unaligned access, you have to do
it in software.
--
Glynn Clements <[EMAIL PROTECTED]>
-
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
