Bare Metal C++ Register Access API

allthingsembedded.com

15 points·tempodox··5 comments

WindRiver diab uses bit fields ordered "the other way". It is not soooo uncommon in embedded... Wer ended up writing convenience classes for mask and shift (and checked that they ended up in a single assembler instruction) for that reason...

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.

The 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.

It'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.

This page is about memory-mapped hardware registers, not CPU registers.

It explains pitfalls in accessing these through low level C definitions, proposes a C++ encapsulation class and summarizes pros and cons.

Reply on news.ycombinator.com