[cpp-threads] Memory model counterproposal: bit-fields

Nelson, Clark clark.nelson at intel.com
Thu May 26 19:44:24 BST 2005


I've talked to some code-generator people at Intel, and they are really
not at all wild about the idea of splitting up bit-field assignments
into multiple stores. In the worst-case scenario:

struct { char a; long long b:48; char c; };

a single bit-field assignment would have to be broken up into (at least)
four stores, with associated shifts. That's a pretty high overhead.

The tightest rule I can imagine that might gain consensus would include
not only all adjacent bit-fields, but also all adjacent fields of any
type smaller than the declared type of the bit-field. So in a typical
implementation, in an assignment to an int bit-field, adjacent shorts
and chars might also be written. In an assignment to a short bit-field,
only adjacent chars might be written.

It'd be nice if we could guarantee that only nearby fields with integer
type might be clobbered. Unfortunately, with a long long bit-field, in
typical implementations even pointers and floats might be affected. And
in any case there are also small structs.

There are also some challenges associated with formulating this rule in
standardese. Specifically, what's "smaller"? Should short be considered
smaller than int unconditionally, or only in an implementation where
they do in fact differ in size?

Also, what's "adjacent"? This is actually quite sticky. The standard
clearly intends to allow ABIs where the order of allocation of fields is
dependent on their accessibility, even though I am not aware of any (and
I certainly don't have to implement any). In such an ABI it may be quite
involved to determine, from a given class definition, which fields wind
up allocated adjacent to one another (which of course is the real
concern).

For this and other reasons, I personally would be satisfied with a rule
that said that any field of a struct object might be written on
assignment to any other field of that object. But I don't imagine I'd be
in the majority in a vote on that proposal.

-- 
Clark Nelson		Vice chair, J16 (ANSI C++ standard committee)
Intel Corporation
clark.nelson at intel.com




More information about the cpp-threads mailing list