jac@paul.rutgers.edu (J. A. Chandross) (05/28/89)
stein@pixelpump.osc.edu (Rick 'Transputer' Stein) > I have some questions about how a compiler constructs a symbol table. > [questions on structure layout deleted] Our erstwhile moderator replies: > C compilers have the right to lay out structures any way they see fit, > unless the ANSI committee changed the rules. I quote, without permission, from The Bible, page 196, First Edition: "Within a structure, the objects declared have addresses which increase as their declarations are read lef-to-right. Each non-field member of a structure begins on an addressing boundry appropriate to its type; therefore, there may be unnamed holes in a structure. Field members are packed into machine integers; they do not straddle words. A field which does not fit into the space remaining in a word is put into the next word....." It is a Good Thing [tm] that structures are laid out in this way. As a hardware type, I often need to write device drivers. Being able to impose a structure onto a hardware memory map is a very useful thing, indeed. Jonathan A. Chandross Internet: jac@paul.rutgers.edu UUCP: rutgers!paul.rutgers.edu!jac [I hope I'm not the erstwhile moderator yet, but stand corrected. -John] -- Send compilers articles to compilers@ima.isc.com or, perhaps, Levine@YALE.EDU Plausible paths are { decvax | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request
henry@zoo.toronto.edu (05/31/89)
>It is a Good Thing [tm] that structures are laid out in this way. As >a hardware type, I often need to write device drivers. Being able to >impose a structure onto a hardware memory map is a very useful thing, >indeed. Beware, however, that it is still possible for C structures to have unnamed holes in them more or less wherever the compiler pleases. C does *not* give you complete control of storage layout, and never has, although in many compilers you can do pretty much what you want at the price of having your code depend on assumptions about the compiler. Case in point: on a 68020, are longs 16-bit aligned or 32-bit aligned? Compilers differ. Henry Spencer at U of Toronto Zoology uunet!attcan!utzoo!henry henry@zoo.toronto.edu -- Send compilers articles to compilers@ima.isc.com or, perhaps, Levine@YALE.EDU Plausible paths are { decvax | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request
jac@paul.rutgers.edu (J. A. Chandross) (06/02/89)
jac> It is a Good Thing [tm] that structures are laid out in this way. As jac> a hardware type, I often need to write device drivers. Being able to jac> impose a structure onto a hardware memory map is a very useful thing, jac> indeed. henry@zoo.toronto.edu > Beware, however, that it is still possible for C structures to have > unnamed holes in them more or less wherever the compiler pleases. C > does *not* give you complete control of storage layout, and never has, > although in many compilers you can do pretty much what you want at the > price of having your code depend on assumptions about the compiler. > Case in point: on a 68020, are longs 16-bit aligned or 32-bit aligned? > Compilers differ. The 68020 has a 32 bit data path. One would assume (hope?) that the compiler would be smart enough to lay out the long on a 32 bit boundry to prevent the additional bus cycle. The Bible is unclear on this point; it states "Each non-field member of a structure begins on an addressing boundry appropriate to its type; therefore there may be unnamed holes in a structure." (Page 196, first edition.) This makes sense if one did: struct foo { char xx; int yy; }; One would expect yy to be long aligned, and thereby induce 3 invisible chars into the structure. I've never had a problem casting a hardware address into a struct declared in the appropriate way. Naturally, I use 8-bit-byte hardware so I haven't run into too much weirdness. This is not to say that problems don't exist; just that implementors do the expected thing. As Henry says, this is not a good thing to rely on. Does ANSI C address the issue of alignment? Jonathan A. Chandross Internet: jac@paul.rutgers.edu UUCP: rutgers!paul.rutgers.edu!jac [Henry's point is that on 680x0 implementations with 16-bit buses, there is no performance advantage to 32 rather than 16 bit alignment, and for a long time those were the bulk of 680x0 systems, hence many compilers did and still do only 16-bit align. I am unaware of any portable way to be sure that structures don't have holes. -John] -- Send compilers articles to compilers@ima.isc.com or, perhaps, Levine@YALE.EDU Plausible paths are { decvax | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request
aglew@mcdurb.Urbana.Gould.COM (06/05/89)
>> Case in point: on a 68020, are longs 16-bit aligned or 32-bit aligned? >> Compilers differ. > >The 68020 has a 32 bit data path. One would assume (hope?) that the compiler >would be smart enough to lay out the long on a 32 bit boundry to prevent >the additional bus cycle. On Motorola SYSTEM V/68 the compiler normally lays out scalar 32 bit quantities (ints, etc.) on 32 bit boundaries. This behaviour is controlled by an environment varaible DBLALIGN, which is normally on. (DBL because 32 bits is a "double-word" in 68K speak). However, 32 bit fields within structures are normally laid out on 16 bit boundaries, for compatibility with pre-68020 data structures - all these data files that have 32 bit quanties at 16 bit alignments. This behaviour is controlled by a variable STALIGN, which is normally off. Setting STALIGN gets you a performance boost for your own code, but may not be compatible with system headers, etc. [From aglew@mcdurb.Urbana.Gould.COM] -- Send compilers articles to compilers@ima.isc.com or, perhaps, Levine@YALE.EDU Plausible paths are { decvax | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request