From: herb@angoss.com (Herb Sears) Subject: Re: one point (Was [Re: FW: Re: wxwin port]) 19 Nov 1996 13:51:36 -0800 Sender: daemon@cygnus.com Approved: cygnus.gnu-win32@cygnus.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@cygnus.com (Doug Evans) Original-Cc: garp@opustel.com, gnu-win32@cygnus.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@cygnus.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@angoss.com - For help on using this list, send a message to "gnu-win32-request@cygnus.com" with one line of text: "help".