Messages in this thread | | | From | (Amy Rupp) | Subject | bit-wise vs. conditional or (kernel bugs found using inspect) | Date | Thu, 24 Feb 2000 09:04:36 -0600 (CST) |
| |
Not every architecture's predictive branching works in the same way (not every architecture even HAS predictive branching). The compiler doesn't emit identical instructions for every architecture since by definition they don't have the same instruction set.
If a bit-wise operation is performed on anything but a bit-field type (eg :1), one risks a future editor adding additional values for the variable to take on. The fact that a bit-wise or is equivalent to ? 1 : 0 ONLY HOLDS if the variable can only be assigned the value of 1 or 0. Without a strictly enforced boolean type, or, even better, a bitfield definition, you can set any data type to a value that's not 0 or 1.
If this bit-wise construction MUST be there for performance, it ought to be commented as such. Even then, the risk that someone will replace it with a conditional-or, or, as mentioned, add a new value to the accepted values of that variable, is quite high.
Bit-wise operations ought to be performed on bit fields where each bit represents a binary true/false condition in the bit field, NOT on integer values. For example, if the value assigned is 3, (binary 11) then there should be a complementary value of 0 (binary 00) that is not a distinct unique condition, nor simply "false", but rather the boolean opposite of 3.
Maximum portability is as important a goal as performance, and equality in performance across architectures (as near as possible) would also be nice. If the code truly needs changing to take advantage of non-C underlying features (eg branch prediction) then that code should be moved to the architecture-specific portion of the kernel, or if accepted, an assembler macro inlined into the C code and #defined by architecture type.
--Amy
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |