4 ms·
There is pretty much no guarantee at all regarding what code a compiler will emit for bitfields. Per spec, the order and sizes can change. The author does ment
by Ecco 5y ago
There is pretty much no guarantee at all regarding what code a compiler will emit for bitfields. Per spec, the order and sizes can change.
The author does mention some of this but their conclusion is misguided: it’s not a portability problem, it’s a showstopper. Indeed, the next point release of the exact same compiler could very well decide to use a completely different behavior for bitfield.
Any seasoned low-level engineer would know: bitfields should never be used for register mapping, period. I wish the article made that more explicit.
- 10000truths 5y agoThe author also fails to mention one other important failure point, which is write-back caching effects. This obviously doesn’t pop up for microcontrollers since they don’t have a CPU cache, but if you’re interacting with PCIE BAR registers from x86/ARM and you don’t use non-temporal load/store instructions to bypass CPU caching side effects, you’re going to have a bad time.
- auxym 5y agoIt's extremely common to use bitfields though. As mentioned by the article, it is recommended by ARM's CMSIS and thus found in vendor libraries of all cortex MCUs I have seen. arm-none-eabi-gcc changing its behavior for bitfields would probably break 99% of existing arm MCU codebases.