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
m...@codesourcery.com
(650) 331-3385 x713
