Bitfields

Bitfields

[Zoltán Kócsi]

I wonder if there would be at least a theoretical support by the
developers to a proposal for volatile bitfields:

When a HW register (thus most likely declared as volatile) is defined as
a bitfield, as far as I know gcc treats each bitfield assignment as a
separate read-modify-write operation. Thats is, if I have a 32-bit
register with 3 fields

struct s_hw_reg {

 int field1 : 10,
     field2 : 10,
     field3 : 12;

};

then

reg.field1 = val1;
reg.field2 = val2;

will be turned into a fetch, mask, or with val1, store, fetch, mask, or
with val2, store sequence. I wonder if there could be a special gcc
extension, strictly only when a -f option is explicitely passed to the
compiler, where the comma operator could be used to tell the compiler
to concatenate the operations:

reg.field1 = val1, reg.field2 = val2;

would then turn into fetch, mask with a combined mask of field1 and
field2, or val1, or val2, store.

Since the bit field operations can not be concatenated that way
currently, and quite frequently you want to change multiple fields in a
HW register simultaneously (i.e. with a single write), more often
than not you have to give up the whole bit field notion and define
everything like

#define MASK1 0xffc00000
#define MASK2 0x003ff000
#define MASK3 0x00000fff

and so on, then you explicitely write the code that fetches, masks
with a compined mas, or-s with a combined field value set and stores. A
lot of typing could be avoided with the bitfields, not to mention that
it would be a lot more elegant, if one could somehow coerce the compiler
to be a bit more relaxed regarding to bitfield access. Actually
'relaxed' is not a good word, because I would not want the compiler to
have a free reign in the access: if there's a semicolon at the end of
the assignment operator expression, then do it bit by bit, adhering
the standard to its strictest. However, the comma operator, and only
that operator, and only if both sides of the comma refer to bit fields
within the same word, and only if explicitely asked by a command line
switch, would tell the compiler to combine the masking and setting
operations within a single fetch - store pair.

Is it a completely brain-dead idea?

Zoltan

Re: Bitfields

[Paolo Bonzini]

> reg.field1 = val1, reg.field2 = val2;
>
> would then turn into fetch, mask with a combined mask of field1 and
> field2, or val1, or val2, store.

You can also do the RMW yourself: declare the register volatile, but not 
the fields of it, and copy in/out of the register manually.

volatile struct reg x;

...
{
   struct reg mine = x;
   mine.field1 = true;
   mine.field2 = 0;
   mine.field3++;
   x = mine;
}

> Is it a completely brain-dead idea?

If I understood it correctly, it would not be standard compliant.

Paolo

Re: Bitfields

[Robert Dewar]

Paolo Bonzini wrote:

>> Is it a completely brain-dead idea?
> 
> If I understood it correctly, it would not be standard compliant.

But it's an extension, so I don't see that is an issue of itself.
> 
> Paolo

Re: Bitfields

[Joseph S. Myers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 508 bytes --]

On Sun, 20 Sep 2009, Zoltán Kócsi wrote:

> I wonder if there would be at least a theoretical support by the
> developers to a proposal for volatile bitfields:

It has been proposed (and not rejected, but not yet implemented) that 
volatile bit-fields should follow the ARM EABI specification (on all 
targets); that certainly seems better than inventing something new unless 
you have a very good reason to prefer the something new on some targets.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Bitfields

[zoltan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 4385 bytes --]

On Sun, 20 Sep 2009, Joseph S. Myers wrote:

> On Sun, 20 Sep 2009, Zoltán Kócsi wrote:
>
> > I wonder if there would be at least a theoretical support by the
> > developers to a proposal for volatile bitfields:
>
> It has been proposed (and not rejected, but not yet implemented) that
> volatile bit-fields should follow the ARM EABI specification (on all
> targets); that certainly seems better than inventing something new unless
> you have a very good reason to prefer the something new on some targets.

Yes, that discussion was that made me thinking and suggesting this
*before* the ARM EABI gets implemented. I don't suggest to implement
something instead of the ARM EABI, I suggest to implement something on top
of it. The suggested behaviour is also architecture-neutral.

It is nothing more than if the user expressly asks the compiler to break
the standard in a particular way, then the compiler does so. The breaking
of the standard is at one single point. The ARM EABI spec clearly states
that bitfield operations are never to be combined, not even in the case
where consecutive bitfield assignments refer to bitfields located in the
same machine word. My suggestion was that if a new command line switch is
present, then in the special case of consecutive bitfield assignments
being made to fields within the same word and the assignments being
separated by the comma operator, then the compiler combines those
assignments. The rationale of such behaviour is writing low-level code
dealing with HW registers. To have a practical example, let's have a SoC
chip with multi-function pins. Let's assume that we have a register that
has 2 bits for each actual pin and the value of the 2 bits selects the
actual function for the pin; a 32 bit register can thus control 16 pins.
Now if you want to, say, assign 4 pins to the SPI interface, without
bitfields you would (and indeed do) write something along these lines:

temp = *pin_control_reg;
temp &= ~(PIN_03_MASK | PIN_04_MASK | PIN_05_MASK | PIN_06_MASK);
temp |= PIN_O3_MISO | PIN_04_MOSI | PIN_05_SCLK | PIN_06_SSEL;
*pin_ctrl_reg = temp;

You can't really use bitfields to achieve the above, because if you write

pin_control_reg->pin_03 = MISO;
pin_control_reg->pin_04 = MOSI;

and so on, pin_xx being 2-bit wide bitfields, then according to the ARM
EABI spec each statement would be translated to a temp = *pin_contorl_reg;
temp &=...; temp |=...;  *pin_control_reg=temp; sequence. What I suggest
is that if you write

pin_control_reg->pin_03 = MISO,	// Note the comma
pin_control_reg->pin_04 = MOSI,
pin_control_reg->pin_05 = SCLK,
pin_control_reg->pin_06 = SSEL;

and compile it with a -fcomma-combines-bitfields switch, then you get the
equivalent of the first code fragment where you manually combined the
masks and the settings and only a single load and a single store was used.

If the switch is not given or the consecutive assignments are not
separated by commas or the bitfields do not belong to the same word, then
the behaviour falls back to the default ARM EABI spec.

The advantage of the suggested behaviour is that it would allow the use of
the more elegant and expressive bitfields in place of the many hundreds of
#define REGNAME_FIELDNAME_MASK and #define REGNAME_FIELDNAME_SHIFT macros
that you can currently find in code that deals with HW. The suggestion
does not introduce any new functionality or performance advantage, it just
provides a way of writing (in my opinion) more readable and more
maintainable code than what we have now with all the #defines. The fact
that structure members live in their own namespace as opposed to the
global #define namespace is an added benefit, of course.

The suggested extension does not break backward compatibility, because the
#define stuff would not be affected and the ARM EABI is not yet
implemented anyway; it would not break the expected behaviour because it
becomes active only when an explicite command line switch is given and has
no side-effects outside the single expression where the subexpressions are
separated by commas.

The change, I believe, would benefit gcc users who deal with HW a lot,
i.e. low level embedded system and device driver designers. Outside of
that circle the suggested behavior would have only a little performance
benefit.

Zoltan

Re: Bitfields

[DJ Delorie]

"Joseph S. Myers" <joseph@codesourcery.com> writes:
> It has been proposed (and not rejected, but not yet implemented)

I'm still working on it...