[ILUG] bitfields

[Caolan McNamara]

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 11.05.00, 00:05:34, Paul Jakma <paul at clubi.ie> wrote regarding RE: 
[ILUG] gcc optimisation weirdness?:
> On Wed, 10 May 2000, Caolan McNamara wrote:
>   You can create a variable that refers to a unit whose size can be
>   specified in bits. (and before people go mad using the damn things, the
>   bitfields are collated together to form integral units (possible bytes,
>   probably 32bit ints) and they are as slow as molasses)

> why slow?

Slow in comparison to a real integral type. Setting or accessing an 
integral type can map to a single operand
int i=3;
becoming a single mov operation while
i=3; where i is an int i:3; member of a struct ends up being a mass of 
bitmasks with and & or operations. The processor is only dealing with 
integral units itself so bit masks and operations have dance around to 
get the desired effect. Take a look at the output from gcc -S to see what 
I mean.

> (eg if i had a lot of flags, and low-ranged integers, eg status
> codes.. wouldn't i be much better off using bitfields to pack them
> into a single 32 bit word? rather than having seperate variables,
> where most of the space isn't used?)

> what about 64bit machines? where you might waste even more space with
> the standard variable sizes?

That would be a judgement call, I wouldn't do it. There are a limited  
set of circumstances where such spacesaving will actually make any 
difference in comparison to the amounts of data generally being moved 
around. The only place I use bitfields is to interface with something 
that is already playing such games. The word spec for instance is a good 
example of a data format which does that, and theres certainly loads of 
hardware which sets individual bits and bit ranges which are easier 
handled with bitfields rather than explicit shifting and masking 
yourself.

Someone else said that bitfields are not standard, there are indeed 
ANSI-C 
Though ansi allows only int, unsigned int, or signed int type. So 
technically no char i:3; or long i:3;

C.