🚀 go-pugleaf

> >Yes, at least in the 4.3BSD version of the compiler, ....
> Actually, some might be aligned to 8-byte boundaries, on machines that
> like doubles on such boundaries.

By way of clarification, my "yes" was to "yes, the VAX aligns the 'union'
containing a 'short' and a 'char' on a 2-byte, not a 4-byte, boundary."
Structures need not always be aligned on the most restrictive boundary
required by the architecture or imposed by the compiler on scalar data, but
it must align a structure so that all its members are aligned, so that it is
aligned on the most restrictive boundary of all its members.

PCC starts out aligning structures on a "minimum alignment required by all
structures" boundary, and then marches through the member list strengthening
the alignment requirement as necessary.  I presume the reason that the
"minimum alignment required by all structures" is not hardcoded to "one
byte" is that there might be machines that prefer, or require, structures
aligned more stringently.  E.g., a machine might have
"register+displacement" addressing where the displacement is in units of
8-byte quadwords, or the implementor might have decided to speed up
structure assignment by using some trick that can copy data faster if it's
aligned on a quadword boundary.  It was *not* intended for machines with
more stringent restrictions on scalar alignment, as the aforementioned march
handles that problem already.

> Note that for speed, it is usually best to align data items on the most
> restrictive boundaries, even if a specific machine implementation doesn't
> really require it.  Lots of machines let words be on arbitrary boundaries,
> but you pay for it in speed, if not now, then later, as CPUs come
> to have wider data paths.

Yes, the VAX PCC aligns "int"s and "long"s on 4-byte boundaries, even though
the machine can fetch longwords off such a boundary; there is, I'd bet, a
performance penalty for such a fetch.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)