[ On Thursday, September 30, 1999 at 16:38:28 (-0400), der Mouse wrote: ]
> Subject: Re: Bitfields and kernel
>
> But what you should be comparing to is
> 
> 	if ((msr & (POW_BIT|ILE_BIT)) == POW_BIT)
> 
> which reads msr only once (semantically significant if msr is volatile
> and possibly worth paying attention to as an optimization if it's a
> complicated expression).

Indeed!  :-)

Just as another data point from systems not using GCC (and perhaps
predates GCC?), consider this report by Thomas Plum and Jim Brodie in
their book "Efficient C" (Plum Hall, 1985):

    "There is no clear rule for whether the direct use of bit-fields or
    the use of the bitwise operators to simulate bit-fields is faster,
    but both techniques may be used to save data space.

    Whether the accessing of bit-fields is competitive with the
    accessing of normal integers is dependent primarily upon whether the
    hardware instruction set supports accessing and testing individual
    bit-fields.  Unless bit-field manipulation instructions are
    available on the target hardware it will not be worthwhile to use
    bit-fields for variables which to not appear in an array of
    structures or as part of a structure which appears multiple time
    (as in a node in a linked list or a binary tree).

    Our timing studies indicated that the testing and setting of single
    bits was somewhat faster with explicit bitwise operations than with
    bit-field operations.  We did not find any consistent differences in
    the extraction and setting of multi-bit bit-fields, as compared with
    explicit bitwise operations."

(Given other evidence in this book it would appear they did their tests
using Lattice C [8088 PC], Whitesmiths C [PDP-11/23], UNIX RCC
[SysV/68k], and UNIX RCC [SysV/VAX].)

> > It looks like there's no clear consensus :),
> 
> Sure does look that way.  Especially since some important aspects vary,
> it appears, from architecture to architecture.

Many of these aspects do not matter in cases where bit-fields are either
being used to conserve space in internal data structures, or to make
binary logic operations more natural to read without requiring use of
bit-fiddling C idioms.  "Premature optimisation...."  ;-)

Indeed bit-fields can still be used "portably" to access external data
(such as chip registers).  For example Harbison & Steele give examples
of how to do this properly in "C: A Reference Manual".  Indeed using
bit-fields for such purposes is no more difficult to do "portably" than
it is to use any other aspect of C structures to map external data.  One
simply has to be aware of how each given compiler and hardware target
works, and to use some form of conditional compilation to get the
declarations to match.  For kernel hacking this should be trivial -- for
applications it will be less so.  Plum and Brodie again (emphasis mine):

    Another *potential* problem with bit-fields is that there is no
    guarantee whether the bits will be allocated from right to left or
    from left to right within the word.  This problem would not have
    *any* effect when accessing fields using the standard references,
    but it could cause problems when trying to align bit-fields to
    correspond to a hardware layout (e.g., the control word for a
    port).  The documentation for your compiler should specify which
    direction it uses when allocating the bit-fields in a word.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>