Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!jarthur!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.unix.programmer Subject: Re: why do structs have different sizes across machines? Message-ID: <6813@auspex.auspex.com> Date: 25 Mar 91 03:52:51 GMT References: <77336@bu.edu.bu.edu> <1991Mar20.170456.15026@colorado.edu> Distribution: usa Organization: Auspex Systems, Santa Clara Lines: 42 > The difference is that the Sun is more efficient with it's data >storage. The encore machine has a 4 byte word size, while the sun has >a smaller granularity. Not quite. Suns - with the possible exception of the Sun-1s and Sun-2s, depending on how you think of the 68000 and 68010 - *also* have 4-byte word sizes. However, the 68K Suns use a compiler derived from the MIT port of PCC to the 68000; that compiler didn't bother aligning 4-byte quantities on 4-byte boundaries. On the 68000, and on the 68010 used in the Sun-2s, there was no performance benefit to doing so; the 68000 and 68010 fetched 4-byte quantities 2 bytes at a time. On most if not all fully-32-bit machines, there *is* a performance benefit to aligning 4-byte quantities on 4-byte boundaries. On some machines, unaligned 4-byte quantities can be handled directly by the hardware, but at a cost in speed; on others, the hardware can't handle it, and either the software doesn't compensate (so your program blows up) or the software does compensate, again at a cost in speed. The Encore has, if I remember correctly, a National Semiconductor 32K-family chip in it; that family started out (at least in the chips used in UNIX systems) as a fully 32-bit chip, and either there was a performance win for 4-byte alignment of 4-byte quantities, or the people who did compilers for it were planning ahead for machines where there was a performance win. I don't know if the MIT folk chose not to align 4-byte quantities on 4-byte boundaries because it would, in some cases, reduce the storage requirements of data structures, or just because they weren't thinking ahead. Had they done so, there *would* have been a performance win on the 68020 and later 68K-family chips. Sun's 68K compiler continues to align 4-byte structure members only on 2-byte boundaries, for data structure binary compatibility between Sun-2s and Sun-3s and, at this point, for data structure compatibility between different software versions on Sun-3s. (I think many other 68K C compilers do so for similar historical reasons.) The Sun compiler does, however, align 4-byte automatics on 4-byte boundaries, and the compiler and linker may also do so with 4-byte static quantities. (The compilers on SPARC-based and 386-based Suns do align 4-byte quantities, including structure members, on 4-byte boundaries.)