Bit manipulation

[yezi]

Hi:
One question about the bit manipulation: if the code is like :

int sequence:18;

is that mean, in memory, although generally for int, it occupy 32 bits,
but now by define 18, which means the real occupancy is 18 bits?

Is that understanding right?

Thanks for any comments.


bin YE

 

[Kwan Lim]

I assume you mean

int sequence = 18;

the size of the integer will be machine dependant but is typically 2 or
4 bytes.
What happens in that assignment statment is that the binary 2's
complement bit pattern for 18 is stored in the memory of the variable.
It is this pattern that will take up the bits.

 

[yezi]

The sentence is

int sequence :18, not

int sequence =18.

 

[Michael Mair]

Hi:
One question about the bit manipulation: if the code is like :

Do you mean _bitfields_? If yes, please say so.

int sequence:18;

is that mean, in memory, although generally for int, it occupy 32 bits,
but now by define 18, which means the real occupancy is 18 bits?

Is that understanding right?

Note that bitfields occur only as structure members.
If you define an unsigned int bitfield of width N then
you know that you are really working modulo pow(2,N).
However, that you cannot get the address of a bitfield
nor know the internal representation or even the order
of consecutive bitfields.

If you have
struct example {
int foo;
int bar:5;
int baz;
} qux;
then baz will still start at an address with alignment
proper to int and the number of bits between the "end"
of qux.foo and the start of qux.baz will be more than
five.


As an aside: int is guaranteed to have at least 16 bits,
nothing more.


Cheers
Michael

 

[yezi]

then, which means if the memory is continuous, the memory should like
the following :

16 bits for qux.foo;
5 bits for qux.bar;
3 bits for anystuff which is not belong to the structure;
16 bits for qux.baz;

Is that understanding right?


Thanks

 

[gooch]

then, which means if the memory is continuous, the memory should like
the following :

16 bits for qux.foo;
5 bits for qux.bar;
3 bits for anystuff which is not belong to the structure;
16 bits for qux.baz;

Is that understanding right?


Thanks

What it looks like in memory depends on the implementation and how many
bits it uses to represent an int as well as how it aligns structure
elements. Where the bits in the bit field are may also depend on the
endianess of the platform.

 

[Niklas Norrthon]

then, which means if the memory is continuous, the memory should like
the following :

[snipped by yezi and reincluded by me]

struct example {
int foo;
int bar:5;
int baz;
} qux;

16 bits for qux.foo;

No. sizeof(int) * CHAR_BIT for qux.foo

Followed by an unspecifed amount of padding bits, followed by

5 bits for qux.bar;

3 bits for anystuff which is not belong to the structure;

No, not necessary 3 bit, but another unspecifed amount of padding bits,
which will result in correct alignment for the next struct member.

16 bits for qux.baz;

No, sizeof(int) * CHAR_BIT here too.

Is that understanding right?

No.

CHAR_BIT is at least 8, and 8 is the most common value in todays
implementations, but other values do exist. There are systems with
9 bit characters, and 36 bit integers for example.

sizeof(int) must be at least 2 on implementations where CHAR_BIT is 8,
but more common today are 4, and 8 is not unheard of.

An implementation is allowed to insert padding (unused memory space)
between members in a struct, so that all members will be properly
aligned. The amount of padding is implementation specific, and may
vary between platform, between compilers, between compiler versions,
and possibly depending on compiler settings. In practice it can be
a good idea to put the larger sized members first in a struct, and
to have same sized members adjacent to each other, to minimize the
amount of padding.

/Niklas Norrthon