> From: Bernd Edlinger <bernd.edlin...@hotmail.de> > Date: Wed, 4 Sep 2013 10:15:22 +0200
> Even driver code rarely uses bit-fields for register access, > because that is inherently non-portabe. Reason: the bit > positions are completely different on little- and big-endian > targets. Most drivers I have seen use some macros and explicit > bit operations for register accesses. Counter-observation, FWIW: most drivers I work on (...) use bit-field structures filled to capacity of the I/O access size (almost always 32 bits), read and written volatile as the full structure. None of the I/O accesses are per *individual* bit-field, so this particular discussion does not apply, but I very much would like a warning for unportable code (meaning: across targets and ABIs within gcc). The bit-field-structure declarations are in turn generated by a (supposedly :) target-endian-aware generator from an I/O register description (also layout-aware except all intended targets have a common layout for the declarations used). If both-endian declarations were desirable, both could easily be generated and selected #if THATENDIAN-style. Not my idea but I dare defend it: using bit-field syntax is quite a bit more readable than shifting-and-masking macros. Unfortunately, sometimes there's a gcc-bug or two, tree-sra being a usual suspect. :/ brgds, H-P
