Date: Sun, 8 May 2011 10:44:04 -0400 From: Attilio Rao <attilio@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r221614 - projects/largeSMP/sys/powerpc/include Message-ID: <BANLkTim_kNZJZxVe1%2BWFPjL5-4oVUORo1Q@mail.gmail.com> In-Reply-To: <20110508202725.K1192@besplex.bde.org> References: <201105080039.p480doiZ021493@svn.freebsd.org> <20110508202725.K1192@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2011/5/8 Bruce Evans <brde@optusnet.com.au>: > On Sun, 8 May 2011, Attilio Rao wrote: > >> Log: >> =C2=A0All architectures define the size-bounded types (uint32_t, uint64_= t, >> etc.) >> =C2=A0starting from base C types (int, long, etc). >> =C2=A0That is also reflected when building atomic operations, as the >> =C2=A0size-bounded types are built from the base C types. >> >> =C2=A0However, powerpc does the inverse thing, leading to a serie of nas= ty > > I think you mean that it does the inverse thing for atomic ops only. > >> =C2=A0bugs. >> =C2=A0Cleanup the atomic implementation by defining as base the base C t= ype >> =C2=A0version and depending on them, appropriately. > > 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 unsuppo= rted: - _char, _short, _8 bit, _16 bit versions The following should just be used in MD code: - _64 bit version I'm not entirely sure what would be the impact on the current kernel of this scheme, but maybe with some luck this is how it is already got. Someone interested can check that. Attilio --=20 Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTim_kNZJZxVe1%2BWFPjL5-4oVUORo1Q>