Steve Graegert wrote: > > 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.
> > 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.) Maybe for binary compatibility with 64-bit systems? There used to be a version of NT for Alpha. Also, compared to gcc, MSVC was quite late at adopting C99 features, so x86/64 may have been taken into account when "long long" was added. Microsoft tends to pay as much attention to the ABI as the API, whereas Unix systems tend to be far less concerned about the ABI. I suspect that this is partly because Windows is far less cross-platform than Unix, so maintaining a common ABI is a lot less work, and partly because of the preference for binary formats on Windows compared to textual formats on Unix. -- 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
