I've been working on my OS for quite a while now. Looking at some other people's code, I saw some C code that I didn't recognize: bit-fields!
So I figured out what they were, etc... but they really bug me and I'm unsure if using them is a good idea.
Pros:
- Makes things easier (more organized)
- Lets the compiler do the bit accessing for you
Cons:
- Bit-fields HAVE to be part of an unsigned/signed int
- Endianness is implementation specific (but for an x86 OS (little-endian), it wouldn't matter since anyone who compiles it on a big-endian architecture would be using a cross compiler, right?)
Any ideas? Who uses bit-fields and who uses bit-masks, and why?
The problem with bit-fields
The problem with bit-fields
"Sufficiently advanced stupidity is indistinguishable from malice."
Why is this a problem?Cons:
- Bit-fields HAVE to be part of an unsigned/signed int Sad
Endianness is specific to the target architecture (the arch the compiler is compiler *for*, not *on*). If you recompile for a target architecture with a different endianness you're pretty much always going to run into problems. Anyway IIRC bitfields don't have any endianness problems.- Endianness is implementation specific (but for an x86 OS (little-endian), it wouldn't matter since anyone who compiles it on a big-endian architecture would be using a cross compiler, right?)
And it makes it less likely for someone who understands bitfields to make a coding error.
And it makes it more likely that someone unfamiliar with bitfields will totally screw up your code -- because the bitfield syntax is ugly as hell.
And your code would not compile on an old K&R C compiler -- since bitfields are a dangling ANSI add-on.
And it makes it more likely that someone unfamiliar with bitfields will totally screw up your code -- because the bitfield syntax is ugly as hell.
And your code would not compile on an old K&R C compiler -- since bitfields are a dangling ANSI add-on.
Re: The problem with bit-fields
Bit-fields don't have to be part of an unsigned/signed int. They only need to be part of an integer type. And the type used matters in how the compiler can store bits. Lets say you want to use a bitfield for 16bit graphics output. So you have 5 bits per color channel. That fits into uin8_t just fine. So lets define out color like this:karekare0 wrote: Cons:
- Bit-fields HAVE to be part of an unsigned/signed int
- Endianness is implementation specific (but for an x86 OS (little-endian), it wouldn't matter since anyone who compiles it on a big-endian architecture would be using a cross compiler, right?)
Any ideas? Who uses bit-fields and who uses bit-masks, and why?
Code: Select all
struct Color {
uint8_t r:5;
uint8_t g:5;
uint8_t b:5;
};
Code: Select all
struct Color {
uint16_t r:5;
uint16_t g:5;
uint16_t b:5;
};
I tried using bitfields in my own code and kind of decided against it though. While their use is verry nice the code they generate is not. I defined a bitfield describing the Page Table Entry for amd64 and then created some page table entries to map pages. The whole structure is 64bit so this should result in a simple instruction loading a 64bit value, or so I hoped. Instead the compiler would generate code to set individual bits in the field, sometimes combining a few bits, sometimes not.
As a solution I used an union of uint64_t and the bitfield. That way I can access the full page table entry in one go, extract a set of flags by masking bits etc on the one hand and on the other hand I can use the bitfield to access indivdual flags with a nice syntax:
MfG
Goswin
Life - Don't talk to me about LIFE!
So long and thanks for all the fish.
So long and thanks for all the fish.
Re: The problem with bit-fields
I decided that I'll only use bitfields where it would be easier to use them compared to bitmasks - most likely for page directories/tables, possibly segment descriptors, and idt stuff, but that's it.
I still find bitmasks easier to work with...
I still find bitmasks easier to work with...
Yes, but unsigned/signed int is the only standard-conforming one. Using other integer types are compiler extensions and might not supported on all compilers/architectures.mrvn wrote: Bit-fields don't have to be part of an unsigned/signed int. They only need to be part of an integer type. And the type used matters in how the compiler can store bits.
"Sufficiently advanced stupidity is indistinguishable from malice."
Re: The problem with bit-fields
Hear ye! Hear ye!mrvn wrote:As a solution I used an union of uint64_t and the bitfield. That way I can access the full page table entry in one go, extract a set of flags by masking bits etc on the one hand and on the other hand I can use the bitfield to access indivdual flags with a nice syntax.
Excellent design decision!
Every good solution is obvious once you've found it.
- os.hacker64
- Member
- Posts: 149
- Joined: Mon Feb 11, 2008 4:43 pm
- Location: Limbo City,Afterlife