This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]


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;



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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]