From owner-svn-src-projects@FreeBSD.ORG Thu May 12 17:41:34 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 999221065670; Thu, 12 May 2011 17:41:34 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id F375A8FC12; Thu, 12 May 2011 17:41:33 +0000 (UTC) Received: by gwb15 with SMTP id 15so773925gwb.13 for ; Thu, 12 May 2011 10:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HfakOng1dUPRRsLl/XgQMBsgW/Ztk2tG0NS7lm1b02c=; b=RWQ2YE9acQLiLYrMZOtQ6sdU9WY+sEfFfvxzKz5bnZ/MBY6tUb4vUQRdHccqDYbGkY /MTSwdpPiBXSrBO5vj9ScGLmQfLNkOZF3vxORj63jDY8qz6MgQQ5YXPGkeKLfknROkNT /LZUz3DtJK5v1RNgXy+R003+6ONxQzrIJ+Q9w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=BpY1cq7mQsTGWWZcG62zMWSTZmhPLxKYko3LaCRFRkUvGGz4biufloHjnmegFOV+Hb sMbubD9oJ27yAA9rleySDBrAwqbCoIAN4ZPxo4tVa1N+7uDsIQorvc3uH/9NGxhle309 AzOgVg5TDzaeR+uSxB1CNT0Q/VwU0ykEDUaR0= MIME-Version: 1.0 Received: by 10.236.161.197 with SMTP id w45mr630979yhk.104.1305222093023; Thu, 12 May 2011 10:41:33 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.236.111.33 with HTTP; Thu, 12 May 2011 10:41:32 -0700 (PDT) In-Reply-To: References: <201105080039.p480doiZ021493@svn.freebsd.org> Date: Thu, 12 May 2011 19:41:32 +0200 X-Google-Sender-Auth: maDxMwkEmeMEWWCrDdjW4KzbF30 Message-ID: From: Attilio Rao To: Artem Belevich Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: svn-src-projects@freebsd.org, Oleksandr Tymoshenko , src-committers@freebsd.org, Warner Losh , Bruce Evans 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: Thu, 12 May 2011 17:41:34 -0000 2011/5/12 Attilio Rao : > 2011/5/12 Artem Belevich : >> 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 wro= te: >>>>> 2011/5/8 Attilio Rao : >>>>>> Author: attilio >>>>>> Date: Sun May =C2=A08 00:39:49 2011 >>>>>> New Revision: 221614 >>>>>> URL: http://svn.freebsd.org/changeset/base/221614 >>>>>> >>>>>> Log: >>>>>> =C2=A0All architectures define the size-bounded types (uint32_t, uin= t64_t, etc.) >>>>>> =C2=A0starting from base C types (int, long, etc). >>>>> >>>>> 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. >>> Said that, in the -CURRENT code it doesn't seem present, or I'm missing= it? >> >> 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*. >>> >>>>> #if defined(__mips_n64) || defined(__mips_n32) >>>>> static __inline void >>>>>-atomic_set_64(__volatile uint64_t *p, uint64_t v) >>>>>+atomic_set_long(__volatile u_long *p, u_long v) >>>> >>>> Using _long here would not match the assembly on N32. >>>> >>>> If you stick with your changes, then you should drop __mips_n32 from >>>> the ifdef above. >>>> You may also want to add atomic_*_longlong for n32. Actually, for o64 = as well. >>> >>> 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. > > That cames from my mips assembly ignorance, I apologize. > I just gave a look at types.h and what it just I basically see is: > - __mips_n32 is just the same as plain !__mips_n32 && !__mips_n64 > - __mips_n64 just addes the operations for 64 bits operands Oh, yeah, I forgot this part. - __mips_n32 should be able to crunch the _64 variants, while probabilly the !__mips_n32 && !__mips_n64 doesn't > Thus what I need to make sure is: > - __mips_n32 (and !__mips_n32 && !__mips_n64) case work on 32 bits > operand on long too > - __mips_n64 works on 64 bits long operands - That __mips_n32 also defines the _64 variants. Attilio --=20 Peace can only be achieved by understanding - A. Einstein