Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #147185 > unrolled thread

Bit field usage

Back to article view | Back to comp.lang.c

Contents

  Bit field usage jacobnavia <jacob@jacob.remcomp.fr> - 2019-10-24 08:03 +0200
    Re: Bit field usage Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-10-24 10:15 -0600
      Re: Bit field usage jacobnavia <jacob@jacob.remcomp.fr> - 2019-10-24 18:55 +0200
        Re: Bit field usage Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-10-24 21:28 -0600
      Re: Bit field usage scott@slp53.sl.home (Scott Lurndal) - 2019-10-24 17:22 +0000
        Re: Bit field usage Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-24 19:45 +0200
          Re: Bit field usage jacobnavia <jacob@jacob.remcomp.fr> - 2019-10-24 19:59 +0200
            Re: Bit field usage Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-24 20:02 +0200
              Re: Bit field usage Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-10-24 21:29 -0600
                Re: Bit field usage Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-25 07:51 +0200
                  Re: Bit field usage scott@slp53.sl.home (Scott Lurndal) - 2019-10-25 15:05 +0000
          Re: Bit field usage Bart <bc@freeuk.com> - 2019-10-24 19:13 +0100
            Re: Bit field usage Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-24 20:54 +0200
              Re: Bit field usage Bart <bc@freeuk.com> - 2019-10-24 20:12 +0100
                Re: Bit field usage David Brown <david.brown@hesbynett.no> - 2019-10-24 23:03 +0200
                  Re: Bit field usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-24 22:50 +0100
                    Re: Bit field usage David Brown <david.brown@hesbynett.no> - 2019-10-25 09:18 +0200
                      Re: Bit field usage Reinhardt Behm <rbehm@hushmail.com> - 2019-10-25 15:46 +0800
                      Re: Bit field usage Robert Wessel <robertwessel2@yahoo.com> - 2019-10-26 12:36 -0500
                  Re: Bit field usage scott@slp53.sl.home (Scott Lurndal) - 2019-10-25 15:04 +0000
                    Re: Bit field usage Robert Wessel <robertwessel2@yahoo.com> - 2019-10-26 12:40 -0500
                  Re: Bit field usage Philipp Klaus Krause <pkk@spth.de> - 2019-10-26 21:12 +0200
                Re: Bit field usage Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-10-25 09:25 -0600
                  Re: Bit field usage Robert Wessel <robertwessel2@yahoo.com> - 2019-10-26 12:52 -0500
        Re: Bit field usage jacobnavia <jacob@jacob.remcomp.fr> - 2019-10-24 19:56 +0200
          Re: Bit field usage already5chosen@yahoo.com - 2019-10-24 12:03 -0700
            Re: Bit field usage scott@slp53.sl.home (Scott Lurndal) - 2019-10-24 19:40 +0000
              Re: Bit field usage jacobnavia <jacob@jacob.remcomp.fr> - 2019-10-24 22:15 +0200
              Re: Bit field usage already5chosen@yahoo.com - 2019-10-24 14:16 -0700
      Re: Bit field usage Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-24 17:50 -0700
        Re: Bit field usage Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-10-25 09:36 -0600
          Re: Bit field usage Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-27 04:54 -0700
            Re: Bit field usage Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-10-27 10:05 -0600
    Re: Bit field usage Philipp Klaus Krause <pkk@spth.de> - 2019-10-26 20:15 +0200
      Re: Bit field usage Philipp Klaus Krause <pkk@spth.de> - 2019-10-26 20:16 +0200
        Re: Bit field usage jacobnavia <jacob@jacob.remcomp.fr> - 2019-10-26 20:37 +0200
          Re: Bit field usage Robert Wessel <robertwessel2@yahoo.com> - 2019-10-26 13:41 -0500
            Re: Bit field usage jacobnavia <jacob@jacob.remcomp.fr> - 2019-10-26 21:54 +0200
              Re: Bit field usage already5chosen@yahoo.com - 2019-10-27 03:46 -0700
                Re: Bit field usage jacobnavia <jacob@jacob.remcomp.fr> - 2019-10-27 12:50 +0100
                  Re: Bit field usage already5chosen@yahoo.com - 2019-10-27 06:37 -0700
                Re: Bit field usage David Brown <david.brown@hesbynett.no> - 2019-10-27 13:00 +0100
                  Re: Bit field usage already5chosen@yahoo.com - 2019-10-27 07:19 -0700
                    Re: Bit field usage David Brown <david.brown@hesbynett.no> - 2019-10-27 22:30 +0100
                      Re: Bit field usage Christopher Collins <ccollins476ad@gmail.com> - 2019-11-07 12:36 -0800
                        Re: Bit field usage David Brown <david.brown@hesbynett.no> - 2019-11-08 08:18 +0100
                          Re: Bit field usage Christopher Collins <ccollins476ad@gmail.com> - 2019-11-08 10:19 -0800
                            Re: Bit field usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-08 21:47 +0000
                            Re: Bit field usage David Brown <david.brown@hesbynett.no> - 2019-11-10 14:08 +0100
                              Re: Bit field usage Christopher Collins <ccollins476ad@gmail.com> - 2019-11-11 09:26 -0800
                                Re: Bit field usage David Brown <david.brown@hesbynett.no> - 2019-11-11 20:31 +0100
                                  Re: Bit field usage Christopher Collins <ccollins476ad@gmail.com> - 2019-11-11 23:01 -0800
                                    Re: Bit field usage Christopher Collins <ccollins476ad@gmail.com> - 2019-11-11 23:25 -0800
                                    Re: Bit field usage David Brown <david.brown@hesbynett.no> - 2019-11-12 10:54 +0100
                                      Re: Bit field usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-12 14:43 +0000
                                        Re: Bit field usage James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 10:54 -0500
                                          Re: Bit field usage David Brown <david.brown@hesbynett.no> - 2019-11-12 19:37 +0100
                Re: Bit field usage Robert Wessel <robertwessel2@yahoo.com> - 2019-10-27 08:36 -0500
                  Re: Bit field usage already5chosen@yahoo.com - 2019-10-27 06:49 -0700
              Re: Bit field usage Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-27 14:23 +0100
              Re: Bit field usage Robert Wessel <robertwessel2@yahoo.com> - 2019-10-27 08:42 -0500
          Re: Bit field usage Philipp Klaus Krause <pkk@spth.de> - 2019-10-26 21:06 +0200
          Re: Bit field usage Bart <bc@freeuk.com> - 2019-10-26 20:41 +0100
            Re: Bit field usage Philipp Klaus Krause <pkk@spth.de> - 2019-10-27 08:29 +0100
              Re: Bit field usage David Brown <david.brown@hesbynett.no> - 2019-10-27 13:05 +0100

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#147249

On Fri, 25 Oct 2019 15:04:28 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:

>David Brown <david.brown@hesbynett.no> writes:
>
>>This is from the guys that brought us the "halt and catch fire" assembly 
>>instruction, as well as the "EIEIO" instruction, so I suppose they have 
>>an odd sense of humour.
>
>The idea of a HCF instruction predates Power by a couple decades (I saw it used as early as 1978 in
>a newsletter list of imaginary opcodes,  another was "Punch Operator").


Along with Rewind Disk and Byte Baudy Bit and Branch...

[toc] | [prev] | [next] | [standalone]

#147259

Am 24.10.19 um 23:03 schrieb David Brown:
> This is from the guys that brought us the "halt and catch fire" assembly
> instruction, as well as the "EIEIO" instruction, so I suppose they have
> an odd sense of humour.
Well, there are systems that offer a full range of jumps / branches:

branch always
branch [some condition]
branch never

jump on true
jump on [some condition]
jump on false

E.g. the S08 and the STM8.

And then there are systems with hardware support for "come from" (very
useful if you think code using goto is too easy to read).

[toc] | [prev] | [next] | [standalone]

#147230

Bart <bc@freeuk.com> writes:

> On 24/10/2019 19:54, Bonita Montero wrote:
>>> But if so that would be wrong, since bit-numbering should be
>>> independent of memory layout. ...
>>
>> It isn't since this would complicate the assembly and disassembly of
>> words.
>
>
> I thought it was generally accepted that bit N of an integer value
> adds 2**N to its value when set. So bit 0 (adding 2**0 or 1) would be
> the least significant.
>
> This /must/ be independent of its layout when store in memory.

I agree that this is the only reasonable way to number the bits in a
byte (or a word), just as the only reasonable way to order the bytes in
a word is with the least significant first.  However, just as there
are people who prefer the wrong byte order, there are architectures that
number the bits backwards -- IBM comes to mind (in fairness, I don't
know whether they have any instructions for which it actually matters).

[toc] | [prev] | [next] | [standalone]

#147251

On Fri, 25 Oct 2019 09:25:48 -0600, Joe Pfeiffer
<pfeiffer@cs.nmsu.edu> wrote:

>Bart <bc@freeuk.com> writes:
>
>> On 24/10/2019 19:54, Bonita Montero wrote:
>>>> But if so that would be wrong, since bit-numbering should be
>>>> independent of memory layout. ...
>>>
>>> It isn't since this would complicate the assembly and disassembly of
>>> words.
>>
>>
>> I thought it was generally accepted that bit N of an integer value
>> adds 2**N to its value when set. So bit 0 (adding 2**0 or 1) would be
>> the least significant.
>>
>> This /must/ be independent of its layout when store in memory.
>
>I agree that this is the only reasonable way to number the bits in a
>byte (or a word), just as the only reasonable way to order the bytes in
>a word is with the least significant first.  However, just as there
>are people who prefer the wrong byte order, there are architectures that
>number the bits backwards -- IBM comes to mind (in fairness, I don't
>know whether they have any instructions for which it actually matters).


A few places.  For example, the Z instruction Find Leftmost One
(FLOGR), roughly the equivalent of x86 Bit Scan Reverse (BSR), returns
a index to the leftmost bit based on the system's usual numbering
convention, and thus effectively numbered from the opposite end of the
register as what x86 does.  Some of the other bit manipulation
instructions as well (Rotate Then (operation) Selected Bits, for
example).

[toc] | [prev] | [next] | [standalone]

#147201

Le 24/10/2019 à 19:22, Scott Lurndal a écrit :
> Not necessarily,  ARM, for example, has both bitfield extract and
> bitfield insert instructions.

That doesn't matter. Here is the assembler code for the following C 
program generated by gcc with -O2 -c -S using an ARM 64:

   1 struct data {
   2     unsigned isOld:1;
   3     unsigned writtenAlready:1;
   4     unsigned discarded:1;
   5     double *table;
   6 };
   7 struct data1 {
   8     unsigned char isOld;
   9     unsigned char writtenAlready;
  10     unsigned char discarded;
  11     double *table;
  12 };
  13
  14 struct data Data;
  15 struct data1 Data1;
  16 #include <stdio.h>
  17 int main(void)
  18 {
  19     Data1.discarded = 1;
  20     Data.discarded = 1;
  21 }

Assembler code:

   9     adrp    x1, :got:Data
  10     adrp    x3, :got:Data1
  11     mov w4, 1
  12     mov w0, 0
  13     ldr x1, [x1, #:got_lo12:Data]
  14     ldr x3, [x3, #:got_lo12:Data1]
  15     ldrb    w2, [x1]
  16     strb    w4, [x3, 2]
  17     orr w2, w2, 4
  18     strb    w2, [x1]
  19     ret

The relevant instructions for accessing Data (using bit fields) are:

   9     adrp    x1, :got:Data  9     adrp    x1, :got:Data
  13     ldr x1, [x1, #:got_lo12:Data]
  15     ldrb    w2, [x1]
  17     orr w2, w2, 4
  18     strb    w2, [x1]

The relevant instructions for accessing Data1 (using unsigned char) are:
  10     adrp    x3, :got:Data1
  11     mov w4, 1
  14     ldr x3, [x3, #:got_lo12:Data1]
  16     strb    w4, [x3, 2]

The code needed for bit fields has 1 instruction more. The bit field 
instructions are handy, for sure, they eliminate the shifts when you 
have to extract a bit field from a byte/word, but they can't eliminate 
the overhead. In this case is 4 against 5 instructions, i.e. a 20% overhead.

[toc] | [prev] | [next] | [standalone]

#147208

On Thursday, October 24, 2019 at 8:56:18 PM UTC+3, jacobnavia wrote:
> Le 24/10/2019 à 19:22, Scott Lurndal a écrit :
> > Not necessarily,  ARM, for example, has both bitfield extract and
> > bitfield insert instructions.
> 
> That doesn't matter. Here is the assembler code for the following C 
> program generated by gcc with -O2 -c -S using an ARM 64:
> 
>    1 struct data {
>    2     unsigned isOld:1;
>    3     unsigned writtenAlready:1;
>    4     unsigned discarded:1;
>    5     double *table;
>    6 };
>    7 struct data1 {
>    8     unsigned char isOld;
>    9     unsigned char writtenAlready;
>   10     unsigned char discarded;
>   11     double *table;
>   12 };
>   13
>   14 struct data Data;
>   15 struct data1 Data1;
>   16 #include <stdio.h>
>   17 int main(void)
>   18 {
>   19     Data1.discarded = 1;
>   20     Data.discarded = 1;
>   21 }
> 
> Assembler code:
> 
>    9     adrp    x1, :got:Data
>   10     adrp    x3, :got:Data1
>   11     mov w4, 1
>   12     mov w0, 0
>   13     ldr x1, [x1, #:got_lo12:Data]
>   14     ldr x3, [x3, #:got_lo12:Data1]
>   15     ldrb    w2, [x1]
>   16     strb    w4, [x3, 2]
>   17     orr w2, w2, 4
>   18     strb    w2, [x1]
>   19     ret
> 
> The relevant instructions for accessing Data (using bit fields) are:
> 
>    9     adrp    x1, :got:Data  9     adrp    x1, :got:Data
>   13     ldr x1, [x1, #:got_lo12:Data]
>   15     ldrb    w2, [x1]
>   17     orr w2, w2, 4
>   18     strb    w2, [x1]
> 
> The relevant instructions for accessing Data1 (using unsigned char) are:
>   10     adrp    x3, :got:Data1
>   11     mov w4, 1
>   14     ldr x3, [x3, #:got_lo12:Data1]
>   16     strb    w4, [x3, 2]
> 
> The code needed for bit fields has 1 instruction more. The bit field 
> instructions are handy, for sure, they eliminate the shifts when you 
> have to extract a bit field from a byte/word, but they can't eliminate 
> the overhead. In this case is 4 against 5 instructions, i.e. a 20% overhead.

Bit Field Clear, Bit Field Insert, Signed Bit Field Extract and Unsigned Bit Field Extract are A32/T32 instructions. They have no aarch64 counterparts.

[toc] | [prev] | [next] | [standalone]

#147211

already5chosen@yahoo.com writes:
>On Thursday, October 24, 2019 at 8:56:18 PM UTC+3, jacobnavia wrote:
>> Le 24/10/2019 =C3=A0 19:22, Scott Lurndal a =C3=A9crit=C2=A0:
>> > Not necessarily,  ARM, for example, has both bitfield extract and
>> > bitfield insert instructions.
>>=20
>> That doesn't matter. Here is the assembler code for the following C=20
>> program generated by gcc with -O2 -c -S using an ARM 64:
>>=20
>>    1 struct data {
>>    2     unsigned isOld:1;
>>    3     unsigned writtenAlready:1;
>>    4     unsigned discarded:1;
>>    5     double *table;
>>    6 };
>>    7 struct data1 {
>>    8     unsigned char isOld;
>>    9     unsigned char writtenAlready;
>>   10     unsigned char discarded;
>>   11     double *table;
>>   12 };
>>   13
>>   14 struct data Data;
>>   15 struct data1 Data1;
>>   16 #include <stdio.h>
>>   17 int main(void)
>>   18 {
>>   19     Data1.discarded =3D 1;
>>   20     Data.discarded =3D 1;
>>   21 }
>>=20
>> Assembler code:
>>=20
>>    9     adrp    x1, :got:Data
>>   10     adrp    x3, :got:Data1
>>   11     mov w4, 1
>>   12     mov w0, 0
>>   13     ldr x1, [x1, #:got_lo12:Data]
>>   14     ldr x3, [x3, #:got_lo12:Data1]
>>   15     ldrb    w2, [x1]
>>   16     strb    w4, [x3, 2]
>>   17     orr w2, w2, 4
>>   18     strb    w2, [x1]
>>   19     ret
>>=20
>> The relevant instructions for accessing Data (using bit fields) are:
>>=20
>>    9     adrp    x1, :got:Data  9     adrp    x1, :got:Data
>>   13     ldr x1, [x1, #:got_lo12:Data]
>>   15     ldrb    w2, [x1]
>>   17     orr w2, w2, 4
>>   18     strb    w2, [x1]
>>=20
>> The relevant instructions for accessing Data1 (using unsigned char) are:
>>   10     adrp    x3, :got:Data1
>>   11     mov w4, 1
>>   14     ldr x3, [x3, #:got_lo12:Data1]
>>   16     strb    w4, [x3, 2]
>>=20
>> The code needed for bit fields has 1 instruction more. The bit field=20
>> instructions are handy, for sure, they eliminate the shifts when you=20
>> have to extract a bit field from a byte/word, but they can't eliminate=20
>> the overhead. In this case is 4 against 5 instructions, i.e. a 20% overhe=
>ad.
>
>Bit Field Clear, Bit Field Insert, Signed Bit Field Extract and Unsigned Bi=
>t Field Extract are A32/T32 instructions. They have no aarch64 counterparts=
>.

Actually Aarch64 has the following instructions:
   Section C6.2.26  BFI (Bitfield Insert - alias for BFM)
   Section C6.2.25  BFC (Bitfield Clear - alias for BFM)
   Section C6.2.27  BFM (Bitfield Move)
   Section C6.2.28  BFXIL (Bitfield Extract and Insert Low - alias for BFM)

references to DDI0487D revision b (ARMv8 Architecture Reference Manual)

I'll have to check our version of gcc for ARM64 to see if it generates them.

[toc] | [prev] | [next] | [standalone]

#147212

Le 24/10/2019 à 21:40, Scott Lurndal a écrit :
> I'll have to check our version of gcc for ARM64 to see if it generates them.

Of course it does. If I change the length of the bit field to 3 bits, it 
will generate:
  18     bfi w3, w4, 2, 3

i.e. bit field insert w4 (contains 1) from bit 2 with length 3 bits and 
put the result in w3. The overhead remains the same as before, it is 
just that it doesn't a simple OR instruction but a bit field insert... 
Still one instruction more

[toc] | [prev] | [next] | [standalone]

#147216

On Thursday, October 24, 2019 at 10:40:50 PM UTC+3, Scott Lurndal wrote:
> already5chosen@yahoo.com writes:
> >On Thursday, October 24, 2019 at 8:56:18 PM UTC+3, jacobnavia wrote:
> >> Le 24/10/2019 =C3=A0 19:22, Scott Lurndal a =C3=A9crit=C2=A0:
> >> > Not necessarily,  ARM, for example, has both bitfield extract and
> >> > bitfield insert instructions.
> >>=20
> >> That doesn't matter. Here is the assembler code for the following C=20
> >> program generated by gcc with -O2 -c -S using an ARM 64:
> >>=20
> >>    1 struct data {
> >>    2     unsigned isOld:1;
> >>    3     unsigned writtenAlready:1;
> >>    4     unsigned discarded:1;
> >>    5     double *table;
> >>    6 };
> >>    7 struct data1 {
> >>    8     unsigned char isOld;
> >>    9     unsigned char writtenAlready;
> >>   10     unsigned char discarded;
> >>   11     double *table;
> >>   12 };
> >>   13
> >>   14 struct data Data;
> >>   15 struct data1 Data1;
> >>   16 #include <stdio.h>
> >>   17 int main(void)
> >>   18 {
> >>   19     Data1.discarded =3D 1;
> >>   20     Data.discarded =3D 1;
> >>   21 }
> >>=20
> >> Assembler code:
> >>=20
> >>    9     adrp    x1, :got:Data
> >>   10     adrp    x3, :got:Data1
> >>   11     mov w4, 1
> >>   12     mov w0, 0
> >>   13     ldr x1, [x1, #:got_lo12:Data]
> >>   14     ldr x3, [x3, #:got_lo12:Data1]
> >>   15     ldrb    w2, [x1]
> >>   16     strb    w4, [x3, 2]
> >>   17     orr w2, w2, 4
> >>   18     strb    w2, [x1]
> >>   19     ret
> >>=20
> >> The relevant instructions for accessing Data (using bit fields) are:
> >>=20
> >>    9     adrp    x1, :got:Data  9     adrp    x1, :got:Data
> >>   13     ldr x1, [x1, #:got_lo12:Data]
> >>   15     ldrb    w2, [x1]
> >>   17     orr w2, w2, 4
> >>   18     strb    w2, [x1]
> >>=20
> >> The relevant instructions for accessing Data1 (using unsigned char) are:
> >>   10     adrp    x3, :got:Data1
> >>   11     mov w4, 1
> >>   14     ldr x3, [x3, #:got_lo12:Data1]
> >>   16     strb    w4, [x3, 2]
> >>=20
> >> The code needed for bit fields has 1 instruction more. The bit field=20
> >> instructions are handy, for sure, they eliminate the shifts when you=20
> >> have to extract a bit field from a byte/word, but they can't eliminate=20
> >> the overhead. In this case is 4 against 5 instructions, i.e. a 20% overhe=
> >ad.
> >
> >Bit Field Clear, Bit Field Insert, Signed Bit Field Extract and Unsigned Bi=
> >t Field Extract are A32/T32 instructions. They have no aarch64 counterparts=
> >.
> 
> Actually Aarch64 has the following instructions:
>    Section C6.2.26  BFI (Bitfield Insert - alias for BFM)
>    Section C6.2.25  BFC (Bitfield Clear - alias for BFM)
>    Section C6.2.27  BFM (Bitfield Move)
>    Section C6.2.28  BFXIL (Bitfield Extract and Insert Low - alias for BFM)
> 
> references to DDI0487D revision b (ARMv8 Architecture Reference Manual)
> 
> I'll have to check our version of gcc for ARM64 to see if it generates them.

You are correct.
My mistake was relying on very old beta version of the armv8 document.
In the copy I downloaded today (ARM DDI 0487B.a (ID033117)):
C6.2.22 BFI
C6.2.23 BFM 
C6.2.24 BFXIL
C6.2.192 SBFIZ
C6.2.193 SBFM
C6.2.194 SBFX
C6.2.276 UBFIZ
C6.2.277 UBFM
C6.2.278 UBFX

[toc] | [prev] | [next] | [standalone]

#147220

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:

> jacobnavia <jacob@jacob.remcomp.fr> writes:
>
>> 1) To access a bitfield, the compiler generates a sequence of shifts
>> that increases execution time.
>>
>> 2) The instructions sequence of the shifts increases code size.
>>
>> Obviously, if you have more than 64 flags (in a 64 bit machine) or
>> more than 32 flags in a 32 bit machine, bitfields can save a lot of
>> data space:  you can fit up to 128 bitfields in 16 bytes, instead of
>> 128 bytes if you use a full char for each bit field.
>>
>> It is important to check two things:
>> 1) If a bit field is heavily used, consider transforming it into an
>> unsigned char.
>> 2) If you have a few bit fields with bitsize less than the word size
>> of your machine, consider if the alignment requirements are nullifying
>> any space gains obtained by using bit fields.
>
> I got burned badly enough by bitfields doing unexpected things decades
> ago that I abandoned them and do my own shifts and masks.

Out of curiosity, what kind of problems did you run into?

[toc] | [prev] | [next] | [standalone]

#147231

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>
>>> 1) To access a bitfield, the compiler generates a sequence of shifts
>>> that increases execution time.
>>>
>>> 2) The instructions sequence of the shifts increases code size.
>>>
>>> Obviously, if you have more than 64 flags (in a 64 bit machine) or
>>> more than 32 flags in a 32 bit machine, bitfields can save a lot of
>>> data space:  you can fit up to 128 bitfields in 16 bytes, instead of
>>> 128 bytes if you use a full char for each bit field.
>>>
>>> It is important to check two things:
>>> 1) If a bit field is heavily used, consider transforming it into an
>>> unsigned char.
>>> 2) If you have a few bit fields with bitsize less than the word size
>>> of your machine, consider if the alignment requirements are nullifying
>>> any space gains obtained by using bit fields.
>>
>> I got burned badly enough by bitfields doing unexpected things decades
>> ago that I abandoned them and do my own shifts and masks.
>
> Out of curiosity, what kind of problems did you run into?

It was a long time ago...  if I remember correctly (always a big if!) I
was using them to construct things like instruction and floating point
formats, and things got scrambled in the switch from Motorola 680x0 to
Sparc.

[toc] | [prev] | [next] | [standalone]

#147282

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>>
>>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>>
>>>> 1) To access a bitfield, the compiler generates a sequence of shifts
>>>> that increases execution time.
>>>>
>>>> 2) The instructions sequence of the shifts increases code size.
>>>>
>>>> Obviously, if you have more than 64 flags (in a 64 bit machine) or
>>>> more than 32 flags in a 32 bit machine, bitfields can save a lot of
>>>> data space:  you can fit up to 128 bitfields in 16 bytes, instead of
>>>> 128 bytes if you use a full char for each bit field.
>>>>
>>>> It is important to check two things:
>>>> 1) If a bit field is heavily used, consider transforming it into an
>>>> unsigned char.
>>>> 2) If you have a few bit fields with bitsize less than the word size
>>>> of your machine, consider if the alignment requirements are nullifying
>>>> any space gains obtained by using bit fields.
>>>
>>> I got burned badly enough by bitfields doing unexpected things decades
>>> ago that I abandoned them and do my own shifts and masks.
>>
>> Out of curiosity, what kind of problems did you run into?
>
> It was a long time ago...  if I remember correctly (always a big if!)  I
> was using them to construct things like instruction and floating point
> formats, and things got scrambled in the switch from Motorola 680x0 to
> Sparc.

Do you remember anything else?  This tells me when you ran into
some problems but not what the problems were.  Might the problems
have been not with bitfields per se but just with platform
differences?  Making a guess, maybe you simply found it easier to
get things right (for the two platforms) using shifting and
masking than using two sets of bitfields?  I think bitfields
work pretty well for a single platform, but are sometimes hard to
get right if dealing with multiple platforms.

[toc] | [prev] | [next] | [standalone]

#147292

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>>
>> It was a long time ago...  if I remember correctly (always a big if!)  I
>> was using them to construct things like instruction and floating point
>> formats, and things got scrambled in the switch from Motorola 680x0 to
>> Sparc.
>
> Do you remember anything else?  This tells me when you ran into
> some problems but not what the problems were.  Might the problems
> have been not with bitfields per se but just with platform
> differences?  Making a guess, maybe you simply found it easier to
> get things right (for the two platforms) using shifting and
> masking than using two sets of bitfields?  I think bitfields
> work pretty well for a single platform, but are sometimes hard to
> get right if dealing with multiple platforms.

Oh, the issue was definitely platform differences and portability.  And
yes, I found it immensely easier to get it right for the multiple
platforms with shifts and masks (and macroes defining those shifts and
masks) than bitfields.

I suppose if I'd been confident I was never going to switch platforms
again I might have tried to figure out how to get them to work with the
new platform.  But if I'm remembering correctly that it was the
680x0-Sparc switch, I've changed platforms once (to x86) and arguably
twice (x86-64) since then.

[toc] | [prev] | [next] | [standalone]

#147253

bitfields are great tool to save data memory. You pay a price in
execution speed and code memory, but often, it is worth it. In small
embedded systems and in retrocomputing, you often have to work with
hardware that has a 32 : 1 ratio of code memory to data memory.

Philipp

[toc] | [prev] | [next] | [standalone]

#147254

Am 26.10.19 um 20:15 schrieb Philipp Klaus Krause:
> bitfields are great tool to save data memory. You pay a price in
> execution speed and code memory, but often, it is worth it. In small
> embedded systems and in retrocomputing, you often have to work with
> hardware that has a 32 : 1 ratio of code memory to data memory.
> 
> Philipp
> 

An dof course, what applies on small systems regarding the whole system,
also applies on big systems when it comes to performance-optimization by
making things fit into caches.

Philipp

[toc] | [prev] | [next] | [standalone]

#147255

Le 26/10/2019 à 20:16, Philipp Klaus Krause a écrit :
> Am 26.10.19 um 20:15 schrieb Philipp Klaus Krause:
>> bitfields are great tool to save data memory. You pay a price in
>> execution speed and code memory, but often, it is worth it. In small
>> embedded systems and in retrocomputing, you often have to work with
>> hardware that has a 32 : 1 ratio of code memory to data memory.
>>
>> Philipp
>>
> 
> An dof course, what applies on small systems regarding the whole system,
> also applies on big systems when it comes to performance-optimization by
> making things fit into caches.
> 
> Philipp
> 

Hi Philipp
If you read my message, I demonstrated that in a 64 bit system, and in 
many 32 bit systems, using less than the word size of bit fields doesn't 
lead to ANY space savings compared to unsigned char.

struct foo {
	int field1:2;
	int field2:3;
	char *pData;
};

This structure has the SAME size than

struct foo {
	unsigned char field1;
	unsigned char field2;
	char *pData;
};

This is the same for 32 and 64 bit systems. In your message you do not 
address this at all...

[toc] | [prev] | [next] | [standalone]

#147256

On Sat, 26 Oct 2019 20:37:24 +0200, jacobnavia
<jacob@jacob.remcomp.fr> wrote:

>Le 26/10/2019 à 20:16, Philipp Klaus Krause a écrit :
>> Am 26.10.19 um 20:15 schrieb Philipp Klaus Krause:
>>> bitfields are great tool to save data memory. You pay a price in
>>> execution speed and code memory, but often, it is worth it. In small
>>> embedded systems and in retrocomputing, you often have to work with
>>> hardware that has a 32 : 1 ratio of code memory to data memory.
>>>
>>> Philipp
>>>
>> 
>> An dof course, what applies on small systems regarding the whole system,
>> also applies on big systems when it comes to performance-optimization by
>> making things fit into caches.
>> 
>> Philipp
>> 
>
>Hi Philipp
>If you read my message, I demonstrated that in a 64 bit system, and in 
>many 32 bit systems, using less than the word size of bit fields doesn't 
>lead to ANY space savings compared to unsigned char.
>
>struct foo {
>	int field1:2;
>	int field2:3;
>	char *pData;
>};
>
>This structure has the SAME size than
>
>struct foo {
>	unsigned char field1;
>	unsigned char field2;
>	char *pData;
>};
>
>This is the same for 32 and 64 bit systems. In your message you do not 
>address this at all...


That is not true of all 64-bit implementations, of course.  Consider
MSVC invoked with /Zp1.  Of course it's true of many implementations.

[toc] | [prev] | [next] | [standalone]

#147261

Le 26/10/2019 à 20:41, Robert Wessel a écrit :
> That is not true of all 64-bit implementations, of course.  Consider
> MSVC invoked with /Zp1.  Of course it's true of many implementations.

Yes, packing fields would be possible in processors like the x86. It is 
not possible in RISC processors where alignment is much stricter. And 
even in the x86 you get a penalty for misaligned pointer data.

As I said in my original message, if the bit field is not used in a loop 
or is not used very often, it doesn't matter. In highly used bit fields, 
a speed advantage can be gained if the bitfield is transformed into an 
unsigned char or bigger.

Sure, if there is an array of 2 million positions, and a bit field can 
be used to improve space requirements of course, it is better to save 
space with it.

Software engineering is the art of compromise, of finding the best 
balance from contradictory requirements. In my message I pointed out 
some weakness of bit fields. It is not a prescription to forget about them!

[toc] | [prev] | [next] | [standalone]

#147279

On Saturday, October 26, 2019 at 10:54:34 PM UTC+3, jacobnavia wrote:
> Le 26/10/2019 à 20:41, Robert Wessel a écrit :
> > That is not true of all 64-bit implementations, of course.  Consider
> > MSVC invoked with /Zp1.  Of course it's true of many implementations.
> 
> Yes, packing fields would be possible in processors like the x86. It is 
> not possible in RISC processors where alignment is much stricter.

There are only 2 high-performance RISCs that are still relevant for new development: ARM/ARM64 and POWER. ARM has no alignment requirements on the integer side of the ISA. The same for Power in Big Endian mode. As far as I remember, Power operating in Little Endian mode used to have alignment requirements, but it seems that since Power8 they have "pure little-endian" mode that removes these limitations.

> And 
> even in the x86 you get a penalty for misaligned pointer data.

On modern x86 hardware misaligned access that does not cross cache line boundaries costs you nothing. Crossing cache line boundary costs little. Only crossing page boundaries could be considered expensive.

> 
> As I said in my original message, if the bit field is not used in a loop 
> or is not used very often, it doesn't matter. In highly used bit fields, 
> a speed advantage can be gained if the bitfield is transformed into an 
> unsigned char or bigger.
> 
> Sure, if there is an array of 2 million positions, and a bit field can 
> be used to improve space requirements of course, it is better to save 
> space with it.
> 
> Software engineering is the art of compromise, of finding the best 
> balance from contradictory requirements. In my message I pointed out 
> some weakness of bit fields. It is not a prescription to forget about them!

[toc] | [prev] | [next] | [standalone]

#147281

Le 27/10/2019 à 11:46, already5chosen@yahoo.com a écrit :
>   ARM/ARM64 and POWER. ARM has no alignment requirements on the integer side of the ISA.

Here are the relevant pages of the ARM64 Architecture manual

<quote>
B2.4.2 Alignment of data accesses
An unaligned access to any type of Device memory causes an Alignment fault.
The alignment requirements for accesses to Normal memory are as follows:
• For all instructions that load or store a single or multiple 
registers, other than Load-Exclusive/Store-Exclusive and 
Load-Acquire/Store-Release, if the address that is accessed is not
aligned to the size of the data element being accessed, then one of the 
following occurs:
— An Alignment fault is generated.
— An unaligned access is performed.

SCTLR_ELx.A at the current Exception level can be configured to enable 
an alignment check, and thereby determine which of these two options is 
used.
Note
— The SCTLR_EL1.A bit that is applicable to software running at EL0, can 
only be accessed from EL1
or above.
— Alignment checks are based on element size, not overall access size. 
This affects SIMD element and structure loads and stores, and also 
Load/Store pair instructions.
• For all Load-Exclusive/Store-Exclusive and Load-Acquire/Store-Release 
memory accesses that access a single element or a pair of elements, an 
alignment fault is generated if the address being accessed is not
aligned to the size of the data structure being accessed.
A failed alignment check results in an Alignment fault, which is taken 
as a Data Abort exception. These exceptions are taken at the lowest 
Exception level that can handle the exception, consistent with the basic 
requirement that the Exception level never decreases on an exception.

B2.4.3 Unaligned data access restrictions
• Accesses are not guaranteed to be single-copy atomic except at the 
byte access level.
• Unaligned accesses typically takes a number of additional cycles to 
complete compared to a naturally-aligned access.
• An operation that performs an unaligned access can abort on any memory 
access that it makes, and can abort on more than one access. This means 
that an unaligned access that occurs across a page boundary can
generate an abort on either side of the boundary.
</end quote>

The situation is not really as you describe it. Alignment still is 
important for many operations and can't be dismissed. That is why the 
compilers will always align the data at its natural boundaries.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web