Re: How to use bitfields?

J. J. Farrell wrote:
On Feb 18, 8:24 am, Radamanthe <tek...@xxxxxxxxxxxxxxxx> wrote:
cman wrote:

What are the advantages of using bitfields?
Memory usage, essentially, at the very lowest possible level. Note that
we could always do without bitfields anyway (by using bitwise operators
like & and |). It's just for readability that bitfields are used.

They are often used to provide an intuitive interface to an underlying
IO register or low-level structure. This way, you use the same semantic
to access values as any other type. Consider, as an example, a pixel
definition in some 16 bits ARGB format:

#include <stdio.h>
#include <stdint.h> // C99 uint16_t

struct ARGB1555 {
union {
uint16_t value;
struct {
unsigned int blue : 5;
unsigned int green : 5;
unsigned int red : 5;
unsigned int alpha : 1;
} comp;
} u;

};

int main(void)
{
struct ARGB1555 pixel;
pixel.u.comp.red = 20;
pixel.u.comp.green = 22;
pixel.u.comp.blue = 7;
pixel.u.comp.alpha = 1;
printf( "red: %d, green: %d, blue: %d, alpha: %d\n",
pixel.u.comp.red,
pixel.u.comp.green,
pixel.u.comp.blue,
pixel.u.comp.alpha );

return 0;

}

This is far more readable than this uggly equivalent machine dependant crap:

int main(void)
{
struct ARGB1555 pixel;
pixel.u.value = (1 << 15) | (20 << 10) | (22 << 5) | 7;
printf( "red: %d, green: %d, blue: %d, alpha: %d\n",
(pixel.u.value >> 10) & 0x1f,
(pixel.u.value >> 5) & 0x1f,
pixel.u.value & 0x1f,
(pixel.u.value >> 15) & 0x1 );

return 0;

}

Why do you describe the second version as "machine dependent crap"?

Because I was too lazy to write a more clean version, with mask and shift constants instead of hardcoded values (so it would have the same degree of portability than the bitfield version, at least).

The point was to demonstrate the readability of bitfields. I could have gone a lot further.

Your use of bitfields in the first example is entirely implementation
dependent, since very little about the layout of bitfields is defined
in C.

Of course it is implementation dependent ! This is all about low-level assumptions. But only THIS definition has to be changed, not the potential thousands lines of code using it everywhere else.

There is simply no way in C or any other language (maybe fragment shaders, but this is not as flexible as C) to make machine independant code for such things, as for many others. If you want speed (and believe me: you WANT speed when dealing with screen devices), this is the best & least you can do because anyway, you know that it will have to be ported to be efficient enough.

One compiler may lay them out from the most significant bit
down, another from the least significant up, for example. If you do
this with bitfields, you may need to re-implement your code for each
different compiler or target.

The bitfield definition code only. All the rest is unchanged and THAT is the point.

The second method, however, is implementation and machine independent
and entirely portable (in principle - I've not checked the details of
your example).

No, it isn't (like the bitfield version) when you're not alone in your C universe and you communicate with devices somewhere else millions of times per second. C is not only about dealing with databases used by C programs only. That would be so simple.

I don't use C because of its portability (though this is welcome), but because it is the only language that allow me to do pseudo-assembly low-level code very tied to the hardware in such a way that I don't have to rewrite everything for each target. In my pov, it is the greatest power of C and the main reason why I stick to it (or C++ eventually).

Code written in this way is portable between compilers
for the same target, and often across different targets.

Is this a debate around 99.98% versus 99.99% portability ? And what is a target for you ? A "C machine" ? I wish computers to be only "C machines", I would have far less problems, but halas, my output device would not be able to draw pixels anyway, and this example would certainly have no sense.



--
R.N.
.

Relevant Pages

  • Re: Variable declaration followed by colon?
    ... A couple of common examples where bitfields are used are device drivers, ... you're relying on bitfields every time you send an IP packet! ... Here's the IP header struct that's used in every packet: ... unsigned int version:4; ...
    (comp.lang.c)
  • Re: How to use bitfields?
    ... difference with other integer types beside their bit size. ... It's just for readability that bitfields are used. ... struct ARGB1555 { ... unsigned int green: 5; ...
    (comp.lang.c)
  • Re: When shorts are longer than longs !
    ... the bitfields have such annoyances (especially ... unsigned int BitsInUnsignedInt ... unsigned int BaseBit) ...
    (comp.lang.c)
  • Re: Checking endianess in compile time
    ... Bitfields *ARE* regarded properly by the compiler. ... > unsigned int tffca: 1; ... tells you the endianness. ...
    (comp.lang.c)
  • Re: How to use bitfields?
    ... It's just for readability that bitfields are used. ... struct ARGB1555 { ... unsigned int green: 5; ... for the same target, ...
    (comp.lang.c)