Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #147185 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2019-10-24 08:03 +0200 |
| Last post | 2019-10-27 13:05 +0100 |
| Articles | 5 on this page of 65 — 15 participants |
Back to article view | Back to comp.lang.c
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 4 of 4 — ← Prev page 1 2 3 [4]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2019-10-27 08:42 -0500 |
| Message-ID | <5h7brepd21hr4059m7rc4hue0d3qk3ccer@4ax.com> |
| In reply to | #147261 |
On Sat, 26 Oct 2019 21:54:26 +0200, jacobnavia <jacob@jacob.remcomp.fr> 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. 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! My complaint was that you made an absolute statement (X is true in 64-bit systems), when only a conditional one was justified (X is usually true in 64-bit systems).
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2019-10-26 21:06 +0200 |
| Message-ID | <qp25es$o74$1@solani.org> |
| In reply to | #147255 |
Am 26.10.19 um 20:37 schrieb jacobnavia:
> 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...
Which, however, is a corner case: Large alignment, few bit-field members
in the struct.
However, I have to admit that it becomes important on the big systems
where one wants to optimize for cache usage. Often, one will want to do
some reordering of the members, so the bit-field members are all next to
each other.
The really small embedded systems (and retrogaming) tend to have small
alignment, typically 1 byte. There one might want to reorder to avoid
having bit-fields unnecessarily cross byte boundaries (in which case the
compiler sometimes will sacrifice a few bits and align to byte boundaries).
Philipp
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-26 20:41 +0100 |
| Message-ID | <dk1tF.1171418$R83.361813@fx23.am4> |
| In reply to | #147255 |
On 26/10/2019 19:37, jacobnavia 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...
This is the same issue in both structs, and is to do with C's default
struct-packing rules. Nothing to do with bitfields.
The smallest struct size on a 64-bit system can be obtained like this,
for a 9-byte total:
#pragma pack(1)
struct foo1 {
char *pData;
unsigned char field1:2;
unsigned char field2:3;
};
(Using char for the bitfields otherwise they will be allocated inside an
int on some compilers.)
However, when there are an array of such structs, then the pData element
can be badly aligned.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2019-10-27 08:29 +0100 |
| Message-ID | <qp3gvk$i0j$1@solani.org> |
| In reply to | #147260 |
But the standard does not yet require unsigned char to be a valid type for bitfields. Currently, only _Bool, int, signed int and unsigned int are supported. Philipp
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-27 13:05 +0100 |
| Message-ID | <qp416i$rr4$1@dont-email.me> |
| In reply to | #147277 |
On 27/10/2019 08:29, Philipp Klaus Krause wrote: > But the standard does not yet require unsigned char to be a valid type > for bitfields. Currently, only _Bool, int, signed int and unsigned int > are supported. > To be clear here, the C11 standard only /requires/ that the compiler supports bit-fields of type _Bool, signed int and unsigned int (with "int" being treated as either "signed int" or "unsigned int", depending on the compiler). But the standard also specifically allows other implementation-defined types for bit-fields. I have met some pre-C99 compilers that only supported signed and unsigned int, but never a post-C99 compiler that did not support signed and unsigned char, and signed and unsigned short.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web