> And I think the adjustments should not be done after the fact in
> finish_record_layout, but rather right in place_field, where also
> the fields alignment and mode are properly tracked.
It would be a lot harder to keep track of which bits are allocated and
which aren't if we do it in place_fie
Hi,
On Wed, 9 Mar 2011, DJ Delorie wrote:
> To avoid having two completely independent definitions of the
> peripheral register structures, would it be acceptable to add a target
> hook to tell gcc to reverse the bitfields? This can be done in
> finish_record_layout() by adjusting bit offsets, b
Quoting Ian Lance Taylor :
DJ Delorie writes:
Except that in this case we want to reverse *only* structures that
represent peripherals, *not* other structures.
I'm sorry, that just seems frigging ridiculous.
I can see arguments to have it either way.
At any rate, once you have an attribut
> I'm tempted to agree. I thought people had stopped numbering bits
> in the wrong order
This has nothing to do with numbering bits, it's about how gcc
allocates bitfields within structures. Consider:
struct {
char a:4;
char b:4;
} Foo;
Nothing says that 'a' is in the LSBs of the byte, or
> > Except that in this case we want to reverse *only* structures that
> > represent peripherals, *not* other structures.
>
> I'm sorry, that just seems frigging ridiculous.
Ridiculous? Why? I see no reason why we should dictate how other
people write their software, or design their chips. Ca
On Mar 9, 2011, at 8:52 PM, Ian Lance Taylor wrote:
> DJ Delorie writes:
>
>> Except that in this case we want to reverse *only* structures that
>> represent peripherals, *not* other structures.
>
> I'm sorry, that just seems frigging ridiculous.
I'm tempted to agree. I thought people had st
DJ Delorie writes:
> Except that in this case we want to reverse *only* structures that
> represent peripherals, *not* other structures.
I'm sorry, that just seems frigging ridiculous.
>> If you need type attributes for this beyond a simple macro, then I agree
>> that they should be target ind
> 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 an
DJ Delorie writes:
> In the RX chip (and others, of course), the memory-mapped peripherals
> have a fixed bit-ordering independent of the endianness of data.
> However, GCC defines bitfields in structures differently for different
> endians - effectively always beginning allocations with the lowe
In the RX chip (and others, of course), the memory-mapped peripherals
have a fixed bit-ordering independent of the endianness of data.
However, GCC defines bitfields in structures differently for different
endians - effectively always beginning allocations with the lowest
addressed byte.
To avoid
10 matches
Mail list logo
