Trouble with bit fields

[=?ISO-8859-1?Q?Ney_Andr=E9_de_Mello_Zunino?=]

Hello.

I have been having some trouble dealing with bit fields. The following
is a simple program that demonstrates it.

#include <iomanip>
#include <iostream>

struct instrucao_i
{
unsigned short opcode: 6;
unsigned short rs: 5;
unsigned short rt: 5;
unsigned short immediate: 16;
};

int main()
{
instrucao_i i = { 0x24110064 };
std::cout << std::hex;
std::cout << "opcode: " << i.opcode << '\n';
std::cout << " rs: " << i.rs << '\n';
std::cout << " rt: " << i.rt << '\n';
std::cout << "immed.: " << i.immediate << '\n';
}

Here is the binary representation of the 32-bit word being used to
initialize /i/:

0010 0100 0001 0001 0000 0000 0110 0100

Since the /opcode/ field is 6 bits long, it should be equal to the first
6 bits of /i/, i.e., 001001, which is 9 in decimal. However, this is the
output I get with both VC++ 7.1 and BCC32 5.5.1 on Windows:

D:\Temp>teste
opcode: 24
rs: 0
rt: 0
immed.: 0

Could anybody shed some light on this subject?

Thank you very much,

 

[Victor Bazarov]

I have been having some trouble dealing with bit fields. The following
is a simple program that demonstrates it.

#include <iomanip>
#include <iostream>

struct instrucao_i
{
unsigned short opcode: 6;
unsigned short rs: 5;
unsigned short rt: 5;
unsigned short immediate: 16;
};

int main()
{
instrucao_i i = { 0x24110064 };
std::cout << std::hex;
std::cout << "opcode: " << i.opcode << '\n';
std::cout << " rs: " << i.rs << '\n';
std::cout << " rt: " << i.rt << '\n';
std::cout << "immed.: " << i.immediate << '\n';
}

Here is the binary representation of the 32-bit word being used to
initialize /i/:

0010 0100 0001 0001 0000 0000 0110 0100

No. It's the 32-bit word you used to intialise i.opcode.

Since the /opcode/ field is 6 bits long, it should be equal to the first
6 bits of /i/, i.e., 001001, which is 9 in decimal.

Why? The rules for initialising aggregates still apply. In order
to initialise a struct you need all elements mentioned.

However, this is the
output I get with both VC++ 7.1 and BCC32 5.5.1 on Windows:

D:\Temp>teste
opcode: 24
rs: 0
rt: 0
immed.: 0

Could anybody shed some light on this subject?

Initialisation of a struct is a very particular thing. Each initialiser
is used to initialise the respective member, and if there are fewer
initialisers than members, the remaining members are initialised to 0.

In your case you intialise 'opcode' with 0x24110064 (which cuts off its
last 6 bits, and yields 24), and the rest of them to zeroes. Why does
the result surprise you? If you wanted 9 in 'opcode', you should have
written

instrucao_i i = { 9, 0, 0x11, 0x64 };

Victor

 

[=?ISO-8859-1?Q?Ney_Andr=E9_de_Mello_Zunino?=]

Victor Bazarov wrote:

[...]

In your case you intialise 'opcode' with 0x24110064 (which cuts off its
last 6 bits, and yields 24), and the rest of them to zeroes. Why does
the result surprise you? If you wanted 9 in 'opcode', you should have
written

instrucao_i i = { 9, 0, 0x11, 0x64 };

The actual usage of the bit fields varies a little in my real program. I
only tried to simplify it in order to facilitate the comprehension of
the code.

The main difference in the real code is that the struct with the bit
fields shares a union with a 32-bit variable. So, I actually initialize
the struct via that number. Here is an extended version of the sample
program:

#include <iomanip>
#include <iostream>

struct instrucao_i
{
unsigned short opcode: 6;
unsigned short rs: 5;
unsigned short rt: 5;
unsigned short immediate: 16;
};

union instrucao
{
unsigned int numero;
instrucao_i instr;
};

int main()
{
unsigned int numero = 0x24110064;
instrucao i;
i.numero = numero;
std::cout << std::hex;
std::cout << "opcode: " << i.instr.opcode << '\n';
std::cout << " rs: " << i.instr.rs << '\n';
std::cout << " rt: " << i.instr.rt << '\n';
std::cout << "immed.: " << i.instr.immediate << '\n';
}

That is how I get the 32-bit number into the struct. My intention with
the bit field is to be able to access each part of the instruction's bit
pack. What am I still missing?

Thank you again,

 

[=?ISO-8859-1?Q?Ney_Andr=E9_de_Mello_Zunino?=]

The main difference in the real code is that the struct with the bit
fields shares a union with a 32-bit variable. So, I actually initialize
the struct via that number. Here is an extended version of the sample
program:

I forgot to include the output I get with the new version, which is
still not what I am looking for:

D:\Temp>teste
opcode: 24
rs: 1
rt: 0
immed.: 2411

Regards,

 

[Ashes]

Hi

In VC++, the order of your struct members needs to be reversed as
follows:

struct instrucao_i
{
unsigned short immediate: 15;
unsigned short rt: 5;
unsigned short rs: 5;
unsigned short opcode: 6;
};

Then the output you get is as follows:
opcode: 9
rs: 0
rt: 11
immed.: 64

Hope this helps ...
Ashley

 

[Ashes]

Hi

Oops, made typo in previous post - struct declaration was meant to be as
follows:

struct instrucao_i
{
unsigned short immediate: 16;
unsigned short rt: 5;
unsigned short rs: 5;
unsigned short opcode: 6;
};

Apologies for that ...
Ashley

 

[=?ISO-8859-1?Q?Ney_Andr=E9_de_Mello_Zunino?=]

struct instrucao_i
{
unsigned short immediate: 16;
unsigned short rt: 5;
unsigned short rs: 5;
unsigned short opcode: 6;
};

Thanks, it works. But I noticed that if I change the type of the last
three fields above from unsigned short to unsigned char (which is enough
to hold those fields), the behavior gets wrong again. Why is that? And
why must the members be laid out in the opposite order? Is that only the
case for IA32-based machines?

Regards,

 

[Dietmar Kuehl]

struct instrucao_i
{
unsigned short opcode: 6;
unsigned short rs: 5;
unsigned short rt: 5;
unsigned short immediate: 16;
};

union instrucao
{
unsigned int numero;
instrucao_i instr;
};

int main()
{
unsigned int numero = 0x24110064;
instrucao i;
i.numero = numero;
std::cout << std::hex;
std::cout << "opcode: " << i.instr.opcode << '\n';
std::cout << " rs: " << i.instr.rs << '\n';
std::cout << " rt: " << i.instr.rt << '\n';
std::cout << "immed.: " << i.instr.immediate << '\n';
}

The value of 'i.instr' is undefined: you initialized 'i.numero'. After
the corresponding assignment you can read an 'i.numero' and expect it
to contain the value you designed to it. What happens if you access
'i.instr' without prio assignment to this field is undefined.

 

[Thomas Matthews]

Hello.

I have been having some trouble dealing with bit fields. The following
is a simple program that demonstrates it.

#include <iomanip>
#include <iostream>

struct instrucao_i
{
unsigned short opcode: 6;
unsigned short rs: 5;
unsigned short rt: 5;
unsigned short immediate: 16;
};

int main()
{
instrucao_i i = { 0x24110064 };
std::cout << std::hex;
std::cout << "opcode: " << i.opcode << '\n';
std::cout << " rs: " << i.rs << '\n';
std::cout << " rt: " << i.rt << '\n';
std::cout << "immed.: " << i.immediate << '\n';
}

Here is the binary representation of the 32-bit word being used to
initialize /i/:

0010 0100 0001 0001 0000 0000 0110 0100

Since the /opcode/ field is 6 bits long, it should be equal to the first
6 bits of /i/, i.e., 001001, which is 9 in decimal. However, this is the
output I get with both VC++ 7.1 and BCC32 5.5.1 on Windows:

D:\Temp>teste
opcode: 24
rs: 0
rt: 0
immed.: 0

Could anybody shed some light on this subject?

Thank you very much,

I believe that you should try a different approach.
Use the bitwise arithmetic operators to isolate the
bit fields into integral variables:

class Instruction
{
public:
Instruction(unsigned long data = 0);
private:
unsigned int opcode;
unsigned int rs;
unsigned int rt;
unsigned int immediate;
};

Instruction::Instruction(unsigned long data)
{
immediate = static_cast<unsigned int>(data & 0xFF);
data >>= 16;
rt = static_cast<unsigned int>(data & 0x1F);
data >>= 5;
rs = static_cast<unsigned int>(data & 0x1F);
data >>= 5;
opcode = static_cast<unsigned int>(data & 0x3F);
}

Not using bit fields allows for easier conversion from
Big Endian or Little Endian byte ordering. Also, some
compilers mess up when accessing bitfields in
structures, especially when the optimization level
is set high.

Another nice feature is that bit fields are converted
into the processor's native integral format. This
will simplify your program and make it more efficient
(faster).

You _may_ want to consider a hierarchial approach, in
which Instruction is a base class and have separate
leaf classes for each instruction. This will allow
generic functions, such as execute and print, to
be applied to any instruction. I used an array of
pointers to the Instruction base class to represent
a program.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book

 

[Ashes]

Hi

On 32 bit Windows, the size of an unsigned char is 1 byte whereas the size
of an unsigned short is 2 hence the difference when changing the type.

I believe that the reason the struct has to be reversed to get the byte
ordering you need is Microsoft compiler specific.

Regards
Ashley

 

[Ron Natalie]

I believe that the reason the struct has to be reversed to get the byte
ordering you need is Microsoft compiler specific.

Bitfields are pretty worthless if you care about the packing. It's implementation
dependent everywhere. I had no fewer than 4 different definitions of a bitfield
back when I was using it to pick out bits of a network packet. I finally just gave
up and used masks and shifts instead.

 

[Thomas Matthews]

Bitfields are pretty worthless if you care about the packing. It's implementation
dependent everywhere. I had no fewer than 4 different definitions of a bitfield
back when I was using it to pick out bits of a network packet. I finally just gave
up and used masks and shifts instead.

Actually, the problem isn't so much related to the platform
but with the compiler. I've had different compilers change
the ordering and also screw up on accessing the bit fields.
I just save myself the agony and use masks and shifts. This
is more portable.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book

 

[=?ISO-8859-1?Q?Ney_Andr=E9_de_Mello_Zunino?=]

Actually, the problem isn't so much related to the platform
but with the compiler. I've had different compilers change
the ordering and also screw up on accessing the bit fields.
I just save myself the agony and use masks and shifts. This
is more portable.

Ok, I think I've read enough about those nasty bit fields. I guess I
will just join most of you and go the way of bit shifting. Nevertheless,
I must say I would rather see compilers improve in this regard than
have a unreliable feature lying around.

Thanks to all,