Date: Mon, 9 May 2011 02:17:31 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Attilio Rao <attilio@FreeBSD.org> Cc: svn-src-projects@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r221614 - projects/largeSMP/sys/powerpc/include Message-ID: <20110509020034.E2292@besplex.bde.org> In-Reply-To: <BANLkTim_kNZJZxVe1%2BWFPjL5-4oVUORo1Q@mail.gmail.com> References: <201105080039.p480doiZ021493@svn.freebsd.org> <20110508202725.K1192@besplex.bde.org> <BANLkTim_kNZJZxVe1%2BWFPjL5-4oVUORo1Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1450297231-1304871451=:2292 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sun, 8 May 2011, Attilio Rao wrote: > 2011/5/8 Bruce Evans <brde@optusnet.com.au>: >> >> I think that it is mostly the other arches that are backwards here, >> except for plain ints. =C2=A0MI code cannot use atomic ops for anything >> except plain ints, since no other type is guaranteed to be supported >> by the MD code. =C2=A0For 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 unsup= ported: > - _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 --0-1450297231-1304871451=:2292--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110509020034.E2292>