C question

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.

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

THANK YOU GUYS!

=] Xarion

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.

So. That's what embedded programming is about.

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.

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.

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

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.