bitfields: types vs modes?

bitfields: types vs modes?

[DJ Delorie]

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 what mode to
use to access bitfields in structures - it uses either the biggest or
smallest mode practical.  This offers the programmer no way to tell
gcc what mode the accesses need to be in, aside from manually
reading/writing memory with integer types and casting.

Options?  My thought, after some internal discussion, is that (if the
target chooses) we allow gcc to honor the type of a volatile bitfield
as the mode as long as it can do so without otherwise violating the
structure's layout.  Some new hook will be needed for the backend, and
perhaps a -W option for when the type cannot be honored.

I.e. if the programmer is careful enough to properly lay out the
struct, the programmer should get what the programmer asks for.

Comments?  Alternatives?

Re: bitfields: types vs modes?

[Hans-Peter Nilsson]

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 those words.  ;)

(There was a "minor argument" on IRC some time ago on a related
subject.)

> However, gcc has a very simplistic heuristic for deciding what mode to
> use to access bitfields in structures - it uses either the biggest or
> smallest mode practical.  This offers the programmer no way to tell
> gcc what mode the accesses need to be in, aside from manually
> reading/writing memory with integer types and casting.

And not even *then* are you guaranteed the intended semantics as
per the documentation (though at least each target should be
able to promise that, IMNSHO).  IMHO GCC should have the means
to do what you suggest for *all* targets; memory-mapped I/O that
needs to be accessed in a specific mode is a general-enough
situation.

> Options?  My thought, after some internal discussion, is that (if the
> target chooses) we allow gcc to honor the type of a volatile bitfield
> as the mode as long as it can do so without otherwise violating the
> structure's layout.  Some new hook will be needed for the backend, and
> perhaps a -W option for when the type cannot be honored.
>
> I.e. if the programmer is careful enough to properly lay out the
> struct, the programmer should get what the programmer asks 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).

> Comments?

The concept is certainly agreeable.  I'd recommend -fno-tree-sra
when you inspect current behavior; there be bugs there.  Sorry,
no PR yet.

brgds, H-P

Re: bitfields: types vs modes?

[DJ Delorie]

> 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:

byte	status (read-only, clears after reading)
byte	control (read/write)
byte	tx buf (write only)
byte	rx buf (read only)
long	uart configuration
		divisor:8
		bits:3
		stop:1
		start:1
		reserved:3
		clock source:8
		pin_selection:8

so, you'd do this:

typedef struct {
  char status:8;
  char control:8;
  char tx:8;
  char rx:8;
  long divisor:8;
  long bits:3;
  long stop:1;
  long start:1;
  long reserved:3;
  long clock_source:8;
  long pin_selection:8;
} UartDev;

extern volatile UartDev uart1;

If you use SImode to access any of the first four registers, you may
end up clearing a status bit you haven't read yet.  If you use QImode
to write the divisor, you may end up clearing the other bits if gcc
doesn't drive the right values onto the bus.

With our current code, the mode for access for the above would either
always be QI or always be SI; there's no way to have QI for the first
four and SI for the rest.

The culprit is get_best_mode(), which doesn't know the C type of the
field.  PCC_BITFIELD_TYPE_MATTERS seems to only control layout, not
access.  Even if it did solve the type-v-mode problem, turning it on
would break ABI compatibility.

Re: bitfields: types vs modes?

[Laurent GUERBY]

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 8-bit field:
> 
> byte	status (read-only, clears after reading)
> byte	control (read/write)
> byte	tx buf (write only)
> byte	rx buf (read only)
> long	uart configuration
> 		divisor:8
> 		bits:3
> 		stop:1
> 		start:1
> 		reserved:3
> 		clock source:8
> 		pin_selection:8
> 
> so, you'd do this:
> 
> typedef struct {
>   char status:8;
>   char control:8;
>   char tx:8;
>   char rx:8;
>   long divisor:8;
>   long bits:3;
>   long stop:1;
>   long start:1;
>   long reserved:3;
>   long clock_source:8;
>   long pin_selection:8;
> } UartDev;
> 
> extern volatile UartDev uart1;
> 
> If you use SImode to access any of the first four registers, you may
> end up clearing a status bit you haven't read yet.  If you use QImode
> to write the divisor, you may end up clearing the other bits if gcc
> doesn't drive the right values onto the bus.
> 
> With our current code, the mode for access for the above would either
> always be QI or always be SI; there's no way to have QI for the first
> four and SI for the rest.
> 
> The culprit is get_best_mode(), which doesn't know the C type of the
> field.  PCC_BITFIELD_TYPE_MATTERS seems to only control layout, not
> access.  Even if it did solve the type-v-mode problem, turning it on
> would break ABI compatibility.

I don't know how the Ada front-end achieve this and wether it's portable
but the following seem to work:

procedure Aa is

   type U8 is mod 2**8;
   for U8'Size use 8;
   pragma Atomic (U8);

   type U8B is mod 2**8;
   type U3B is mod 2**3;
   type U1B is mod 2;

   type R1 is record
      B1 : U8B;
      B2 : U3B;
      B3 : U1B;
      B4 : U1B;
      B5 : U3B;
      B6, B7 : U8B;
   end record;
   pragma Pack (R1);
   pragma Atomic (R1);

   type R is record
      B1, B2, B3, B4 : U8;
      B5 : R1;
   end record;
   pragma Pack (R);
   pragma Volatile (R);

   X : R;
   X1 : R1;
begin
   X.B1 := 0;
   X.B2 := 0;
   X.B3 := 0;
   X.B4 := 0;
   X1 := X.B5;
end AA;


gcc -S -O2 aa.adb
_ada_aa:
.LFB1:
	movb	$0, -12(%rsp)
	movb	$0, -11(%rsp)
	movb	$0, -10(%rsp)
	movb	$0, -9(%rsp)
	movl	$0, -24(%rsp)
	ret

Re: bitfields: types vs modes?

[Paul Brook]

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?  Alternatives?

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.

Paul

Re: bitfields: types vs modes?

[Hans-Peter Nilsson]

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 to defer to the ABI just
as the other items there, rather than using weasel words to the
effect of "flying demons up your nose, ha ha".  After fixing the
mentioned bug that is; *with* the bug the current wording fits. ;)
(Yeah yeah, I know: "patches welcome".)

brgds, H-P

Re: bitfields: types vs modes?

[DJ Delorie]

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 int b:25;
} t2;

t1.a will be accessed as a byte regardless of the target's
preferences, whereas t2.c follows the target preferences.

> 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 what mode to
> use to access bitfields in structures - it uses either the biggest or
> smallest mode practical.  This offers the programmer no way to tell
> gcc what mode the accesses need to be in, aside from manually
> reading/writing memory with integer types and casting.
> 
> Options?  My thought, after some internal discussion, is that (if the
> target chooses) we allow gcc to honor the type of a volatile bitfield
> as the mode as long as it can do so without otherwise violating the
> structure's layout.  Some new hook will be needed for the backend, and
> perhaps a -W option for when the type cannot be honored.
> 
> I.e. if the programmer is careful enough to properly lay out the
> struct, the programmer should get what the programmer asks for.
> 
> Comments?  Alternatives?

Re: bitfields: types vs modes?

[Ian Lance Taylor]

DJ Delorie <dj@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;
>
> volatile struct
> {
>   unsigned int a:7;
>   unsigned int b:25;
> } t2;
>
> t1.a will be accessed as a byte regardless of the target's
> preferences, whereas t2.c follows the target preferences.
>
>> 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 what mode to
>> use to access bitfields in structures - it uses either the biggest or
>> smallest mode practical.  This offers the programmer no way to tell
>> gcc what mode the accesses need to be in, aside from manually
>> reading/writing memory with integer types and casting.
>> 
>> Options?  My thought, after some internal discussion, is that (if the
>> target chooses) we allow gcc to honor the type of a volatile bitfield
>> as the mode as long as it can do so without otherwise violating the
>> structure's layout.  Some new hook will be needed for the backend, and
>> perhaps a -W option for when the type cannot be honored.
>> 
>> I.e. if the programmer is careful enough to properly lay out the
>> struct, the programmer should get what the programmer asks for.
>> 
>> Comments?  Alternatives?


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.  gcc doesn't even
document the order of bits in a bitfield, so it's generally difficult to
reliably use bitfields to access memory mapped registers.  If this were
my customer, I would tell them to write inline functions which access
the data as integers of the appropriate size and do the required
shifting and masking.  That code only has to be written once, it will be
just as efficient as the code generated by using a volatile bitfield
struct, and it will be clearly correct with any reasonable compiler.

A volatile bitfield is a dubious construct all by itself.  The volatile
qualifier is supposed to direct the compiler to act exactly like the
virtual machine.  But what does the virtual machine do on an assignment
to a volatile bitfield?  Many real machines must read the value, change
some bits, and then write the value back.  Is that following the virtual
machine or not?  Is the volatile qualifier misleading in such a case?

In any case, while I recommend against it, I won't stop you if you
really want to follow your proposal.  The most important thing for this
approach would be the documentation, so write that first.  Your brief
description above is insufficient; I'm not sure what you mean by
"without otherwise violating the structure's layout," and I don't know
why you might need a -W option.  Then, of course, you will need a fairly
complete set of test cases.


I want to say that I think that this comment:

>> I.e. if the programmer is careful enough to properly lay out the
>> struct, the programmer should get what the programmer asks for.

is misleading.  When I give a type to a bitfield, I don't think I am
asking for the bitfield to be accessed in that type.  It's not a case of
the programmer getting what he or she asks for; it's a case of the
programmer wants to define a specific set of semantics to bitfields, a
language construct which can provide a range of different semantics.

Ian

Re: bitfields: types vs modes?

[Mark Mitchell]

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 part, because of the ARM ABI issue, I think we ought to accept
patches that fix this problem.  It's true that GCC doesn't in general
document these semantics, but users of some ABIs have expectations about
how volatile bitfields will work.

DJ, I'd suggest you look at:

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 them.  If not, there may be still be some common parts.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: bitfields: types vs modes?

[DJ Delorie]

> 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 them.  If not, there may be still be some common parts.

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?  Should we take into
consideration adjacent field types, or the type's natural alignment?
What if the field spans natural alignment boundaries?  What if the
larger-than-field access exceeds the memory region and causes a fault?

For example, in this case, when we access x.b does it also read a, or
c?  Will reading x.d cause a segment fault?

volatile struct {
	char a:8;
	int b:24;
	char c:8;
	int d:8;
	} x;

We need to figure out how much information we should pass to the
target to let it make these decisions, if it needs to.  A common
function to do by-type access could be called from your target and
mine.

Re: bitfields: types vs modes?

[Mark Mitchell]

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 that they're there, but the intent is the
types' natural alignment.  All "int" bit-fields in that ABI are located
within a 32-bit aligned range of memory; the intent is that you
read/write that entire 4-byte range.  In other words, take the byte
address of the start of the bit-field, mask off the two low-order bits,
that's the 4-byte address to read.

On an ARM, you can never cross a protection boundary in that way; you're
never going to get a SEGV from the bytes you read in that way if you
wouldn't have gotten one from the byte containing the start of the
bit-field.  Protection is done at the page (or cache-line, I forget)
boundary; in either case, the granularity of protection is greater than
the granularity of any basic type.  And, if it's not, that's your
problem; the ABI semantics of a volatile bit-field of type T are that
you get sizeof(T) bytes, and if it blows up (which I don't think it
can), it's not the compiler's fault.

If you have an ABI where an int bit-field can cross a sizeof(int)-byte
boundary, that's a harder case.  That can happen on ARM with GCC's
packed-structure extension, but that's outside the ARM ABI, and
therefore the behavior is not specified.

> We need to figure out how much information we should pass to the
> target to let it make these decisions, if it needs to.  A common
> function to do by-type access could be called from your target and
> mine.

I'd like to know how many of the assumptions above are valid on your
target.  I would imagine that many of them are.  In which case, the
existing hook is good enough; we just need to implement middle-end
behavior depending on the hook.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: bitfields: types vs modes?

[DJ Delorie]

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, common code can be shared between the CPUs

Re: bitfields: types vs modes?

[Ian Lance Taylor]

DJ Delorie <dj@redhat.com> writes:

> 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, common code can be shared between the CPUs

Since the ARM ABI apparently specifies something about volatile
bitfields, I think we ought to implement that.

I continue to think that a sane programmer would use a different
mechanism.  C/C++ provides mechanisms for working with memory mapped
hardware.  Bitfields are not one of those mechanisms.

Ian

Re: bitfields: types vs modes?

[Mark Mitchell]

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 think we ought to implement that.

Yes, we should.  I am aware of real user demand for this feature as
well.  It's a competitive disadvantage for GCC not to have this feature.

> I continue to think that a sane programmer would use a different
> mechanism.  C/C++ provides mechanisms for working with memory mapped
> hardware.  Bitfields are not one of those mechanisms.

I think the ARM specification is pretty sensible, and would make a good
cross-platform approach.  Using bit-fields may not be portable at
present, but it would sure be nice if it was; it maps directly onto how
people think about memory-mapped peripherals.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: bitfields: types vs modes?

[DJ Delorie]

> 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.

Re: bitfields: types vs modes?

[Mark Mitchell]

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 corner-case for C++ bit-fields that are bigger than their
declared type, but don't worry about that.)  So "int i:6" has a 32-bit
container, whereas "char c:6" has an 8-bit container.

(In the ARM ABI, a bit-field never crosses a container boundary; "struct
{ char c1:6; char c2:3}" puts "c2" completely into the second byte, not
straddling the first two bytes.  But, if those were int bit-fields, then
the second bit-field would straddle the two bytes.  Packed structures
are outside the scope of the ABI.)

> When a volatile bit-field is read, its container must be read exactly
> once using the access width appropriate to the type of the container.
>  When a volatile bit-field is written, its container must be read
> exactly once and written exactly once using the access width
> appropriate to the type of the container. The two accesses are not
> atomic.

> Multiple accesses to the same volatile bit-field, or to additional
> volatile bit-fields within the same container may not be merged. For
> example, an increment of a volatile bit-field must always be
> implemented as two reads and a write.

> Note the volatile access rules apply even when the width and
> alignment of the bit-field imply that the access could be achieved
> more efficiently using a narrower type. For a write operation the
> read must always occur even if the entire contents of the container
> will be replaced.

> If the containers of two volatile bit-fields overlap then access to
> one bit-field will cause an access to the other. For example, in
> struct S {volatile int a:8; volatile char b:2}; an access to a will
> also cause an access to b, but not vice-versa.

> If the container of a non-volatile bit-field overlaps a volatile
> bit-field then it is undefined whether access to the non-volatile
> field will cause the volatile field to be accessed.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: bitfields: types vs modes?

[DJ Delorie]

> >> 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 AAPCS functionality is suitable for their
ports as well.

What's the next step?

Re: bitfields: types vs modes?

[Mark Mitchell]

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 step?

At the risk of being naive: implement it.  I'm not quite sure what
you're looking for here?

I'd assume that we should try to do some of this at the tree->rtl
conversion point, in a platform-independent manner, but I'm not an
expert on those bits.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: bitfields: types vs modes?

[DJ Delorie]

> 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
target now.

Re: bitfields: types vs modes?

[DJ Delorie]

> 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 getting
out of hand.  Is there some easier way to track the type that an rtx
came from?  Perhaps we could call get_best_mode() earlier in the whole
process, and put that mode in the rtx instead of BLKmode ?