From owner-svn-src-projects@FreeBSD.ORG Fri May 13 12:17:52 2011 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63FAD106566B; Fri, 13 May 2011 12:17:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id EF8608FC13; Fri, 13 May 2011 12:17:51 +0000 (UTC) Received: from c122-106-158-76.carlnfd1.nsw.optusnet.com.au (c122-106-158-76.carlnfd1.nsw.optusnet.com.au [122.106.158.76]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p4DCHnlM027423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 May 2011 22:17:49 +1000 Date: Fri, 13 May 2011 22:17:49 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Artem Belevich In-Reply-To: Message-ID: <20110513220640.T1035@besplex.bde.org> References: <201105080039.p480doiZ021493@svn.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@freebsd.org, Attilio Rao , Oleksandr Tymoshenko , Bruce Evans , svn-src-projects@freebsd.org, Warner Losh Subject: Re: svn commit: r221614 - projects/largeSMP/sys/powerpc/include X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 12:17:52 -0000 On Thu, 12 May 2011, Artem Belevich wrote: > On Thu, May 12, 2011 at 3:22 PM, Attilio Rao wrote: >> 2011/5/12 Artem Belevich : >>> On Thu, May 12, 2011 at 5:15 AM, Attilio Rao wrote: >>>> 2011/5/8 Attilio Rao : >>>> 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_*_ 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