From: kagel AT quasar DOT bloomberg DOT com
Date: Fri, 12 Jul 1996 14:32:06 -0400
Message-Id: <9607121832.AA14488@quasar.bloomberg.com >
To: brucef AT central DOT co DOT nz
Cc: djgpp AT delorie DOT com
In-Reply-To: <4s5env$cqi@status.gen.nz> (brucef@central.co.nz)
Subject: Re: packed attribute ?
Reply-To: kagel AT dg1 DOT bloomberg DOT com

   From: brucef AT central DOT co DOT nz (Bruce Foley)
   Date: Fri, 12 Jul 1996 11:04:28 GMT

   Hi.  just a quick question regarding the __attribute__ ((packed))
   clause commonly used on data structures.

   Can someone confirm exactly what this implies, or perhaps
   more importantly, what the absence of it implies.
   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.  Does this mean then, that DJGPP will
   align data on word or even dword boundaries?
   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

Because DJGPP is a 32bit environment, DJGPP structures (andeven scalar
variables) are allocated aligned according to their size with 4byte alignment
the strictest.  This means that char is unaligned, or 1byte aligned, shorts are
2byte aligned on even addresses; longs, ints, floats, and doubles are aligned
on 4byte addresses (addr mod 4 == 0); and structures are aligned internally
according to these rules and the structure itself is padded at the end such
that the next element in an array of structs remains aligned.

   packed clause wasn't used?  This is not something
   I have encountered in real-mode programming.

Sure you did it is just that in real-mode, read 16bit, programming the
strictest alignment is 2byte alignment so only a larger object following an odd
number of chars is affected.  You just did not run into it when you were
looking.  Since it happens more often in 32bit programming it is more
noticeable.  (Try: struct fred { char f; long l; }; sizeof (struct fred) in
your 16bit compiler you'll find that sizeof returns 6 not 5, while DJGPP will
return 8.)

   typedef struct
   {
   char	byte_at_offset_0;	// Offset 0
   char	next_byte;	// Offset ?
   } DEMO_STRUCT;

   DEMO_STRUCT MyData;


   Also, I notice that assmbler code is often
   preceded with .align 4.

This forces 4byte alignment as in DJGPP.

   I imagine this is to force the start of code to be aligned
   on a dword boundary.  Is this purely a performance
   concession?

Yes.  A fine reason if you ask me.  But it may also be done for compatibility
with DJGPP "C" code or variables which are all aligned.   BTW DJGPP does this
even for scalar variables for performance.  So:

{
    static long zero;
    static long one;
    static char two;
    static long three;
    static char four;
    static double five;

    printf( "diff: %d\n", (long)&three -(long) &one );
    printf( "diff: %d\n", (long)&two - (long)&one );
    printf( "diff: %d\n", (long)&four - (long)&two );
    printf( "diff: %d\n", (long)&one - (long)&one );
    printf( "diff: %d\n", (long)&five - (long)&one );
}
Prints out:

diff: 8
diff: 4
diff: 8
diff: 12
diff: 16

On my UNIX system at work with GCC version 2.6.3.22 the output is also:

diff: 8
diff: 4
diff: 8
diff: 12
diff: 20            Because the Motorolla 88100 requires object size alignment 
		to a strictest align of 8bytes for doubles.

-- 
Art S. Kagel, kagel AT quasar DOT bloomberg DOT com

A proverb is no proverb to you 'till life has illustrated it.  -- John Keats