Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!tut.cis.ohio-state.edu!ukma!xanth!mcnc!decvax!ima!compilers-sender
From: jac@paul.rutgers.edu (J. A. Chandross)
Newsgroups: comp.compilers
Subject: Re: Layout of Structs
Message-ID: <4019@ima.ima.isc.com>
Date: 2 Jun 89 00:37:25 GMT
References: <3979@ima.ima.isc.com> <4002@ima.ima.isc.com>
Sender: compilers-sender@ima.ima.isc.com
Reply-To: jac@paul.rutgers.edu (J. A. Chandross)
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 51
Approved: compilers@ima.UUCP

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