bit fields in a structure

[Hetal]

Hey all ...

I have a question.

I have a structure as below:

typedef struct
{
UInt8 data1;
UInt8 data2_4b : 4,
data2_nxt4b : 4;
UInt16 data3;
} data_T;

assuming ..
UInt8 = unsigned char
UInt16 = unsigned short int

My code is running on a Windows system (Little Endian)
When I write code to store data in this structure and view the memory
windows in Visual Studio ... this is wht I get.

when I set data2_4b = 7; and data2_nxt4b = 3; the memory window shows
....

0011 0111 (0x37)
Shouldn't I be seeing 0111 0011 (0x78). Thus looks like when splitting
the byte .. the processor is storing the first 4 bits in the least
significat half byte and the second four bits in the most significant
half byte.

Is this a processor specific thing ? That is will this code execute
differently on diffeent systems ?

thanks,
Hetal.

 

[Gordon Burditt]

I have a question.

I have a structure as below:

typedef struct
{
UInt8 data1;
UInt8 data2_4b : 4,
data2_nxt4b : 4;
UInt16 data3;
} data_T;

assuming ..
UInt8 = unsigned char
UInt16 = unsigned short int

My code is running on a Windows system (Little Endian)

Little-BYTE-Endian does not say anything about BIT-Endianness.

When I write code to store data in this structure and view the memory
windows in Visual Studio ... this is wht I get.

when I set data2_4b = 7; and data2_nxt4b = 3; the memory window shows
...

0011 0111 (0x37)
Shouldn't I be seeing 0111 0011 (0x78).

That's 0x73, not 0x78, and no, you're not guaranteed that.

Thus looks like when splitting
the byte .. the processor is storing the first 4 bits in the least
significat half byte and the second four bits in the most significant
half byte.

Which it's allowed to do. And isn't that what LITTLE ENDIAN means?
The first stuff goes in the LEAST SIGNIFICANT piece?

Is this a processor specific thing ? That is will this code execute
differently on diffeent systems ?

"memory windows" are not a feature of C. Memory layouts of structs, with or
without bitfields, are specific to the implementation.

Gordon L. Burditt

 

[Peter Shaggy Haywood]

Groovy hepcat Hetal was jivin' on 17 May 2004 14:45:01 -0700 in
comp.lang.c.
bit fields in a structure's a cool scene! Dig it!

I have a structure as below:

typedef struct
{
UInt8 data1;
UInt8 data2_4b : 4,
data2_nxt4b : 4;
UInt16 data3;
} data_T;

assuming ..
UInt8 = unsigned char
UInt16 = unsigned short int

My code is running on a Windows system (Little Endian)
When I write code to store data in this structure and view the memory
windows in Visual Studio ... this is wht I get.

when I set data2_4b = 7; and data2_nxt4b = 3; the memory window shows
...

0011 0111 (0x37)
Shouldn't I be seeing 0111 0011 (0x78). Thus looks like when splitting
the byte .. the processor is storing the first 4 bits in the least
significat half byte and the second four bits in the most significant
half byte.

Of course. That's because it's not only the bytes that have little
endian order, but the bits within each byte too. Or, to put it another
way, bytes are "backwards" on Intel hardware. So, the "first" few bits
occupy the "back" of the byte, while the "last" bits occupy the
"front".
Of course, all this is off topic.

Is this a processor specific thing ? That is will this code execute

Yes. Some other processors have the same bit order architecture.
Others don't.

differently on diffeent systems ?

On some, yes.

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?