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