From: herb AT angoss DOT com (Herb Sears)
Subject: Re: one point (Was [Re: FW: Re: wxwin port])
19 Nov 1996 13:51:36 -0800
Sender: daemon AT cygnus DOT com
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <199611191518.KAA05725.cygnus.gnu-win32@silver.research.angoss.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Original-To: dje AT cygnus DOT com (Doug Evans)
Original-Cc: garp AT opustel DOT com, gnu-win32 AT cygnus DOT com
In-Reply-To: <199611190108.RAA05782@canuck.cygnus.com> from "Doug Evans" at Nov 18, 96 05:08:48 pm
X-Mailer: ELM [version 2.4 PL25]
Original-Sender: owner-gnu-win32 AT cygnus DOT com


Hi,

I've been following this discussion for some time and would like to add
my $0.02 to the alignment issue.  The company I work for produces cross
platform (Win/DOS/Unix) software for the user market and we have run into
this problem many times.

> 
>    I've run across this problem with some other structures.  It appears that
>    GCC will automatically align the size of some variables in order to eek out
>    more performance.
> 

This is partly true.  The more important reason for alignment is that some
CPU's (mainly RISC) cannot access structure elements that are not aligned
properly.  The actual required alignment varies by CPU but is usually 8 or
4 byte (NOTE: some compilers will emit code to access unaligned elements
but this is very inefficient).

> I don't believe this assessment can be correct.
> If GCC doesn't align structures [by default] the way the native compiler does,
> then that is a bug, end of story.
> 

Not a bug, just different behavior.  With the Intel CPU, alignment is not
important in terms of structure access but is important for performance
(aligned elements are accessed in fewer clock cycles).  GCC is probably
defaulting to 8 byte (or 4 byte) alignment.  In fact, the MS developer
studio (I know...) uses 8 byte alignment by default.  The windows header
files include pshpack[1248].h and poppack.h to maintain the alignment of
internal structures.

>    A WORD, which is an unsigned short, should be 16 bits but
>    GCC will pad it out to a full 32 bits which is presumably more efficient to
>    pass.  I've noticed this in structures which have an odd number of WORD
>    variables as the BITMAPFILEHEADER structure below.  When there is an even
>    number of WORD variables then GCC appears to pack both into 32 bits.
> 

What happens with n-byte alignment is that elements of a structure (after the
first) are aligned on boundaries that are the sizeof the element or n-bytes
which ever is smaller.  So, with 8 byte alignment:

	ELEMENT		OFFSET
	-------		------
	WORD	w1;	0 
	DWORD	d1;	4	(2 bytes padding added)
	WORD	w2;	8
	DOUBLE	dbl;	16	(6 bytes padding added)

	total size:	24 bytes.

-- 
Herb Sears
ANGOSS International
herb AT angoss DOT com
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".