>>>>> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
>> We don't have atomic read or atomic write builtins (ok, you could
>> abuse __sync_fetch_and_add (&x, 0) for atomic read and a loop with
>> __sync_compare_and_swap_val for atomic store, but that's a
>> horrible overkill. Being able to assume that for non-bitfield
>> accesses bigger than certain minimum size, smaller or equal to the
>> word size and naturally aligned the compiler will read or write a
>> value in one lump is certainly desirable and many programs assume
>> it heavily (starting with glibc, kernel, libgomp, ...).
Andrew> That seems reasonable, but I suspect that coming up with
Andrew> wordage to describe it sufficiently formally for all cases
Andrew> will be tricky.
Probably so. In any case, clearly no such wordage could include the
phrase "when possible".
Andrew> AFAIK the only reason we don't break this rule is that doing
Andrew> so would be grossly inefficient; there's nothing to stop any
Andrew> gcc back-end with (say) seriously slow DImode writes from
Andrew> using two SImode writes instead.
Or, say, because you're using the MIPS O32 ABI rather than the N32/N64
ABI... which is yet another example why a formal rule is tricky.
>> The "certain minimum size" is typically either size of char, or
>> (e.g. on old alphas) size of int.
Not just old Alphas. Even if the instruction set has a "store
character" opcode, the hardware is going to do a read-modify-write
internally; is that an atomic operation? Not necessarily. Perhaps
even "only rarely".
paul
