hyc@math.lsa.umich.edu (Howard Chu) (10/30/90)
Just a little FYI: I discovered today (sigh) that the C compiler on
Sun Sparcstations always tries to align structure elements on longword
boundaries. Thus my "unix-compatible" (hah) TOS disassembler fails to
work, because there are extra pad bytes inserted to my structure declarations.
(e.g.,
struct GEMHEADER {
short GEM_MAGIC;
long GEM_SEGS[GEM_NSEGS];
long reserved;
long unused;
short GEM_FLAG;
}
This defines the start of a TOS executable file. The structure, as defined,
is 28 bytes on an ST, and 32 bytes on a Sparc. Bleah.)
If you're trying to write portable code, don't assume you can read or write
structures in a single operation. If you're already using buffered I/O then
it's really not much more overhead to read X bytes at a time and fill structures
in explicitly, one element at a time...
Of course, if you're only writing for 680x0 architectures, this won't ever
be a problem (?) since data is aligned on word boundaries (2 bytes, 16 bits)
and not longword boundaries (4 bytes, 32 bits). [but watch out for those
single-byte declarations! }-) ]
--
-- Howard Chu @ University of Michigan
Mac// - adv., q.v. MacToo, e.g. McHave a McHappy McDay!
McThanks, McYou MacToo!rehrauer@apollo.HP.COM (Steve Rehrauer) (10/31/90)
In article <1990Oct29.235921.23294@math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu) writes: >Just a little FYI: I discovered today (sigh) that the C compiler on >Sun Sparcstations always tries to align structure elements on longword >boundaries. Thus my "unix-compatible" (hah) TOS disassembler fails to >work, because there are extra pad bytes inserted to my structure declarations. >(e.g., > struct GEMHEADER { > short GEM_MAGIC; > long GEM_SEGS[GEM_NSEGS]; > long reserved; > long unused; > short GEM_FLAG; > } >This defines the start of a TOS executable file. The structure, as defined, >is 28 bytes on an ST, and 32 bytes on a Sparc. Bleah.) [...] >Of course, if you're only writing for 680x0 architectures, this won't ever >be a problem (?) since data is aligned on word boundaries (2 bytes, 16 bits) >and not longword boundaries (4 bytes, 32 bits). [but watch out for those >single-byte declarations! }-) ] Well, not quite. I can't speak for other vendors, but Apollo C on our 68k workstations can also insert padding between structure members to long-align them. (A 32-bit fetch of a long-aligned object will run slightly faster than a fetch of an odd-word-aligned object.) On a DN4500, for example, your example struct would also be 32 bytes big. -- "I feel lightheaded, Sam. I think my | (Steve) rehrauer@apollo.hp.com brain is out of air. But it's kind of | The Apollo Systems Division of a neat feeling..." -- Freelance Police | Hewlett-Packard
rehrauer@apollo.HP.COM (Steve Rehrauer) (10/31/90)
In article <4dba8b38.20b6d@apollo.HP.COM> rehrauer@apollo.HP.COM (I) wrote: >In article <1990Oct29.235921.23294@math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu) writes: >>Of course, if you're only writing for 680x0 architectures, this won't ever >>be a problem (?) since data is aligned on word boundaries (2 bytes, 16 bits) >>and not longword boundaries (4 bytes, 32 bits). [but watch out for those >>single-byte declarations! }-) ] > >Well, not quite. I can't speak for other vendors, but Apollo C on our 68k >workstations can also insert padding between structure members to long-align >them. (A 32-bit fetch of a long-aligned object will run slightly faster >than a fetch of an odd-word-aligned object.) On a DN4500, for example, your >example struct would also be 32 bytes big. That'll teach me to post before the morning's caffeine takes effect. Forget what I said about Apollo C (it really will only word-align Howard's struct members). However, I don't see any reason why a compiler *mustn't* long- align struct members, can you? Aside from that it wastes space; I'm mean, in an idealogical sense. It sounds like something you shouldn't depend upon. -- "I feel lightheaded, Sam. I think my | (Steve) rehrauer@apollo.hp.com brain is out of air. But it's kind of | The Apollo Systems Division of a neat feeling..." -- Freelance Police | Hewlett-Packard
bro@eunomia.rice.edu (Douglas Monk) (11/01/90)
In article <1990Oct29.235921.23294@math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu) writes: [re: byte padding on Sparcstations] >[...] always tries to align structure elements on longword >boundaries. >[...] The structure, as defined, >is 28 bytes on an ST, and 32 bytes on a Sparc. Bleah.) I ran into the same problem years ago between Suns (1s) and Vaxen. (Plural of Vax :-) Since we weren't sure at the time what else might be called for in the future, we started reading and writing structures as the component independent low level objects (shorts, longs, and bytes), and since we also wanted to be prepared for *byte-order* variations, we used the byteorder macros used for networking portability (htonl, htons, ntohl, ntohs) so it could run on *anything*. On a Sun 2/3/4 these are null macros, since the size and byteorder of shorts and longs are the network standard. Other machine architectures (like Vaxes, '386s, etc.) provide macros to convert to and from network standard sizes and orderings. You still have to fool about a bit with ints: I always casted them to longs to be safe before converting :-). Haven't had a bit of trouble since. Moral: a little extra effort, even when it is *really* a no-op *now* may save a *ton* of trouble later. Oh, yeah, and *never* trust compilers to construct structures in any *sane* way: if byte padding can take place, is there any reason for a compiler even to maintain the same order for components as declared within a structure? Doug Monk (bro@rice.edu) Disclaimer: These views are mine, not necessarily my organization's.
ericco@ssl.berkeley.edu (Eric C. Olson) (11/01/90)
If you really want to be careful check out the XDR library. Eric -- Eric ericco@ssl.berkeley.edu