Recent Features
| |||||||||||||
Knock me over with a featherKnock me over with a featherPosted Feb 2, 2012 5:43 UTC (Thu) by ncm (subscriber, #165)Parent article: Betrayed by a bitfield
I'm astonished that Linus has a problem with this. Everybody knows that C bitfields can never be counted on to work right. Even when one seems to, that's bad luck because it just hasn't failed *yet*. A one-bit bitfield? Next to a lock type defined as 32 bits on an almost militantly 64-bit machine? Why did he allow such cursed, doomed, jinxed code into his kernel in the first place?
My bet is that he knows the code is bad, but is covering his embarrassment by haranguing the Gcc developers, on the (sound!) general principle that they always deserve abuse, regardless of the immediate facts. Gcc developers are the candles whose unsteadiness we blame for causing us to stumble in the darkness.
(Log in to post comments)
Knock me over with a feather Posted Feb 2, 2012 20:05 UTC (Thu) by dashesy (subscriber, #74652) [Link]
Can someone please explain, what could be the advantage of a "one-bit bitfield" over an integer here?
Knock me over with a feather Posted Feb 2, 2012 20:46 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Maybe they're planning to have several flags in future?
Knock me over with a feather Posted Feb 2, 2012 21:57 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the thing is, this compiler bug would break that too.
Knock me over with a feather Posted Feb 3, 2012 6:50 UTC (Fri) by ncm (subscriber, #165) [Link]
Yes, the real bug was the 32-bit lock word. The bitfield was just to tempt fate.
Knock me over with a feather Posted Feb 3, 2012 22:58 UTC (Fri) by cavok (subscriber, #33216) [Link]
bitfields in a mostly 32/64 bit aligned world...
how many millions of those structures do you need to see some gain in using bitfields?
Knock me over with a feather Posted Feb 3, 2012 23:02 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
not very many.
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.
Knock me over with a feather Posted Feb 6, 2012 13:32 UTC (Mon) by cavok (subscriber, #33216) [Link]
got it. thank you.
Knock me over with a feather Posted Feb 6, 2012 12:22 UTC (Mon) by etienne (subscriber, #25256) [Link]
You can gain a lot of code space using related bits declared in a bitfield structure, because the compiler can do a single mask (to hide irrelevant bits) and a single test of a 32 bits value to decide something.
For instance, a bitfield structure describing the debugging/logging of messages where bits are enable_global, enable_subsystem1, enable_onserial, telnet_connected, and the test is "if (debug.enable_global && (debug.enable_onserial || debug.telnet_connected) && debug.enable_subsystem5)". If you do not do that, on processors with one single "flag" register, the only way for the compiler is to do multiple test and jump and storing intermediate bit into 32 or 64 bits registers (compilers do not do well sub-register allocation by themself). You could also use the preprocessor with "#define enable_global 0x80000", but I prefer writing in C/C++ than in CPP...
|
|||||||||||||