> First I have to say that people should not use bitfields to access > memory mapped peripherals. However, at least this case is not as > bad as the volatile bitfields issue.
Agreed, but that doesn't stop people from doing it, and it does lead to more readable code. > It seems to me that the answer is not a target hook to reverse > bitfields, it is some way of saying how bitfields should be counted > within a larger structure. E.g., BITFIELDS_BIG_ENDIAN. The default > would simply be BITS_BIG_ENDIAN as it presumably is today. Except that in this case we want to reverse *only* structures that represent peripherals, *not* other structures. And swapping by default would cause all sorts of problems, because by default they'd overlap a *lot*. GCC's current method - allocate from byte zero - results in much more predictable results when you mix base types and sizes together. > If you need type attributes for this beyond a simple macro, then I agree > that they should be target independent. The syntax all the other RX compilers use is: ... regular structures... #pragma bit_order left ... peripheral structures... #pragma bit_order /* resets to default */ ... regular structures...
