Re: Layout of Structs (J. A. Chandross)
2 Jun 89 00:37:25 GMT

          From comp.compilers

Related articles
Layout of Structs (1989-05-28)
Re: Layout of Structs (1989-05-31)
Re: Layout of Structs (1989-06-02)
Re: Layout of Structs aglew@mcdurb.Urbana.Gould.COM (1989-06-04)
| List of all articles for this month |

From: (J. A. Chandross)
Newsgroups: comp.compilers
Date: 2 Jun 89 00:37:25 GMT
References: <> <>
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.
> 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
UUCP: rutgers!!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]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.