14
7400
5y

I felt like being the cause for “that dreaded legacy code“ and wrote 250 lines of C preprocessor macros for generating bitfields in a large header file automatically, with the goal of simplifying and clarifying register access for all peripherals in the end. Then, I found out that SDCC's optimisation for bitfields is absolutely awful (if existent at all), and I don't really want to use these abstractions if they have a performance impact.

Did I deserve that?

Comments
  • 7
    You NEVER use C bitfields for peripheral register access because the C standard doesn't specify in which order the bits are implemented.
  • 3
    @Fast-Nop: I know. These headers are only going to be used with one compiler, though.
  • 5
    @7400 and that's awful legacy code - tied to a single compiler and even compiler version without any good reason.
  • 6
    @Fast-Nop: Yes, I like to live dangerously. Bit ordering in bitfield is not that likely to change between compiler versions, though (especially since the architecture is fixed and it's a single byte every time), and it would undeniably have been nice to use in code. Microchip even uses bitfields in the “official” headers for PICs, I think.

    But, yeah, it still was a nice exercise in writing C macros.
  • 1
    I'm tempted to extend the macros a bit and use them for my ARM example projects. Right now they use ST's headers with their not open source compatible licence. Some also use a fair amount of GCC-specific attributes. If the bit fields aren't used, the usage would be completely compatible. Comments?
  • 0
    @7400 ST's code sucks anyway; I only use it for getting a quick overview how something should work and then implement it myself.

    But if you are into macros, why don't you drop the bitfields and make set/reset bit macros using bitmasks?
  • 0
    @Fast-Nop: I never liked the aesthetics of bit set/reset/check macros. Otherwise I wouldn't go through all the trouble with bitfields.
Add Comment