www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/04/29/18:07:24

From: jeffdbREMOVETHIS AT goodnet DOT com (Mikey)
Subject: Re: structure packing/allingment
29 Apr 1998 18:07:24 -0700 :
Message-ID: <3547c180.23407674.cygnus.cygwin32.developers@smtp.goodnet.com>
References: <Pine DOT SUN DOT 3 DOT 93 DOT 980429140714 DOT 9870A-100000 AT modi DOT xraylith DOT wisc DOT edu>
Reply-To: jeffdbREMOVETHIS AT goodnet DOT com
Mime-Version: 1.0
To: cygwin32-developers AT cygnus DOT com

-fno-strength-reduce
Because a long time ago when this was a problem under
linux I read several articles that pointed out that with the
paucity of general purpose registers in the x86
strength reduction was of dubious benefit at best, and
probably actually slowed down the code because of
forcing extra moves to memory. 
(That's a remembered quote BTW :)

#define PCC_BITFIELD_TYPE_MATTERS 0
this was defined in the emx port, and the guy apparently
knows what he is doing with structure alignment. 
( I couldn't run the test at the end because I don't have cl.exe :)
If this is handeled somewhere else in the gcc config files,
I couldn't find it.

Would someone who has vc++ please compile the example
at the end and report the results?

`PCC_BITFIELD_TYPE_MATTERS'
     Define this if you wish to imitate the way many other C compilers
     handle alignment of bitfields and the structures that contain them

     The behavior is that the type written for a bitfield (`int',
     `short', or other integer type) imposes an alignment for the
     entire structure, as if the structure really did contain an
     ordinary field of that type.  In addition, the bitfield is placed
     within the structure so that it would fit within such a field, not
     crossing a boundary for it.

     Thus, on most machines, a bitfield whose type is written as `int'
     would not cross a four-byte boundary, and would force four-byte
     alignment for the whole structure.  (The alignment used may not be
     four bytes; it is controlled by the other alignment parameters.)

     If the macro is defined, its definition should be a C expression;
     a nonzero value for the expression enables this behavior.

     Note that if this macro is not defined, or its value is zero, some
     bitfields may cross more than one alignment boundary.  The
     compiler can support such references if there are `insv', `extv',
     and `extzv' insns that can directly reference memory.

     The other known way of making bitfields work is to define
     `STRUCTURE_SIZE_BOUNDARY' as large as `BIGGEST_ALIGNMENT'.  Then
     every structure can be accessed with fullwords.

     Unless the machine has bitfield instructions or you define
     `STRUCTURE_SIZE_BOUNDARY' that way, you must define
     `PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value.
     If your aim is to make GNU CC use the same conventions for laying
     out bitfields as are used by another compiler, here is how to
     investigate what the other compiler does.  Compile and run this
     program:

          struct foo1
          {
            char x;
            char :0;
            char y;
          };

          struct foo2
          {
            char x;
            int :0;
            char y;
          };

          main ()
          {
            printf ("Size of foo1 is %d\n",
                    sizeof (struct foo1));
            printf ("Size of foo2 is %d\n",
                    sizeof (struct foo2));
            exit (0);
          }

     If this prints 2 and 5, then the compiler's behavior is what you
     would get from `PCC_BITFIELD_TYPE_MATTERS'.


On Wed, 29 Apr 1998 14:10:49 -0500 (CDT), you wrote:

>On Tue, 28 Apr 1998, Mikey wrote:
>
>> Ok, I tried the following changes with
>> egcs 1.0.2 + link-compat-ld + Mumit's __declspec.dif
>> and they seem to work, at least bitmaps
>> open without __attribute__((packed))
>> added to the SDK headers. FINALLY!!!
>
>I believe my #pragma was rejected a long time ago that did this, but that
>was before days of egcs.
>
>> add -m486 like this
>> 
>> -#define CPP_PREDEFINES "-Di386 -D_WIN32 \
>> +#define CPP_PREDEFINES "-m486 -Di386 -D_WIN32 \
>
>Thanks for trying this out, and hash out pshpack8.h etc. We do need a more
>general scheme than having to define -m486 etc however. I haven't looked
>at this problem in a *long* time, so don't know what the current status
>is.
>
>> +/* Bitfields may cross alignment boundaries. */
>> +#undef PCC_BITFIELD_TYPE_MATTERS
>> +#define PCC_BITFIELD_TYPE_MATTERS 0
>
>Why this?
>
>> *cc1:
>> %(cc1_cpu) -fno-strength-reduce -malign-jumps=2 -malign-loops=2 -malign-functions=2
>> 
>> *cc1plus:
>> -fno-strength-reduce -malign-jumps=2 -malign-loops=2 -malign-functions=2
>> 
>
>Out of curiosity, why are you using -fno-strength-reduce for egcs? As far
>as I know, it's not a problem anymore since the patches in 2.7.2.3+. Or is
>the bug still there in some form?
>
>Mumit
>


=====================================================
Linux a platform built by, and for users, standing on
the firm legs of reliability, and speed.

Microsoft Windows, a platform without a leg to stand on.

(jeffdbREMOVETHIS AT goodnet DOT com)
delete REMOVETHIS from the above to reply
         Mikey

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019