Bitfields

[KansaiRobot]

Hello.
I am currently updating a project that uses bitfields heavily. To do this I am planning to use these as well. My question is if the following is correct, appropriate or a good idea:


first a field in the bitfield:

struct {
WORD somefield:1;
WORD otherfield :1;


WORD MYFIELD:2; // The 2-bit field I am going to use


} somebitfield;

Yeah, I know the standard recommends only use unsigned ints for that, but for some reason the project uses a user defined WORD.


Ok, so I have a 2-bit field so I guess it means this can assume 4 values right?


So I define something like

 enum { NOTHING=0, STATEONE, STATETWO,STATETHREE} myenum;

So, my question is , can I safely do something like

if(somebitfield.MYFIELD==NOTHING) {


}
elseif (somebitfield.MYFIELD==STATETWO){


}

or even

switch(somebitfield.MYFIELD)
  {
   case NOTHING:   


  case STATEONE:


}

any advice will be greatly appreciated


Thanks


Kansai

 

[The J]

Yup, that should work as the compiler should set up the necessary masks and shifts for you. At least, that's been my experience with the compiler I work with (Microchip C30 and C32, which are based on GCC).

 

[degibson]

Careful of concurrency, but yes, the above will work.

 

[KansaiRobot]

thanks for the replies.
I already implemented the solution and it works great. I was just a little aprehensive about bitfields and enums since I seldom use them.

(We are taking care of concurrency by deactivating interrupts in atomic operations and activating them again later.. at least that is what the code does)


BY THE WAY, talking about bit fields. The standard recommends to use only unsigned ints. However my legacy code uses WORD and sometimes BYTE (another user defined type)

Since bit fields are just that: bits, I always wonder what for are these types? I mean for example:

struct{
        unsigned int field1:1;
        unsigned int field2:2;
       ...

field1 is just one bit, and field2 just two bits. Then why put the "int" there???

Any idea?

 

[degibson]

The underlying machine is incapable of single-bit operations. The compiler emulates them by performing full-uint loads, shifts, masks, and then full-uint stores. 'unsigned int' is the underlying access size.

Edit: This means the entire unsigned int is actually there, but only those two bits in the uint ever appear to change.

 

[Markbnj]

The underlying machine is incapable of single-bit operations. The compiler emulates them by performing full-uint loads, shifts, masks, and then full-uint stores. 'unsigned int' is the underlying access size.

Edit: This means the entire unsigned int is actually there, but only those two bits in the uint ever appear to change.

Interesting. I always thought it packed the bits into a single scalar value.