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 1 of 4  [1] 2 3 4  Next page →

#147185 — Bit field usage

Suppose this structure:

struct data {
	// Some flags
	unsigned isOld:1;
	unsigned writtenAlready:1;
	unsigned discarded:1;
	double *table;
};

Contrary to what many beginners would believe, in a 64 bit architecture 
the above structure and the structure below have the same size.

struct data1 {
     // Some flags
     unsigned char isOld;
     unsigned char writtenAlready;
     unsigned char discarded;
     double *table;
};

The 3 bits of the "data" structure are followed by a pointer that is 
aligned to a 64 bit boundary! The following program shows this in practice:

struct data {
     // Some flags
     unsigned isOld:1;
     unsigned writtenAlready:1;
     unsigned discarded:1;
     double *table;
};
struct data1 {
     // Some flags
     unsigned char isOld;
     unsigned char writtenAlready;
     unsigned char discarded;
     double *table;
};
#include <stdio.h>
int main(void)
{
     printf("%Lu %Lu\n",sizeof(struct data),sizeof(struct data1));
}

Output:
16 16

This could be considered as unimportant, and in most cases it is. In 
some situations of heavy use of bitfields however, they have two drawbacks:

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.

jacob

[toc] | [next] | [standalone]

#147195

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.

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

#147196

Le 24/10/2019 à 18:15, Joe Pfeiffer a écrit :
> I got burned badly enough by bitfields doing unexpected things decades
> ago that I abandoned them and do my own shifts and masks.

Sure, but that way you have the worst of all worlds:
1) You have to write, test and debug the shifts
2) Your code is bigger
3) Your execution time goes up

What about using an unsigned char for storing that data?

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

#147223

jacobnavia <jacob@jacob.remcomp.fr> writes:

> Le 24/10/2019 à 18:15, Joe Pfeiffer a écrit :
>> I got burned badly enough by bitfields doing unexpected things decades
>> ago that I abandoned them and do my own shifts and masks.
>
> Sure, but that way you have the worst of all worlds:
> 1) You have to write, test and debug the shifts
> 2) Your code is bigger
> 3) Your execution time goes up
>
> What about using an unsigned char for storing that data?

Depends on how many bits I need to control and how big the data
structure is.  If it's just a couple of booleans, sure, that's what I'll
do.

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

#147197

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.

Not necessarily,  ARM, for example, has both bitfield extract and
bitfield insert instructions.

>>
>> 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.

Used correctly, they work well and allow the compiler to generate optimal
code, IMO.   Portability between big and little endian hosts can be accomodated
with appropriate preprocessor statements.   Also aids in code readability and
maintainability.

e.g.
typedef union
{
    uint64_t u;
    struct
    {
#if __BYTE_ORDER == __BIG_ENDIAN
        uint64_t reserved_20_63 : 44;
        uint64_t countsize : 4;
        uint64_t maxsize : 4;
        uint64_t interval : 4;
        uint64_t reserved_6_7 : 2;
        uint64_t ernd : 1;
        uint64_t lds : 1;
        uint64_t archinst : 1;
        uint64_t fl : 1;
        uint64_t ft : 1;
        uint64_t fe : 1;
#else
        uint64_t fe : 1;
        uint64_t ft : 1;
        uint64_t fl : 1;
        uint64_t archinst : 1;
        uint64_t lds : 1;
        uint64_t ernd : 1;
        uint64_t reserved_6_7 : 2;
        uint64_t interval : 4;
        uint64_t maxsize : 4;
        uint64_t countsize : 4;
        uint64_t reserved_20_63 : 44;
#endif
    } s;
} arm_reg_pmsidr_el1_t;

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

#147200

> #if __BYTE_ORDER == __BIG_ENDIAN
>          uint64_t reserved_20_63 : 44;
...
> #else
...
>          uint64_t reserved_20_63 : 44;
> #endif

Doesn't work since this 44 bits have opposite byte-ordering.

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

#147202

Le 24/10/2019 à 19:45, Bonita Montero a écrit :
>> #if __BYTE_ORDER == __BIG_ENDIAN
>>          uint64_t reserved_20_63 : 44;
> ...
>> #else
> ...
>>          uint64_t reserved_20_63 : 44;
>> #endif
> 
> Doesn't work since this 44 bits have opposite byte-ordering.
> 

I do not see what are you answering to. Maybe an explanation is 
necessary? Who are you answering to?

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

#147204

>>> #if __BYTE_ORDER == __BIG_ENDIAN
>>>          uint64_t reserved_20_63 : 44;
>> ...
>>> #else
>> ...
>>>          uint64_t reserved_20_63 : 44;
>>> #endif

>> Doesn't work since this 44 bits have opposite byte-ordering.

> I do not see what are you answering to. Maybe an explanation
> is necessary? Who are you answering to?

You can see it from the threading. ;-)

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

#147224

Bonita Montero <Bonita.Montero@gmail.com> writes:

>>>> #if __BYTE_ORDER == __BIG_ENDIAN
>>>>          uint64_t reserved_20_63 : 44;
>>> ...
>>>> #else
>>> ...
>>>>          uint64_t reserved_20_63 : 44;
>>>> #endif
>
>>> Doesn't work since this 44 bits have opposite byte-ordering.
>
>> I do not see what are you answering to. Maybe an explanation
>> is necessary? Who are you answering to?
>
> You can see it from the threading. ;-)

Apparently not.

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

#147225

>> You can see it from the threading. ;-)

> Apparently not.

Then use something more convenient like Thunderbird.

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

#147229

Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> You can see it from the threading. ;-)
>
>> Apparently not.
>
>Then use something more convenient like Thunderbird.
>

Instead of being a prick, stop deleting the attributions.

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

#147205

On 24/10/2019 18:45, Bonita Montero wrote:
>> #if __BYTE_ORDER == __BIG_ENDIAN
>>          uint64_t reserved_20_63 : 44;
> ...
>> #else
> ...
>>          uint64_t reserved_20_63 : 44;
>> #endif
> 
> Doesn't work since this 44 bits have opposite byte-ordering.
> 

I saw that, but thought maybe the bit-numbering was reversed too, so 
that bit 63 is the least significant.

But if so that would be wrong, since bit-numbering should be independent 
of memory layout. Bit 0 is generally the least significant.

This kind of reinforces the OP's point that you never know exactly how 
bit fields are going to be implemented.

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

#147207

> 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.

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

#147209

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.

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

#147215

On 24/10/2019 21:12, Bart wrote:
> 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.
> 

It is /generally/ accepted, yes.  But there are exceptions (not here, 
though).  In PowerPC (which is primarily big-endian, but some devices 
support little-endian mode too) documentation, "bit 0" is the most 
significant bit.  This leads to some "interesting" numbering.  Since the 
PPC supports 64-bit architecture, "bit 0" means 2**63.  Thus when you 
have a 32-bit PPC device, each 32-bit general purpose register has bits 
numbered from "bit 32" down to "bit 63" (the ones).  However, the 
external address bus was originally only 32-bit wide - thus "bit 0" 
corresponds to the 2**31 address bit.  When devices were made that 
supported more than 4 GB of memory, the extra address lines were 
therefore labelled "bit -1", "bit -2", etc.

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.

> This /must/ be independent of its layout when store in memory.

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

#147218

David Brown <david.brown@hesbynett.no> writes:

> On 24/10/2019 21:12, Bart wrote:
<cut>
>> 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.
>
> It is /generally/ accepted, yes.  But there are exceptions (not here,
> though).  In PowerPC (which is primarily big-endian, but some devices
> support little-endian mode too) documentation, "bit 0" is the most
> significant bit.

That numbering is a long-standing IBM tradition.

<cut>
-- 
Ben.

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

#147226

On 24/10/2019 23:50, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 24/10/2019 21:12, Bart wrote:
> <cut>
>>> 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.
>>
>> It is /generally/ accepted, yes.  But there are exceptions (not here,
>> though).  In PowerPC (which is primarily big-endian, but some devices
>> support little-endian mode too) documentation, "bit 0" is the most
>> significant bit.
> 
> That numbering is a long-standing IBM tradition.
> 

I only met it when working with PPC microcontrollers, but I assumed it
was a tradition that came from the Power processors, following older
habits from their earliest mainframes.  It certainly has to have
originated a very long time ago, since (to my knowledge) everyone else
standardised on "bit x is 2**x" many decades ago.

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

#147227

On 10/25/19 3:18 PM, David Brown wrote:
> On 24/10/2019 23:50, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 24/10/2019 21:12, Bart wrote:
>> <cut>
>>>> 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.
>>>
>>> It is /generally/ accepted, yes.  But there are exceptions (not here,
>>> though).  In PowerPC (which is primarily big-endian, but some devices
>>> support little-endian mode too) documentation, "bit 0" is the most
>>> significant bit.
>>
>> That numbering is a long-standing IBM tradition.
>>
> 
> I only met it when working with PPC microcontrollers, but I assumed it
> was a tradition that came from the Power processors, following older
> habits from their earliest mainframes.  It certainly has to have
> originated a very long time ago, since (to my knowledge) everyone else
> standardised on "bit x is 2**x" many decades ago.

I remember TI did this too with their 99xx CPUs.

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

#147248

On Fri, 25 Oct 2019 09:18:04 +0200, David Brown
<david.brown@hesbynett.no> wrote:

>On 24/10/2019 23:50, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> 
>>> On 24/10/2019 21:12, Bart wrote:
>> <cut>
>>>> 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.
>>>
>>> It is /generally/ accepted, yes.  But there are exceptions (not here,
>>> though).  In PowerPC (which is primarily big-endian, but some devices
>>> support little-endian mode too) documentation, "bit 0" is the most
>>> significant bit.
>> 
>> That numbering is a long-standing IBM tradition.
>> 
>
>I only met it when working with PPC microcontrollers, but I assumed it
>was a tradition that came from the Power processors, following older
>habits from their earliest mainframes.  It certainly has to have
>originated a very long time ago, since (to my knowledge) everyone else
>standardised on "bit x is 2**x" many decades ago.


Indeed, it predates S/360.  You can find that ordering convention in
many of the 7xxx references, for example.  Page 7 of the 7090
reference, for example:

http://www.bitsavers.org/pdf/ibm/7090/22-6528-4_7090Manual.pdf

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

#147228

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").

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web