Alex Deucher <alexdeucher at gmail.com> writes:
> As part of the amdgpu transition, we are moving to using database
> generated register and packet headers. We have a number of options
> for formatting, some of which involve bitfields (don't worry there
> will also be shift/mask style headers as well which is mainly what we
> use in the code). I think these formats are cleaner for a number of
> cases, however, as far as I know, C does not define the ordering of
> bits within bitfields. That said, every compiler I've used seems to
> do what you would expect. It makes coding a lot cleaner as less
> error-prone in certain cases. Here are a couple of example of what
> I'm talking about:
>
> A register example:
>
> union GRPH_SWAP_CNTL {
> struct {
> #if BIG_ENDIAN
> unsigned int : 20;
> unsigned int GRPH_ALPHA_CROSSBAR : 2;
> unsigned int GRPH_BLUE_CROSSBAR : 2;
> unsigned int GRPH_GREEN_CROSSBAR : 2;
> unsigned int GRPH_RED_CROSSBAR : 2;
> unsigned int : 2;
> unsigned int GRPH_ENDIAN_SWAP : 2;
> #else
> unsigned int GRPH_ENDIAN_SWAP : 2;
> unsigned int : 2;
> unsigned int GRPH_RED_CROSSBAR : 2;
> unsigned int GRPH_GREEN_CROSSBAR : 2;
> unsigned int GRPH_BLUE_CROSSBAR : 2;
> unsigned int GRPH_ALPHA_CROSSBAR : 2;
> unsigned int : 20;
> #endif
> } bitfields, bits;
> unsigned int u32All;
> signed int i32All;
> float f32All;
> };
> Are there any strong objections to these sorts of structures?
My experience with bitfields was that the code generated by gcc was
atrocious, and I wouldn't use them for any performance sensitive 32-bit
word setup. As a result, publishing headers in the form of
bitfield-structs seems like a way to encourage people to generate bad
code for your hardware.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141016/b88c2586/attachment.sig>
