atomic accesses

[Segher Boessenkool]

>>>>>> The Linux kernel, and probably some user-space applications and 
>>>>>> libraries
>>>>>> as well, depend on GCC guaranteeing (a variant of) the following:
>>>>>> 	"any access to a naturally aligned scalar object in memory
>>>>>> 	that is not a bit-field will be performed by a single machine
>>>>>> 	instruction whenever possible"
>>>>>> and it seems the current compiler actually does work like this.
>>>>> Seems a pity to have the bit-field exception here, why is it there?
>>>> Bit-fields will generally require a read-modify-write instruction,
>>>> and I don't think we actually guarantee to generate one right now.
>>> Well if they do require more than one instruction, the rule has
>>> no effect ("whenever possible"). If they can be done in one
>>> instruction  (as on the x86), then why not require this, why
>>> make a special case?
>> Because current GCC doesn't work like this AFAIK.  I'm aiming for
>> a documentation-only change here, we can always extend it later.
>
> Fair enough, we don't want to document something we don't do!
>
> Does this rule extend to the use of floating-point instructions
> to guarantee atomic access to 64-bit long_long_integer, as
> written it does!

Good point.  Suggestions for better wording?  How does

	"any access to a naturally aligned scalar object in memory
	that is not a bit-field and fits in a general purpose integer
	machine register, will be performed by a single machine
	instruction whenever possible"

or

	"any access to a naturally aligned scalar object in memory
	that is not a bit-field and not bigger than a long int,
	will be performed by a single machine instruction whenever
	possible"

sound?


Segher