C question

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi everyone

I am trying to get to terms with programming in C now.

What does the following mean?
I understand that it is a structure called dat_bits but ...
1) what does the 8 and the 24 mean?
2) why is there no name declared in line 3?

1: typedef struct {
2:    _REG32 DATA    : 8;
3:    _REG32                :24;
4:} dat_bits;


Thanx :)
Xarion



Re: C question
Quoted text here. Click to load it

Those are called "bitfields". They mean that the first field occupies 8
bits, and the second 24. You can use an arbitrary number of bits with this
syntax.


Re: C question
As already answered by someone else, you have found an
example of bit fields. The reason no field name exists
on line 3 is because it is just padding.

Do not use bit fields in C. From page 150 of the second
edition of Kernighan and Ritchie, "The C Programming
Language", ISBN 0131103628:

"[..]
    Almost everything about fields is implementation-dependent.
Whether a field may overlap a word boundary is
implementation-defined. [..]
    Fields are assigned left to right on some machines and
right to left on others. [..]"

Use bitwise operators instead of bit fields if you want to use
C, if you would like to use notation like bit fields' then
consider programming in Ada ( news:comp.lang.ada ) and taking
advantage of its representation clauses (please see the bottom
of WWW.AdaIC.org/standards/95lrm/html/RM-13-5-1.html for an
example).

Re: C question

Quoted text here. Click to load it

If you're program is supposed to be portable, I would agree.
Much of what one writes in an embedded program has no hope
whatsoever of being portable, so bitfields have their place.

Quoted text here. Click to load it

So.  That's what embedded programming is about.

Quoted text here. Click to load it

Some compilers generate better code for bitfields than they do
for bitwise operators.  If speed and space aren't a concern,
then bitwise operators are indeed more portable.  But, for some
compilers I've used, using a bitfield cut the number of
instructions generated for a bit set/clear operation by 2/3.

Ideally, the compiler should generate the same code for either
approach, but some don't.

Quoted text here. Click to load it

It does seem ironic that the most popular language used in
embedded systems programming doesn't allow the programmer to
specify low-level storage layout.

--
Grant Edwards                   grante             Yow!  Hold the MAYO & pass
                                  at               the COSMIC AWARENESS...
We've slightly trimmed the long signature. Click to see the full one.
Re: C question

Quoted text here. Click to load it
[Snipped]

Ones code should at least be portable between compilers, and between
different versions of the same compiler.  It also should not break
when the optimisation level is changed. I have worked with compilers
where with low optimization, bitfields were byte aligned. When upping
the optimization to maximum, the bitfields were suddenly word aligned.
In my opinion bitfields should not be used where the underlying
structure is important. Use masks and shifts instead. If one wants to
do such things as calculations with a 12bit sized integer, then
bitfields are nice because the underlying implimentation does not
matter.

Regards
  Anton Erasmus

Re: C question
Quoted text here. Click to load it

Yes and no.

Some processors offer "near" and "far" memory.  Typically (as is true for
the 68HC08 and TMS370C8 cores) bitfield operations on bitfields of size 1
which are in "near" memory come down to a single machine instruction (a
direct-addressed OR, AND, or BTBC instruction).  Using a bitfield of size 1
on these machines is vastly superior to a variable declared outside a
structure.

Generally, the breakdown is:

a)Bitfields of size 1 in near memory on small machines often work well.

b)Bitfields of size 8 or UCHARS on more powerful machines often work well.

c)Bitfields of other sizes have questionable value in embedded work.  The
code to extract and pack the fields is often bulky.

However, on larger machines, as long as one understands the tradeoffs,
bitfields of unusual sizes can be useful.  For example, if I were
implementing chess on a PDA and had to build a large game tree in limited
RAM, I would pack things, knowing that I would make the game tree smaller at
the expense of size and speed of the code that deals with it.




Re: C question
THANK YOU GUYS!

=]
Xarion

Quoted text here. Click to load it



Site Timeline