Printable View
How do I get certain bits from a larger value? I am being passed an unsigned long as a function parameter and I need to get bits 0-15 and 16-23 out of it. How do I do this? (I know I have to use binary operators and shifts but I forgot how to do this exactly.) Thanks. :)
(Might want to see the attached drawing to get what I mean.)
To filter out given bits in a value you typically use the AND operator (&). So, if you need the 2. and 3. bit (counting from 0 to n / right to left / least to most significant), you first determine the value of bit 2 and 3:
The answer is 12, now take your number and AND it with 12:Code:2^2 + 2^3 = 4 + 8 = 12
If you need the 16 least significant bits from a quad, you simply AND it with the sum of the 16 least significant bits:Code:unsigned int value = 9; // 0. and 3. bit is set
unsigned int mask = 12; // value of 2. and 3. bit
unsigned int result = value & mask; // this should reult in 8 (ie. the 3. bit was set)
Or to get the value of bits 16..23:Code:unsigned int value = ...;
unsgiend int result = value & 0xffff; // 0xffff is the sum of the 16 LSBs
In the latter example you may want to shift the result so that is fits into a byte. To do that you shift the result 16 positions to the right:Code:unsigned int value = ...;
unsgiend int result = value & 0x00ff0000; // 0x00ff0000 is the sum of bits 16..23
- petterCode:unsigned int value = ...;
unsgiend char result = (value & 0x00ff0000) >> 16;
Thank you very much! :D
or do it the easy way.
Code:union Packet
{
unsigned long Value;
struct
{
unsigned long T: 1;
unsigned long P: 1;
unsigned long A: 1;
unsigned long Reserved: 4;
unsigned long E: 1;
unsigned long ScanCode: 8;
unsigned long RepeatCount: 16;
};
};
Code:Packet x;
x.Value = 0xFFFFFFFF;
x.P = 0;
x.Reserved = 0x0C;
//etc.
Hmm. I never knew about that technique. Thanks to you too! :)
no problem i hope u undestand my example because idint explain alot of it
Is this union/bitfields stuff guarated to work?
Well, this is C, not C++ stuff. It works, but you gotta find out about the order of high/low bits - this may vary, depending on the compiler. You could do that with bytes, words, lwords; here you have to watch out for the order the bytes appear.Quote:
Originally Posted by Hobson
IE,
is different fromCode:struct {
char x1:3;
char x2:5;
char x2:8;
}
Code:struct {
int x1:3;
int x2:5;
int x3:8;
}
No, not at all.Quote:
Originally Posted by Hobson
For example, I'm pretty sure Mitsukai's example won't work on most x86-32 compilers.
It's highly non-portable, because of bit order, bit fields storage size, and other bit field issues. It also introduces value representation issues, with problems of padding bits of unsigned long and bit order of the value representation of unsigned long.
Moreover, there might be aliasing issues (though, it's not very probable).
its most likely this struct does not contain padding bits. since it only has one variable and it is an aggregate.
and what do you mean with bit order?
im pretty sure this works 99%
Mitsukai
Therefore it is not guaranteed to work.Quote:
How the translator packs successive bitfield declarations into integer type objects is implementation defined.
http://www-ccs.ucsd.edu/c/types.html#Bitfields
it does not state that its not portable.
and we do not :)Quote:
You cannot portably specify more bits than are used to represent type int.
A bitfield on its own is indeed portable.Quote:
Originally Posted by Mitsukai
But a union of a bitfield and an integer is not portable, because the internal layout of the bitfield can change from compiler to compiler.
ah ok, now that makes more sense.
maybe we could use memcpy on the aggregate instead?
Code:struct Packet
{
unsigned long T: 1;
unsigned long P: 1;
unsigned long A: 1;
unsigned long Reserved: 4;
unsigned long E: 1;
unsigned long ScanCode: 8;
unsigned long RepeatCount: 16;
};
unsigned long slut = 0x0F0F0F0F
int main(void)
{
Packet x;
::memcpy(&x, &slut, sizeof(slut));
}
You cannot know for certain where each field will end up inside the integer. T could be the most significant bit or the least significant bit, so could P or A.
So you cannot use a bitfield to get specific bits (eg. the least significant bit) from an integer.
:)
MinGW 3.4.5, Borland C++ 5.5.1, Digital Mars Compiler, OpenWatcom, SCC and Turbo C++ 1 are in the bad 1% part.Quote:
Originally Posted by Mitsukai
With all of them, output is "0 1"Code:#include <stdio.h>
union Packet
{
unsigned long Value;
struct
{
unsigned long T: 1;
unsigned long P: 1;
unsigned long A: 1;
unsigned long Reserved: 4;
unsigned long E: 1;
unsigned long ScanCode: 8;
unsigned long RepeatCount: 16;
} x;
};
int main() {
Packet p;
p.Value=0xFFFFFFF0UL;
printf("%lu %lu",p.x.T,p.Value>>31);
return 0;
}
unsigned long may have padding bits.Quote:
Originally Posted by Mitsukai
This structure may contain padding bits between bit fields as well. I hope you know that "unsigned long T: 1" doesn't imply AT ALL that T is stored in the same unsigned long word than P, A and others...
Actually, a 16 bits machine may very well store "unsigned long" bit fields that are shorter than 16 bits, in a 16 bits word, and add padding if necessary.
For example:
struct {
unsigned long T: 3;
unsigned long P: 15;
};
On a 16 bits platform, this structure might be stored with padding... T and P being stored in two separate 16 bits words.
Similarly, sizeof(struct {unsigned long T:1;}) might very well be 1 or 2 on a 16 bits machine!
In your structure, there seems to be no place for padding between bit-fields on sensible implementations on 8 bits byte machines.
Wrong, it has 7 variables.Quote:
since it only has one variable and it is an aggregate.
If two bit fields are stored in the same machine byte/word/multi-word... There are mainly two sensible organisations of this fields (and a lot of other organisations which aren't sensible):Quote:
and what do you mean with bit order?
Putting the first bit-field in the lower bits (i.e. less significant bits) of the byte/word/unit and the second bit-field in the higher bits.
Of course, new issues occur because of byte order of your "unsigned long Value"!
For example, assume a 16 bits little-endian compiler, which puts T, P, A and Reserved in a first 16 bits word, with a higher-bits-to-lower-bits order of bit-fields, and put E, ScanCode and RepeatCount in the next 16 bits word... Well, in that case, the bijection of bits of bitfields to bit of unsigned long will be weird.
And, of course little-endian byte order vs big-endian byte order is not universal... There exists more complex endianess... With big-endianess in 16 bits word and little-endianess in 32 bits word.
And, padding bits in unsigned long (which may be formed of several words) as well as padding bits in simple words, may complicate things.
Padding bits isn't a myth... There exists machines without real unsigned arithmetic, on which unsigned integers are simple signed integers with the sign bit always set to zero.
On common platforms, the main issue is due to placement of bit fields.
Many compilers will pad your structure to a default boundary, such as dword. Say you have a structure containing 24 bits of data, it may well be represented as sizeof(yourStruct) = 4 bytes, instead of 3. This can wreck data structures, so to fix check your compiler's #pragma options to set padding to 1 byte.
i must have read wrong tutorials on bit fields.
reading this why did they even bother with bit fields.
i will do some tests myself but your explain it very well
Bit fields are great and they are safe. The issue here is not the bitfield, but the union.Quote:
reading this why did they even bother with bit fields.
(eta: Or did you mean: why did the tutorial use bitfields in that way?)
When you have written to a member of a union, you should only read from that same member. You can write to another member of the union, but then you can only read from that other member. What you cannot do safely is to write to one member of a union and then immediatly read from another member of the same union.
And using memcpy to write an integer into a bitfield has the same effect as using a union.
i dont think u understand my statement..as logn as bit fields are not to be portable they are almost useless..
Yes, it's true that bitfields aren't very useful.Quote:
Originally Posted by Mitsukai
For example, writing raw structures containing bitfields to files produce non-portable file formats. It's true to some extent for any binary data type (text formats rule :D )... But, for integer types, you can write a format portable to all 32 bits little-endian machines and with a bit of coding, these file formats can even be read on big endian and middle endian machines.
Bit fields are far from being panacea. They're seldomly useful.
But, sometimes, they can be handy and are in the language mainly because they've been in it for a long time.
Nevertheless, ABI exist (I'm not sure there exists a reliable ABI under Win32 which seems a quite bad system for binary compatibility... especially for C++) on some systems. For example, there's a System V i386 ABI which specifies how bit fields, structures and unions are layout in memory.
Bitfields ARE portable (as portable as integers). In fact, bitfields in unions are also portable. What is not portable is assigning to one member of a union and then reading from another member of the same union.Quote:
Originally Posted by Mitsukai
:wave:
I can write the following code and it will work on all compilers:
Code:struct BitsAndPieces
{
int a : 1;
int b : 3;
};
int f(BitsAndPieces bp)
{
return (int)(bp.a) + (int)(bp.b);
}
i dont think u understand again.
that code is NOt portable, in a way u write that data in a file as binair and read the file with a diffrent compiler program then u get undefined results.
i would be very please if in C++.0x they were more standardized and forced to have the defined bit order
The issue is not the compiler, but the platform portability. If you're compiling on a Intel, it'll use MSB (Most significant bit) order; whereas, if you compile to an LSB platform, like Motorola 68k, you'll find the byte ordering to be a problem ONLY if you write bit structures to a file and transfer to the other platform.
After having written code for Palm handheld (68k), this is an obvious problem that is easily solved with functions (macros, actually) that swap byte order for words and dwords.
The portability of the code we're talking about is in the person writing the code, not the compiler. In other words, the examples presented work, but when writing to file streams, just be sure to write in the same standard byte order.
That is true for all structs.Quote:
Originally Posted by Mitsukai
Each compiler can arrange the layout of the struct in a different way. Even the same compiler can give you a different struct layout if you change the type alignment option.Code:struct PointAndStuff
{
int x;
int y;
short n;
};
struct Any
{
long a;
struct PointAndStuff p;
short b;
char c;
double d;
};
I do not think C/C++ guarantees that you can write any built-in type to a binary file and then correctly read it from that file using a different compiler or with different options or on a different operating system. In practice you can do testing and ensure the compiled code works, but it is not automatically guaranteed in the C/C++ standard.
But that is not what portable source code means anyway. Portable source code means: If you compile it on any compiler/machine, will the program behave the same way; like the BitsAndPieces example I gave in my earlier post.
Yes, byte order, and type sizes are the most common portability problems. Other problems such as byte size and uncommon value representation (padding bits, sign and magnitude vs one's complement vs two's complement) are seldom.Quote:
Originally Posted by Zaccheus
But, if guys want, they can draw compatibility with past and future (and present), supporting only ILP32 little-endian machines.
With bit-fields, they have to draw compatibility with different compilers of the same OS, namely Win32, because Win32 has no ABI.
On other systems, this issue doesn't appear, because they have an ABI.
I hope the C and C++ commitee will never impose any ABI break. It would reveal a very low abstraction level and would mainly imply that nobody would adopt the new standard, because compiler vendors don't want to break their OWN compatibility.
Even using the same compiler, I have had problems with structs using different padding and enums having different sizes, depending on the compiler options I chose for each project. I'm now very careful to make sure all my library projects use the same settings.
I can't agree on that. T could be most or least significant bit, but definitly not P or A. The byte order may vary, depending on your usage of char, int or long, but not the bit order.Quote:
Originally Posted by Zaccheus
Least or most significant bit may vary among compilers, but how often do you change that?
a word about bitstrings beeing useful.
The major part of my life as a programmer is in transferring and processing data of telecommunication and telecontrol systems. On that level, bitstrings are extremly useful. Bits are often used to signal states of remote stations, i.e. blocked, running, reset and many others. So if you wanna no more about those states, you can use either a bitfield (once you cleared up the order), or you mask the bits out. Bitfields are much more handy - you don't have to think about mask and bit order, each and every time.
Definitively?Quote:
Originally Posted by Wild Thing
Probably on most implementations you're aware of.
But, the standard doesn't impose any constraint on that!
An implementation may very well ignore the sign bit or do similar things.
Don't assume "all the world is two's complement with System V ABI".
Actually, writing in Packet::Value and then, reading Packet::T is undefined behavior.
Quote:
Originally Posted by C++ standard
@SuperKoko: not on most implementations, but on all (I`ve seen, of course).
So if you say its theoretically possible, let´s put it the other way around: are you aware of any implementation that does mix up the bit order?
I just wanna be aware, if I happen to have to deal with such an implementation.
It is completely at the compiler vendor's discretion. While I agree that it is unlikely that P or A will endup being the least or most significant bit, there is no prescribed way in which a compiler must arrange the data.Quote:
Originally Posted by Wild Thing