Page 1 of 1
Odd....
Posted: Mon Feb 02, 2004 9:19 am
by Nychold
On one of the boards here (I think it was OS development), I noticed a very odd structure in C. It used a colon to denote using x bits of a variable, rather then using all of them. I'm just curious...does this work, and how? Like, for instance:
Code: Select all
typedef struct
{
unsigned short red:5;
unsigned short green:6;
unsigned short blue:5;
} RGB16, *pRGB16;
Would this produce a color in the form of rrrrr gggggg bbbbb or bbbbb gggggg rrrrr? I would check this myself, but I'm not anywhere near a C/C++ compiler at the moment. Thanks, and pardon the dumb question. ^_^
Re:Odd....
Posted: Mon Feb 02, 2004 9:58 am
by Candy
Nychold wrote:
Would this produce a color in the form of rrrrr gggggg bbbbb or bbbbb gggggg rrrrr? I would check this myself, but I'm not anywhere near a C/C++ compiler at the moment. Thanks, and pardon the dumb question. ^_^
To be completely correct, when storing it and viewing in a hex editor you would get:
but when reading as a 16-bit (or larger) int, you'd get:
because of little-endianness (assuming X86). It works on just about all modern compilers, and it uses a number of bits as it is specified to do.
Re:Odd....
Posted: Mon Feb 02, 2004 6:46 pm
by Nychold
So it's MSB->LSB. Okay...that's pretty much what I wanted to know. Didn't even know C/C++ could do that! Thanks! This'll make converting 15 bit, 16 bit, 24 bit, and 32 bit graphics much, MUCH easier. XD
Re:Odd....
Posted: Thu Feb 12, 2004 7:24 am
by Pype.Clicker
note that the MMX certainly has faster ways to do this. Geting x=color.red will be much like doing x=(color&RED_MASK)>>RED_SHIFT except the compiler picks up the mask and shift automagically and hides the details. So yes, it is easier to write, but not faster to execute than a pmunpack() stuff ...
Re:Odd....
Posted: Thu Feb 12, 2004 7:54 am
by Candy
Pype.Clicker wrote:
note that the MMX certainly has faster ways to do this. Geting x=color.red will be much like doing x=(color&RED_MASK)>>RED_SHIFT except the compiler picks up the mask and shift automagically and hides the details. So yes, it is easier to write, but not faster to execute than a pmunpack() stuff ...
Note though that GCC doesn't really make clean code from that stuff using bitfields, at least not on -O2. Also, using MMX is not possible here since MMX only supports 2^n-sized amounts, not something like 5/6/5. MMX would extract just the same. Although, there is one method I can think of to speed up the process:
pshufw mm0, [edi], 0 - assuming edi points to the 16-bit color
pandq mm0, 0x0000F80007E0001F - assuming immediates are allowed... not sure
pmullw mm0, 0x0000000000400800 - again, assuming immediates
psrlw mm0, 11d
this puts the 5/6/5 triple in mm0 in words. However, if you want MMX/SSE speeds, try using 8-bit quantities, saves speed:
movd mm0, [edi]
punpcklbw mm0, 0x0
for the same result with 8-bit quantities.
Back to the topic, bitfields are quite useful for not-speed-critical things for GCC. If it's speed critical, make your own code (asm?). So things like page tables (usually) can be done in C code.