offset of a bit field

[James Kuyper]

Especially since there are no (i.e. zip) guarantees about how the
bits in bitfields are selected. Use constants and | or &.

The standard does provide a few guarantees about how bit in bitfields
are selected. Not as many as some people expect, but it's not "zip", either:

6.7.2.1p10: "If enough space remains, a bit-field that immediately
follows another bit-field in a structure shall be packed into adjacent
bits of the same unit."

p11: "... a bit-field structure member with a width of 0
indicates that no further bit-field is to be packed into the unit in
which the previous bitfield, if any, was placed."

p13: "Within a structure object, the non-bit-field members and the units
in which bit-fields reside have addresses that increase in the order in
which they are declared."

Consider the following code:

struct example {
int a;
float b;
signed c:5;
signed d:3;
unsigned :0;
unsigned e:8;
double f;
} one, two;

size_t offset = offsetof(struct example, b) + sizeof one.b;
size_t width = offsetof(struct example, f) - offset
memcpy((char*)&two + offset, (char*)&one + offset, width);

Because the addressable storage unit cannot have a size of less than 8
bits, 6.7.2.1p10 guarantees that one.c and one.d share the same storage
unit.

Because of 6.7.2.1p11, one.e is guaranteed to be in a different storage
unit from one.c and one.d.

Because of 6.7.2.1p13, the call to memcpy() is guaranteed to copy the
bits representing 'c', 'd', and 'e' from 'one' to 'two'. There's no
portable way to be sure which of those bits represent each of those
variables, but they will be copied.

 

[CBFalconer]

The standard does provide a few guarantees about how bit in
bitfields are selected. Not as many as some people expect, but
it's not "zip", either:

6.7.2.1p10: "If enough space remains, a bit-field that
immediately follows another bit-field in a structure shall be
packed into adjacent bits of the same unit."

p11: "... a bit-field structure member with a width of 0
indicates that no further bit-field is to be packed into the
unit in which the previous bitfield, if any, was placed."

p13: "Within a structure object, the non-bit-field members and
the units in which bit-fields reside have addresses that
increase in the order in which they are declared."

No argument with your and Bens statements. However that doesn't
alter the need to use constants and masks in making code compatible
with hardware (portably), which was the original point.

 

[Guest]

(e-mail address removed) wrote:
over-generous...

... snip ...


Especially since there are no (i.e. zip) guarantees about how the
bits in bitfields are selected.  Use constants and | or &.

well you can guarantee that the representaion won'y change on-the-fly.
Therefore once you have determined how bit-fields arelaid out you use
fixed code to access them. As I remarked, not the right way to do it.
In practice I rarely (if ever) use bit-fuelds.

 

[Dik T. Winter]

> Richard Tobin said:
>
> Any statement that sweeping /must/ be wrong. Offhand, however, I
> can't quite demonstrate how it's wrong, so you're going to have to
> take my word for it.

It is wrong. Since "address" is not a C term (I think), the general meaning
is implied. And the CDC Cyber 205 was bit-addressable.

 

[Dik T. Winter]

> Richard Tobin wrote: ....
>
> The combination of an address and a bit offset could be used to point to
> bit-field. It's just not something that C allows you to do, at least not
> in any portable fashion, but there's nothing inherently impossible about
> it. Some implementations implement a char* pointer by combining a word
> address and a byte offset; since they choose to make the byte size
> smaller than the word size. Pointers that could point at individual bits
> would be only a little more complicated than that.

O no, not on the Cyber 205. On that machine *every* address is a bit address.
That in most cases the least significant five or six bits of the address are
0 is irrelevant.

 

[Ben Bacarisse]

It is wrong. Since "address" is not a C term (I think), the general meaning
is implied. And the CDC Cyber 205 was bit-addressable.

I agree, but I would say that "address" is a C term.

The standard does not define the term but it uses it a lot, and by
using it, constrains what it can mean. Roughly speaking, the standard
uses the term address for the values that are stored in pointers. It
talks about addressable units of storage and requires that an address
can refer to an individual char.

Nothing it says suggests that the C meaning of the term is different
from the general meaning so you are quite right in that respect. In
particular, it does not prevent an address from being able to refer to
smaller units than a char. Any uses of that facility would have to
be provided by extensions which is, presumably, what Richard Tobin
meant.

 

[CBFalconer]

.... snip ...

The standard does not define the term but it uses it a lot, and
by using it, constrains what it can mean. Roughly speaking, the
standard uses the term address for the values that are stored in
pointers. It talks about addressable units of storage and
requires that an address can refer to an individual char.

Nothing it says suggests that the C meaning of the term is
different from the general meaning so you are quite right in that
respect. In particular, it does not prevent an address from
being able to refer to smaller units than a char. Any uses of
that facility would have to be provided by extensions which is,
presumably, what Richard Tobin meant.

Not portably. See p 2 following.

3.3
[#1] bit
unit of data storage in the execution environment large
enough to hold an object that may have one of two values

[#2] NOTE It need not be possible to express the address of
each individual bit of an object.

3.4
[#1] byte
addressable unit of data storage large enough to hold any
member of the basic character set of the execution
environment

[#2] NOTE 1 It is possible to express the address of each
individual byte of an object uniquely.

[#3] NOTE 2 A byte is composed of a contiguous sequence of
bits, the number of which is implementation-defined. The
least significant bit is called the low-order bit; the most
significant bit is called the high-order bit.

 

[Ben Bacarisse]

Not portably.

Do you actually disagree with anything I said? Extensions are not
normally portable. Maybe you thought I should have made that clear.

Of course an extension *can* be portable, but that is another
argument.

 

[CBFalconer]

Do you actually disagree with anything I said? Extensions are not
normally portable. Maybe you thought I should have made that clear.

Of course an extension *can* be portable, but that is another
argument.

Just extending it. Yes, extensions CAN be portable. Then I
consider them just routines written in standard C and embedded in
something or other.

 

[David Thompson]

On Apr 10, 11:27 pm, (e-mail address removed) (Richard Tobin) wrote:

It's not possible for C to have char-addressing on machines which only
have word-addressing at the hardware level? (I'm thinking of pdp10 and
probably loads more)

PDP-10 has byte pointers that allow char (and bit) addressing/access.
Not for most instructions, true; but they are in 'hardware' (at least
in the ISA; by the KS10, lots of things were microcode rather than
true hardware, and I don't know if this was one of them).

The GE/HIS machines had some hardware support for chars within a word,
but I don't know the details. I'm not sure about CDC; I know IBM 70*
and Cray did not, because people or compilers had to code around it.
OTOH early DEC Alpha had byte addressing but not byte access!

It is my understanding that some (many? most?) DSP and graphics chips
today have widish (24-32bit) words and no byte access, but I don't
have personal experience.

If so, addresses could also have extra information to isolate specific
bits.

Even if not directly possible in C, it would be possible at the user
level.

I've worked on languages which have pointers to bits and bitfields,
and it's not a big deal. It just that C doesn't have them built-in to
the language.

Concur.