Re: Any pointer to Byte Alignment & Structure Padding?

[Steve Graegert <graegerts@gmail.com>]

On 8/5/05, Glynn Clements <glynn@gclements.plus.com> 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 <graegerts@gmail.com>
Software Consultancy {C/C++ && Java && .NET}
Mobile: +49 (176)  21248869
Office: +49 (9131) 7126409