Except for those architectures that both have and use special instructions
for bit manipulation (the VAX comes to mind) there is a huge risk in using
bit fields for representing hardware registers. 

Specifically when the compiler generates a read/mask/write operation it in
fact reads and writes all bits of a register rather than just the bit in
question and that can cause weird things to happen. 

For non-hardware issues, using bit fields can be slower than just using
#defines since the statement:

	if (something->dirty_bit) ...

On a piece of hardware that doesn't support bit instructions might result
in code that does something like:
	LOAD	__something+offset
	ANDI	__bitmask_for_dirty_bit
	SHRL	__bit position
	BNE	L10

versus the statement:
	if (something->flags & DIRTY_BIT) ...

would generate code more like
	LOAD	__something+offset
	ANDI	DIRTY_BIT
	BNE

A classic case where using bitfields slows down code is something like the
page table manipulation on a RISC processor.

When you have bit instructions though they can be a win...
--Chuck

At 02:09 PM 9/28/99 -0500, Brian C. Grayson wrote:
>  Is there any inherent reason why using bitfields in the kernel
>would be evil?  For example, for some PPC stuff, I'd rather have code
>like (off-the-top-of-my-head, so forgive semantic goof-ups):
>
>typedef struct {
>  unsigned int reserved0_12:13;
>  unsigned int pow:1;
>  unsigned int reserved14:1;
>  unsigned int ile:1;
>  ...
>} reg_msr_t;
>
>...
>reg_msr_t msr;
>...
>msr.pow = 1;
>msr.ile = 0;
>
>  Currently, these are done with #define's.  I see that some
>archs use bitfields for FP and page-table stuff, so there's at
>least some precedence for it.
>
>  IMHO, using bitfields is easier to maintain and understand, and
>less prone to errors.  However, I don't know if there are
>portability problems with it.  Someone at work claims that not
>all compilers do bitfields all that well, but it looks like gcc
>does.  But gcc isn't the only compiler we care about.
>
>  TIA.
>
>  Brian