Re: reverse bitfield patch

[DJ Delorie <dj at redhat dot com>]

> Ok, but as we are dealing exclusively with bitfields there is
> already output_constructor_bitfield which uses an intermediate
> state to "pack" bits into units that are then emitted.  It shouldn't
> be hard to change that to make it pack into the appropriate bits
> instead.

That assumes that the output unit is only emitted once per string of
bitfields.  If the total amount of data to output is larger than the
unit size, then the units themselves need to be output in the other
order also.

> Note that code expects that representatives are byte-aligned so better
> would be to not assign representatives or make the code work with
> the swapped layout (I see no reason why that shouldn't work - maybe
> it works doing before swapping the layout)?

I'm OK with not assigning them, but I couldn't figure out from the
code what they were for.

> I'm still not happy about the idea in general (why is this a bitfield
> exclusive thing?  If a piece of HW is big/little-endian then even
> regular fields would have that property.

A bi-endian MCU with memory-mapped peripherals needs this to properly
and portably describe the fields within the peripheral's registers.
Without this patch, there's no way (short of two independent
definitions) of assigning a name to, for example, the LSB of such a
device's registers.

> Your patch comes with no testcase - testcases should cover all
> attribute variants, multiple bitfield (group) sizes and mixed
> initializations / reads / writes and be best execute testcases.

I wrote testcases, perhaps I just forgot to attach them.