svn commit: r221614 - projects/largeSMP/sys/powerpc/include

[Bruce Evans]

On Sun, 8 May 2011, Attilio Rao wrote:

> 2011/5/8 Bruce Evans <brde at optusnet.com.au>:
>>
>> I think that it is mostly the other arches that are backwards here,
>> except for plain ints. Â MI code cannot use atomic ops for anything
>> except plain ints, since no other type is guaranteed to be supported
>> by the MD code. Â For example, sparc64 doesn't support any 8-bit or
>> 16-bit types, and i386 doesn't support any 64-bit types (until recently;
>> it now uses cmpxchg8b on some CPUs and a hack on other CPUs to support
>> 64, bit types), and my version of i386 doesn't support any 8-bit or
>> 16-bit types or long since these types are unusable in MI code and
>> unused in MD code (long is misused in some MI code but I don't use
>> such broken code).
>
> I want to comment specifically on this.
> I think you are right and that over time our kernel policy on atomic
> has got very flakey.
> My personal idea is that MI part should support only this:
> - _int version
> - _32 bit version
> - _ptr version
>
> and the common sense also mandates it could support easilly:
> - _long version
>
> The following should just be used in specific MD code or be totally unsupported:
> - _char, _short, _8 bit, _16 bit versions
>
> The following should just be used in MD code:
> - _64 bit version

This agrees exactly with my policy, except I think 64-bit types should
be prepared for, and supported when it is easy (about the same as long
if longs are 64 bits).

atomic(9) agrees with this for the _char, _short, _8 bit, _16 bit versions.
It disagrees for:
- unsigned long: says that full support is always available.  Correct, but
   inhibits expanding long.
- uint64_t: says that full support is always available.  Was just wrong on
   i386 until recently.  i386 now has support for load/store only.
   Apparently still just wrong for powerpc32.

Bruce