regarding bit fields

[sam_cit]

Hi Everyone,

We all know that bit fields are to be used within a structure, like

struct sample
{
int i:4;
}

However, is there any reason as to why it can only be specified only
within a structure or a union and why not standalone as,

int i:4;

 

[Chris Torek]

We all know that bit fields are to be used within a structure, like

struct sample
{
int i:4;
}

However, is there any reason as to why it can only be specified only
within a structure or a union and why not standalone as,

int i:4;

"Because Dennis said so", more or less.

(In other words, there is no fundamental reason bitfields could not
be applied to ordinary variables. Note, however, that there is no
"pointer to bitfield" type in C, so there *is* a fundamental reason
they could not be applied to arrays, at least not without first
adding "pointer to bitfield" types.)

Dennis Ritchie also once said that C's bitfields are "a botch and
a blemish". I have to agree: they are not supported "correctly"
at a high level (no arrays of bitfields, no pointers to bitfields,
and so on), and at the same time, they do not map usefully to
hardware or protocol needs (no control over underlying machine
representations, cannot span machine words, and so on). In other
words, their sole function is to specify representation -- in
this case, "number of bits in machine storage" -- yet they fail
to let you specify the representation *enough*.

 

[Jack Klein]

"Because Dennis said so", more or less.

(In other words, there is no fundamental reason bitfields could not
be applied to ordinary variables. Note, however, that there is no
"pointer to bitfield" type in C, so there *is* a fundamental reason
they could not be applied to arrays, at least not without first
adding "pointer to bitfield" types.)

Dennis Ritchie also once said that C's bitfields are "a botch and
a blemish". I have to agree: they are not supported "correctly"
at a high level (no arrays of bitfields, no pointers to bitfields,
and so on), and at the same time,

Up to here, I agree with you...

they do not map usefully to
hardware or protocol needs (no control over underlying machine
representations, cannot span machine words, and so on). In other
words, their sole function is to specify representation -- in
this case, "number of bits in machine storage" -- yet they fail
to let you specify the representation *enough*.

....but I disagree with this last point. It may be true enough in
general, but there are specific implementations where it is done well
and extremely useful.

This is the case in many embedded microcontroller/DSP implementations
that I have used. It is quite common for the silicon vendor to supply
extensive header files defining all of the on-chip memory mapped
peripherals with unions overlaying bit fields and unsigned integer
types.

Of course, they make sure the bit ordering and other features of their
definitions compile properly with their compiler. They would not
necessarily be portable to any other compiler, but then neither would
the hardware peripherals they address.

So this may be a portability issue, especially on desktops and work
stations, but can be and is used well, despite its limitations, on
many embedded platforms.

 

[David T. Ashley]

Up to here, I agree with you...


...but I disagree with this last point. It may be true enough in
general, but there are specific implementations where it is done well
and extremely useful.

This is the case in many embedded microcontroller/DSP implementations
that I have used. It is quite common for the silicon vendor to supply
extensive header files defining all of the on-chip memory mapped
peripherals with unions overlaying bit fields and unsigned integer
types.

Of course, they make sure the bit ordering and other features of their
definitions compile properly with their compiler. They would not
necessarily be portable to any other compiler, but then neither would
the hardware peripherals they address.

Actually, it seems in your last paragraph that you are agreeing with Chris.

Of course, they make sure the bit ordering and other features of their
definitions compile properly with their compiler. They would not
necessarily be portable to any other compiler ...

But they _would_ be portable to any other compiler, if they:

There is definite room for improvement with 'C'. Not only is there the
portability issue, but there is a learning and training cost. I've worked
with compilers that pack bitfields MSB first and LSB first, and when I look
at memory dumps and so on I need to refamiliarize myself with how the
compiler packs each time ... it would be easier if they all packed the same
way.

And I also wish there were a way to give the compiler _MORE_ freedom in what
it did in some cases. When one has bitfields that are being used for
compact storage only (and not for ill-advised type conversions and so on),
one should be able to tell the compiler to rearrange fields as it pleases.
Two examples come to mind:

a)A processor I've used in the past had a neat instruction for swapping
nibbles of a byte. The compiler did a really good job if one just happened
to place a bitfield of size 4 as the upper nibble ... the compiler should
have the freedom in some cases for force this alignment by rearranging
bitfields.

b)In general, shifting and masking to extract bitfields is an expensive
operation (for embedded systems). The compiler should have the freedom in
some cases to align frequently-used bitfields against the LSB to eliminate
the shifting.

The *enough* is a problem. One should be able to give the compiler less
freedom in some cases and more freedom in others.