From: j DOT aldrich6 AT genie DOT com
Message-Id: <199607130546.AA031036801@relay1.geis.com>
Date: Sat, 13 Jul 96 05:30:00 UTC 0000
To: djgpp AT delorie DOT com
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Subject: Re: packed attribute ?

Reply to message 7553226    from BRUCEF AT CENTRA on 07/12/96  7:04AM


>Can someone confirm exactly what this implies, or perhaps
>more importantly, what the absence of it implies.

DJGPP, as a 32-bit compiler, by default aligns structure members
on word and dword boundaries, depending on the native type of the
member.  In effect, each structure member in an unpacked struct
will be aligned so as to start on a 4-byte boundary.  This significantly
improves performance when running in protected mode.  Packing
forces the compiler to not pad members, which can mean a significant
performance loss.

>For example, I see it is required when accessing VBE based
>data structures, and I imagine that if the packed clause was not
>used then the data structure would be mis-aligned with what
>vesa has returned.

That is correct.

>for example, how would you address next_byte if you
>were writing an assembler module and had the
>starting address of the below structure.  If it was
>packed, then it would be at offset 1, but what if the
>packed clause wasn't used?  This is not something
>I have encountered in real-mode programming.
>
>typedef struct
>{
>char	byte_at_offset_0;	// Offset 0
>char	next_byte;	// Offset ?
>} DEMO_STRUCT;
>
>DEMO_STRUCT MyData;

Well, the easiest way to test this is to compile a program containing
that code with -S to create an ASM file and then examine the result.
If my understanding is correct, then the DEMO_STRUCT structure
would take up a total of 8 bytes, arranged like so:

MyData + 0:  byte_at_offset_0
             <3 bytes of padding>
MyData + 4:  next_byte
             <3 bytes of padding>

>Also, I notice that assmbler code is often
>preceded with .align 4.
>
>I imagine this is to force the start of code to be aligned
>on a dword boundary.  Is this purely a performance
>concession?

Exactly.  There is a huge performance penalty for unaligned accesses.
The FAQ describes this in some detail (section 22.9, among others).

John