5 ms·

Helper functions or macros are just as clean as the bitfield syntax. That said, hardware register access is one of those things that is intrinsically tied to a

by pavon 5y ago

Helper functions or macros are just as clean as the bitfield syntax. That said, hardware register access is one of those things that is intrinsically tied to a specific platform (and if you target multiple platforms, it will already be behind an abstraction layer), so you can usually know the quirks of how the toolchain for that platform supports bitfields, and use them accordingly. Still more work for people reading the code, though since there are a lot of hidden assumptions behind that deceptively simple "=" than with an explicit mask and shift.

AdamH12113 5y ago
>Helper functions or macros are just as clean as the bitfield syntax. They can be, if done right, but then I have to remember the names of all the helper functions and macros. :-) An IDE can auto-complete bitfield names. >Still more work for people reading the code, though since there are a lot of hidden assumptions behind that deceptively simple "=" than with an explicit mask and shift. Depends on the platform. IIRC on ARM a bitfield access is masking and shifting, only done by the compiler instead of me. With optimized code I often have to look at the disassembly anyway if I want to know what's really going on.
- deaddodo 5y ago
  > Depends on the platform. IIRC on ARM a bitfield access is masking and shifting, only done by the compiler instead of me. With optimized code I often have to look at the disassembly anyway if I want to know what's really going on. ARM supports native bitfield loading[1], extraction[2] and clearing[3]. 1 - https://developer.arm.com/documentation/ddi0602/2022-03/Base-Instructions/BFI--Bitfield-Insert--an-alias-of-BFM-?lang=en https://developer.arm.com/documentation/ddi0602/2022-03/Base... 2 - https://developer.arm.com/documentation/ddi0602/2022-03/Base-Instructions/UBFX--Unsigned-Bitfield-Extract--an-alias-of-UBFM-?lang=en https://developer.arm.com/documentation/ddi0602/2022-03/Base... 3 - https://developer.arm.com/documentation/ddi0602/2022-03/Base-Instructions/BFC--Bitfield-Clear--an-alias-of-BFM-?lang=en https://developer.arm.com/documentation/ddi0602/2022-03/Base...
- ncmncm 5y ago
  There are tens of thousands of different ARM chip types. Many of them get it right.
- raxxorraxor 5y ago
  Another trap with macros is that they might introduce extremely hard to detect bugs. You macro for clearing a bit like for example: #define CLEARBIT(a,p) = ((a) &= ~(1 << (p))) might not work correctly if your datatype is something "exotic" like a long. An inlined function might be the better choice. Otherwise you would need to define specific macros again: #define CLEARBITLONG(a,p) = ((a) &= ~(1L << (p))) These bugs can steal hours of your time, especially on embedded systems where debugging is less accessible.
  - FrozenVoid 5y ago
    #define CLEARBIT(a,p) = ((a) &= ~((typeof(a))1 << (p)))
    - raxxorraxor 5y ago
      That is clearly better provided the compiler supports it. Less portable but it should really be a part of ISO C in my opinion.

by pavon 5y ago

AdamH12113 5y ago

>Helper functions or macros are just as clean as the bitfield syntax. They can be, if done right, but then I have to remember the names of all the helper functions and macros. :-) An IDE can auto-complete bitfield names. >Still more work for people reading the code, though since there are a lot of hidden assumptions behind that deceptively simple "=" than with an explicit mask and shift. Depends on the platform. IIRC on ARM a bitfield access is masking and shifting, only done by the compiler instead of me. With optimized code I often have to look at the disassembly anyway if I want to know what's really going on.

deaddodo 5y ago
> Depends on the platform. IIRC on ARM a bitfield access is masking and shifting, only done by the compiler instead of me. With optimized code I often have to look at the disassembly anyway if I want to know what's really going on. ARM supports native bitfield loading[1], extraction[2] and clearing[3]. 1 - https://developer.arm.com/documentation/ddi0602/2022-03/Base-Instructions/BFI--Bitfield-Insert--an-alias-of-BFM-?lang=en https://developer.arm.com/documentation/ddi0602/2022-03/Base... 2 - https://developer.arm.com/documentation/ddi0602/2022-03/Base-Instructions/UBFX--Unsigned-Bitfield-Extract--an-alias-of-UBFM-?lang=en https://developer.arm.com/documentation/ddi0602/2022-03/Base... 3 - https://developer.arm.com/documentation/ddi0602/2022-03/Base-Instructions/BFC--Bitfield-Clear--an-alias-of-BFM-?lang=en https://developer.arm.com/documentation/ddi0602/2022-03/Base...
ncmncm 5y ago
There are tens of thousands of different ARM chip types. Many of them get it right.
raxxorraxor 5y ago
Another trap with macros is that they might introduce extremely hard to detect bugs. You macro for clearing a bit like for example: #define CLEARBIT(a,p) = ((a) &= ~(1 << (p))) might not work correctly if your datatype is something "exotic" like a long. An inlined function might be the better choice. Otherwise you would need to define specific macros again: #define CLEARBITLONG(a,p) = ((a) &= ~(1L << (p))) These bugs can steal hours of your time, especially on embedded systems where debugging is less accessible.
- FrozenVoid 5y ago
  #define CLEARBIT(a,p) = ((a) &= ~((typeof(a))1 << (p)))
  - raxxorraxor 5y ago
    That is clearly better provided the compiler supports it. Less portable but it should really be a part of ISO C in my opinion.