At the risk of being naive: implement it. I'm not quite sure what
you're looking for here?
Ok, time to ask for a hint. I started at get_best_mode(), adding a
TREE argument for the type, and worked my way out, adding arguments to
functions as needed to propogate the type information. It's
I think the ARM specification is pretty sensible, and would make a
good cross-platform approach.
Could you distill it for us?
The relevant bits are from AAPCS \S 7.1.7.5, and quoted below.
I finally got the last of the feedback I needed from our customers,
and they agree that the
DJ Delorie wrote:
I think the ARM specification is pretty sensible, and would make a
good cross-platform approach.
I finally got the last of the feedback I needed from our customers,
and they agree that the AAPCS functionality is suitable for their
ports as well.
Great!
What's the next
At the risk of being naive: implement it. I'm not quite sure what
you're looking for here?
I'd rather have some confidence that the way I choose to implement it
would be acceptable to those who would be reviewing it ;-)
I'll give it a shot at the same point in the code where we call the
DJ Delorie wrote:
I think the ARM specification is pretty sensible, and would make a
good cross-platform approach.
Could you distill it for us?
The relevant bits are from AAPCS \S 7.1.7.5, and quoted below.
The term container here means the declared type of the bit-field.
(There's a
We seem to have dropped this discussion. I now have *two* customers
asking for this functionality. Can we pick it up again? We need to
decide:
1. If the functionality will be allowed in gcc at all
2. What info the target needs to be provided to make the choices it wants
3. What, if any,
Ian Lance Taylor wrote:
1. If the functionality will be allowed in gcc at all
2. What info the target needs to be provided to make the choices it wants
3. What, if any, common code can be shared between the CPUs
Since the ARM ABI apparently specifies something about volatile
bitfields, I
I think the ARM specification is pretty sensible, and would make a
good cross-platform approach.
Could you distill it for us? If it's acceptable to my two customers,
it would be a good starting point to define an API for the targets.
Ian Lance Taylor wrote:
So... can I/we move forward on this? Or will such a change be
rejected?
It's hard for me to get excited about something like this. It's
straightforward a programmer to write code that is clearly correct in
this sort of situation: just don't use a bitfield.
In
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042c/IHI0042C_aapcs.pdf
and, in particular, \S 7.1.7.5, entitled Volatile bit-fields.
A first question is if these are the semantics that you're looking for
in your project. If so, then we could collaborate with you on
implementing
DJ Delorie wrote:
Yes, that's pretty much what they asked for. However, it is still
somewhat ambiguous - for example, if you have an 8-bit int field,
which 4 bytes are read to get that field?
I haven't gone back just now to try to find the right words in the ABI,
so I don't know for sure
So... can I/we move forward on this? Or will such a change be
rejected?
BTW, Since sending this I discovered that gcc treats these
differently wrt TARGET_NARROW_VOLATILE_BITFIELD:
volatile struct
{
unsigned int a:8;
unsigned int b:24;
} t1;
volatile struct
{
unsigned int a:7;
unsigned
DJ Delorie d...@redhat.com writes:
So... can I/we move forward on this? Or will such a change be
rejected?
BTW, Since sending this I discovered that gcc treats these
differently wrt TARGET_NARROW_VOLATILE_BITFIELD:
volatile struct
{
unsigned int a:8;
unsigned int b:24;
} t1;
On Tuesday 10 March 2009, DJ Delorie wrote:
One of our customers has a chip with memory-mapped peripheral
registers that need to be accessed in a specific mode. The registers
represent bitfields within the hardware, so a volatile struct is an
obvious choice to represent them in C.
Comments?
On Wed, 2009-03-11 at 01:05 -0400, DJ Delorie wrote:
Can you provide example code? I'm confused enough to believe
that you *should* get this effect with PCC_BITFIELD_TYPE_MATTERS
(modulo current bugs).
Imagine a device with four 8-bit registers followed by a 32-bit
register with an
On Wed, 11 Mar 2009, Paul Brook wrote:
PR23623 (I suspect the status on that bug is incorrect, it's nt actually
fixed). The ARM EABI defines semantics for volatile bitfields, and gcc gets
this wrong.
If the ARM EABI really documents the semantics for that,
implement-c.texi:Qualifiers does need
On Tue, 10 Mar 2009, DJ Delorie wrote:
One of our customers has a chip with memory-mapped peripheral
registers that need to be accessed in a specific mode. The registers
represent bitfields within the hardware, so a volatile struct is an
obvious choice to represent them in C.
Thank you for
Can you provide example code? I'm confused enough to believe
that you *should* get this effect with PCC_BITFIELD_TYPE_MATTERS
(modulo current bugs).
Imagine a device with four 8-bit registers followed by a 32-bit
register with an 8-bit field:
bytestatus (read-only, clears after reading)
One of our customers has a chip with memory-mapped peripheral
registers that need to be accessed in a specific mode. The registers
represent bitfields within the hardware, so a volatile struct is an
obvious choice to represent them in C.
However, gcc has a very simplistic heuristic for deciding
19 matches
Mail list logo
