Date: Fri, 13 May 2011 22:17:49 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Artem Belevich <art@freebsd.org> Cc: src-committers@freebsd.org, Attilio Rao <attilio@freebsd.org>, Oleksandr Tymoshenko <gonzo@freebsd.org>, Bruce Evans <brde@optusnet.com.au>, svn-src-projects@freebsd.org, Warner Losh <imp@freebsd.org> Subject: Re: svn commit: r221614 - projects/largeSMP/sys/powerpc/include Message-ID: <20110513220640.T1035@besplex.bde.org> In-Reply-To: <BANLkTinaWDcaiZiB3G5Szoaho1jVSeniMA@mail.gmail.com> References: <201105080039.p480doiZ021493@svn.freebsd.org> <BANLkTi=e7GtBM-PTq9yJHSLRoaOWh62AeA@mail.gmail.com> <BANLkTiktwEvRktZrGOqKKB2iSB99a3Jw=g@mail.gmail.com> <BANLkTik17r-XampEdO%2BsQ7aMOL_SDyhG=g@mail.gmail.com> <BANLkTinaWDcaiZiB3G5Szoaho1jVSeniMA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 12 May 2011, Artem Belevich wrote: > On Thu, May 12, 2011 at 3:22 PM, Attilio Rao <attilio@freebsd.org> wrote: >> 2011/5/12 Artem Belevich <art@freebsd.org>: >>> On Thu, May 12, 2011 at 5:15 AM, Attilio Rao <attilio@freebsd.org> wrote: >>>> 2011/5/8 Attilio Rao <attilio@freebsd.org>: >>>> mips seems having the same issue, so here is my patch: >>>> http://www.freebsd.org/~attilio/largeSMP/mips-atomic.diff >>> >>> I see at least one problem. N32 ABI is ILP32 even though it can use >>> 64-bit registers for "long long". >> >> I'm sorry but this _longlong is non standard for our atomic scheme, >> nothing in the kernel uses it and in general I'd say to not add them >> if not strictly necessary. It also uses the long long abomination. Apart from being broken as designed, using it gives the same sorts of unportortabilities as does using long long, but slightly more so. E.g., uint64_t and even uintmax_t is plain u_long on all 64 bit arches. Thus unsigned long long on these arches is incompatable with every useful type, and using it gives mainly type mismatches. >> Said that, in the -CURRENT code it doesn't seem present, or I'm missing it? It would also be unusual in MI code, since most arches can't have it. Unlike u_long, for 32-bit arches it actually is twice the bus width like u_long should be, and is thus inherently non-atomic. > The key is that N32 ABI does use 64-bit registers and can perform > 64-bit atomic ops. > Unfortunately, 64-bit type is long long or [u]int64_t. The point is > that it's not *long*. register_t or bus_width_t or even max_atomic_t (like sig_atomic_t, except the latter shouldn't be maximal), might be the correct encoding of this capability for MI code. >> I'm not entirely sure in which way the above is different... or at >> least, I may have overlooked the _long support for __mips_n32... can >> you please elaborate a bit more? > > The inline assembly for atomic_set_long above uses 64-bit load/store. > This is not going to work for 32-bit long in N32 ABI. But does anything actually use the 64-bit capabilities in a 32-bit arch? >>> I think for mips sticking with atomic_*_<size> would be a better fit >>> considering ABI zoo we potentially have to deal with. >> >> Actually you still have them, it is just the dipendency that changes. MI current code can't tell whether any particular size works. Currently, it can only safely assume that size 32 works (this is documented, and so is the working of size 64, but size 64 doesn't actually work). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110513220640.T1035>