Re: [RFC PATCH 03/23] scripts: add script to generate C header files from SVD XML files

[Richard Henderson]

On 8/13/24 03:56, Octavian Purdila wrote:
> > >    typedef struct {
> > >      ...
> > >      union {
> > >        uint32_t PSELID;              /* 0x00000FF8 Peripheral Select and
> > >                                       * Flexcomm module ID */
> > >        struct {
> > >          uint32_t PERSEL : 3;        /* [2..0] Peripheral Select */
> > >          uint32_t LOCK : 1;          /* [3..3] Lock the peripheral select */
> > >          uint32_t USARTPRESENT : 1;  /* [4..4] USART present indicator */
> > >          uint32_t SPIPRESENT : 1;    /* [5..5] SPI present indicator */
> > >          uint32_t I2CPRESENT : 1;    /* [6..6] I2C present indicator */
> > >          uint32_t I2SPRESENT : 1;    /* [7..7] I2S Present */
> > >          uint32_t : 4;
> > >          uint32_t ID : 20;           /* [31..12] Flexcomm ID */
> > >        } PSELID_b;
> > >      };
> >
> > Bitfield layout in C isn't portable, so don't generate this kind
> > of union-of-a-integer-and-some-bitfields, please. You can
> > generate FIELD() macro invocations (see include/hw/registerfields.h)
> > which define shift/mask/length macros that can be used with
> > FIELD_EX*/FIELD_DP* to do extract/deposit operations.
>
> I see that C bitfields are already used in a few places in qemu. Could
> you please elaborate on the portability issue?

Bitfields are fine, so long as you're only using them for storage compression and do not 
care about the underlying layout.

The moment you put them into a union with an integer, clearly you are expecting the 
bitfields to be in some particular order with respect to the integer, and that is the 
portability issue.

In particular, big-endian hosts will generally flip the order, layout starting at the most 
signifiacnt bit and work down.  Other compilers will pad bits for alignment in ways that 
you do not expect.

Just Don't Do It.


r~