henry@utzoo.uucp (Henry Spencer) (08/22/88)
In article <2970@tekcrl.CRL.TEK.COM> danw@tekchips.CRL.TEK.COM (Daniel E. Wilson;1432;58-790;;) writes: > It would seem that a well written compiler would already choose the >best alignments of members in a structure. Unfortunately, the definition of "best" is somewhat context-dependent. All a compiler can do is try to pick a reasonable compromise (i.e. the one that best fits the prejudices of its implementors). > Also remember that some >types of hardware can't address a word on a byte boundry (PDP-11) and >so this option would end up not being implemented. This interferes with *pointers* to such variables, but the variables themselves are not a problem -- they just take longer to access. This can be a worthwhile tradeoff in some circumstances. In particular, it would be very nice to be able to define a precise storage layout for things like network packets -- it wouldn't be entirely portable, but having the compiler do the details of digging the data out would be better than making the programmer do it. >A good 80x86 compiler >would probably not pad a structure because the hardware doesn't care how >an int is aligned. Ah, but it does! Unaligned accesses *work*, but they are much slower. A good 80x86 compiler should probably pad out to 16-bit alignment at least, and perhaps 32. -- Intel CPUs are not defective, | Henry Spencer at U of Toronto Zoology they just act that way. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu