Bitfields are not supported in the OpenCL language. What was the reason to not support them? Unlike in other pieces omited (recursion, pointers to functions, ...), where there is an obvious reason to not support them, I fail to see one for bitfields. I am sure that it is not an oversight on behalf of the commitee, but what is the reason?
(I store some bits packed in ints, and the code would be nicer to read with them. I understand bitfields as nice syntax for avoiding bit-shifting and masking back and forth, which is what they translate to in assembly anyway.)
I was able to ask this question of somebody involved in the working group. Here's what he had to say:
Bit-fields are not portable -- so they could not be used in types used for kernel arguments.
The only place they could be used is for types for local variables declared inside a kernel.
The OpenCL working group was not convinced this was very useful. In addition, there were concerns that compilers may not generate efficient code when using bitfields. All of these led the working group to the decision not to support bit-fields in OpenCL C.
Wikipedia has some info on the drawbacks of bitfields:
Bit members in structures as presented above have potential practical drawbacks. First, the ordering of bits in memory is CPU dependent and memory padding rules can vary between compilers. In addition, less well-optimized compilers sometimes generate poor quality code for reading and writing bit members and there are potentially thread safety issues relating to bit fields because most machines cannot manipulate arbitrary sets of bits in memory, but must instead load and store whole words.
I think all of these drawbacks are relevant in an OpenCL environment.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With