3 ms·

Eh, that use of a bitfield is asking for it. What could you possibly gain from using a single bitfield in the entire struct? I also thought it was well known t

Eh, that use of a bitfield is asking for it. What could you possibly gain from using a single bitfield in the entire struct? I also thought it was well known that using bitfields you are just pushing the burden of generating the bit shifting code on the compiler, and that implies accessing other fields. I don't think there is a processor out there that has single bit writes for general purpose memory (some do for config registers).

mschuster91 10y ago
> Eh, that use of a bitfield is asking for it. What could you possibly gain from using a single bitfield in the entire struct? A (buried way down) comment explains this: > if you can even replace two int variables with one bitfield, you may shrink your datastructure enough to have it fit within a CPU cache line. The memory access that can then be avoided can be enough to make a noticeable difference. https://lwn.net/Articles/479402/ https://lwn.net/Articles/479402/
- mikeash 10y ago
  Right, but there's only one here. Is it just an attempt to future proof in case they add a second?
  - arcticbull 10y ago
    Likely their standard practice so the addition of a second field is immaterial. Does look funky though.
- CamperBob2 10y ago
  if you can even replace two int variables with one bitfield, you may shrink your datastructure enough to have it fit within a CPU cache line. But the way you should do that is by declaring an integer variable of the exact size you anticipate requiring to store your bits, and set/clear/test those bits explicitly with Boolean operators. C bitfield semantics have always been far too hand-wavy to use for anything important. This is a perfect example (not that a separate variable will necessarily save you from a compiler stupid enough to write to adjacent structure members for no reason).
ambrop7 10y ago
I think the very reasonable expectation is that you can only have issues with respect to accessing different parts of adjacent bitfield members, since in those cases the compiler generally really needs to access other members of the structure.

mschuster91 10y ago

> Eh, that use of a bitfield is asking for it. What could you possibly gain from using a single bitfield in the entire struct? A (buried way down) comment explains this: > if you can even replace two int variables with one bitfield, you may shrink your datastructure enough to have it fit within a CPU cache line. The memory access that can then be avoided can be enough to make a noticeable difference. https://lwn.net/Articles/479402/ https://lwn.net/Articles/479402/

mikeash 10y ago
Right, but there's only one here. Is it just an attempt to future proof in case they add a second?
- arcticbull 10y ago
  Likely their standard practice so the addition of a second field is immaterial. Does look funky though.
CamperBob2 10y ago
if you can even replace two int variables with one bitfield, you may shrink your datastructure enough to have it fit within a CPU cache line. But the way you should do that is by declaring an integer variable of the exact size you anticipate requiring to store your bits, and set/clear/test those bits explicitly with Boolean operators. C bitfield semantics have always been far too hand-wavy to use for anything important. This is a perfect example (not that a separate variable will necessarily save you from a compiler stupid enough to write to adjacent structure members for no reason).

ambrop7 10y ago

I think the very reasonable expectation is that you can only have issues with respect to accessing different parts of adjacent bitfield members, since in those cases the compiler generally really needs to access other members of the structure.