Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!mentor.cc.purdue.edu!j.cc.purdue.edu!pur-ee!hankd From: hankd@pur-ee.UUCP (Hank Dietz) Newsgroups: comp.arch Subject: Re: Sorting struct members for alignment (was Re: Unaligned Accesses) Summary: compiler vs. machine dependencies Keywords: alignment Message-ID: <11128@pur-ee.UUCP> Date: 28 Mar 89 14:17:33 GMT References: <37196@bbn.COM> <1989Mar16.190043.23227@utzoo.uucp> <24889@amdcad.AMD.COM> <355@bnr-fos.UUCP> <13@microsoft.UUCP> <362@bnr-fos.UUCP> <59@microsoft.UUCP> <11118@pur-ee.UUCP> <4582@pt.cs.cmu.edu> Reply-To: hankd@pur-ee.UUCP (Hank Dietz) Organization: Purdue University Engineering Computer Network Lines: 34 In article <4582@pt.cs.cmu.edu> bsy@PLAY.MACH.CS.CMU.EDU (Flexi-thumbs) writes: >In article <11118@pur-ee.UUCP> hankd@pur-ee.UUCP (Hank Dietz) writes: >>In C, it has been a very common idiom to ASSUME that the address of the first >>member of a struct IS the address of the struct. For example: [elided] > ... >The big problem that you're referring to is probably the injunction against >reordering structure members, viz., Section A8.3 of K&R 2nd Ed (pg 213). >You'll find it in the ANSI std too. So, the assumption is valid for all >architectures that do not require padding before the first element of the >struct. Does anybody know of any? I'd conjecture that no machine is that >silly. .... It isn't a machine issue... it is a compiler issue. Suppose an int is 4 units and a char is 1 unit, with alignment constraints to match. At the risk of reopening the great endian wars, given a struct like: struct s { char c; int i; } t; a compiler might legally decide to make &t be 3 units BEFORE &(t.c); effectively {pad3, char, int} versus {char, pad3, int}. This does not violate the above referenced ordering constraints, and might make sense in that the machine might be able to extract the char value from a fetched word (int) faster if the padding appears in front rather than behind. Basically, the difference would be extracting the char by a simple mask versus extracting it using a multi-bit shift (and perhaps also a mask). Why isn't this a big problem? Easy. The compiler doesn't know it will need to pad struct s until it encounters the int member, and by that time most compilers have generated the allocation offset for the char field. In short, it is easier for the compiler not to put padding in front. -hankd@ee.ecn.purdue.edu