Writing Data to Bit Field

[Richard G. Riley]

Do you need bitfields? The struct is padded to a 4-byte object on my
platform. There must be any number of ways to do the job more efficiently
(if that matters) in no more space using a char or 2 chars

Bitfields would frequently be used to map an OS specific return or a
HW interface. Could someone state if the standard guarentees optimal
bit "compression" e.g no padding between fields?

 

[CBFalconer]

Ok, I never have quoted before...


Yes, that is also what my compiler says...


It would be the fastest way to initialize the bits, wouldn't it?

Congratulations on rapidly learning how to use google. Now the
next thing to learn is on the subject of optimization. The mantra
is: don't. Write for clarity first. Before even considering
optimization measure the performance, and also measure the
performance of the sections you are thinking of optimizing. You
will rarely find that optimization is worthwhile or even useful.
In general the compiler is better at optimization than you are, so
you should limit your trials to using whatever optimization
switches the compiler provides. Gcc provides a variety of
optimization switches, and also means of profiling and measuring
performance. What those are is off-topic here.

Algorithmic improvement is another matter, and will often pay off
heavily.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Keith Thompson]

You were right, it must have been unsigned int Bit2 : 1;

Please read <http://cfaj.freeshell.org/google/>.

 

[Keith Thompson]

You should also know the first rule of optimisation:

1. Don't do it.

Compilers are generally better at it. Second rule is useful as well:

2. Don't do it yet.

I think Rule 2 is usually quoted as:

2. Don't do it yet (experts only).

 

[Keith Thompson]

memset will be not inlined. That means, by example, that a simple
becames a call to procedure + stack allocation + loop + stack
deallocation + return.

You don't know that. Since memset() is in the standard library, the
compiler is entitled to assume that it behaves as the standard
specifies, and do whatever it can do to achieve the same results.

For example, given:
int n;
memset(&n, 0, sizeof n);
the compiler could legally generate code equivalent to
int n = 0;

But memset() is very unlikely to be the best solution for the OP's
problem. If you want two bit fields to have the value 1, assign the
value 1 to both of them:
MyField.bit1 = 1;
MyField.bit2 = 1;
or:
MyField.bit1 = MyField.bit2 = 1;

If this turns out to be a significant bottleneck in the performance of
your program (because you *measured* it), you can consider other
approaches. A union might be one possible solution, but the layout of
bit fields is implementation-defined (or is it unspecified?).

There's no virtue in getting wrong answers very quickly.

 

[Zero]

Zero, please don't do any of these things. Just spell out exactly what
you're doing.

I have realized that memset cannot be used for bitfield as it is only
limited to say chars.
I use the bitfield for a statemachine and at the beginning I have to
initialize some bits. I have wondered if there is a way to initialize
the whole struct, so when assigning 3 to the structure which does not
work obviously, I know that Bit1 and Bit2 are TRUE == HIGH == 1.

 

[Vladimir S. Oka]

I have realized that memset cannot be used for bitfield as it is only
limited to say chars.
I use the bitfield for a statemachine and at the beginning I have to
initialize some bits. I have wondered if there is a way to initialize
the whole struct, so when assigning 3 to the structure which does not
work obviously, I know that Bit1 and Bit2 are TRUE == HIGH == 1.

Well, you can initialise a structure with another structure. See one of
my previous posts.

I'd also like to add to the commendations you already received for
picking up the c.l.c house rules in no time at all. Thank you! It's a
pleasant change.

 

[Ben Bacarisse]

You don't know that. Since memset() is in the standard library, the
compiler is entitled to assume that it behaves as the standard specifies,
and do whatever it can do to achieve the same results.

For example, given:
int n;
memset(&n, 0, sizeof n);
the compiler could legally generate code equivalent to
int n = 0;

That's interesting. Does this mean that one cannot re-define standard
functions like memset? If one can, then presumably a conforming compiler
that does this is allowed to play tricks with translation units that I
thought were not possible.

 

[Richard Bos]

That's interesting. Does this mean that one cannot re-define standard
functions like memset?

Not portably, no. Nor any other Standard function.

If one can, then presumably a conforming compiler that does this is allowed
to play tricks with translation units that I thought were not possible.

Declaring any of the identifiers used by the Standard, or any of those
reserved for it (e.g., strfoo), invokes undefined behaviour, IIAMN. Of
course, a common way to handle this UB is to allow it, but a portable
program cannot rely on this.

(One trick that you _can_ use, because it does not change anything in
the way the implementation works, is to re-#define memset to my_memset -
provided you do so _after_ you've #included any implementation header
which might use it.)

Richard

 

[Ben Bacarisse]

Declaring any of the identifiers used by the Standard, or any of those
reserved for it (e.g., strfoo), invokes undefined behaviour, IIAMN. Of
course, a common way to handle this UB is to allow it, but a portable
program cannot rely on this.

Ah, thank you. I did look in the standard before asking but I did not
find the answer (I hope it is not in the FAQ!).

(One trick that you _can_ use, because it does not change anything in
the way the implementation works, is to re-#define memset to my_memset -
provided you do so _after_ you've #included any implementation header
which might use it.)

I've used this method myself when I needed this behaviour (debugging a
library) because it is more self-documenting and far less error-prone than
just linking with a different version of the function, but I did not know
that one had to use it!

 

[Flash Gordon]

Doesn't worry me too much since if I'm interested in a thread then it
can easily be tagged or reconstructed at will despite being an online
newsreader.

So tell me, how do you reconstruct it if the message it is a reply to
has reached neither Google nor your news server? This *does* happen in
the real world as I know through experience.

Personally I hate people constantly including the entire

previous post

That is why people should also snip what they are not responding to.

Maybe. What About using a Union? BTW its horrible

I agree that it is horrible. Especially as the bit fields could be in
either ascending or descending order so you don't know which part of the
other field in the union they will correspond to.

> : address the fields
seperately and let the compiler take care of optimizations unless
there really is a need to write data to a word at exactly the same time.

Agreed. Even when there is need to write all the bits at the same time
(e.g. accessing a HW register) there are better ways to do it, mainly by
building the word you want to write in advance then writing it.

 

[Flash Gordon]

Richard G. Riley wrote:

Bitfields would frequently be used to map an OS specific return or a
HW interface. Could someone state if the standard guarentees optimal
bit "compression" e.g no padding between fields?

No. You should therefore only use the method when your system specific
documentation says that it is the right thing to do. In such cases a
system specific header will generally provide you with the required
definitions so you can ignore the fact that bit fields are being used
and treat it as a normal struct.

Note also that the ordering of bit fields might (I haven't checked) be
different in gcc under Linux for the PPC and x86.