Related articles |
---|
Layout of Structs jac@paul.rutgers.edu (1989-05-28) |
Re: Layout of Structs henry@zoo.toronto.edu (1989-05-31) |
Re: Layout of Structs jac@paul.rutgers.edu (1989-06-02) |
Re: Layout of Structs aglew@mcdurb.Urbana.Gould.COM (1989-06-04) |
From: | jac@paul.rutgers.edu (J. A. Chandross) |
Newsgroups: | comp.compilers |
Date: | 2 Jun 89 00:37:25 GMT |
References: | <3979@ima.ima.isc.com> <4002@ima.ima.isc.com> |
Organization: | Rutgers Univ., New Brunswick, N.J. |
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]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.