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/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:10 EST