From owner-svn-src-projects@FreeBSD.ORG Thu May 12 20:05:15 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 C2BB4106566C; Thu, 12 May 2011 20:05:15 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 27A678FC16; Thu, 12 May 2011 20:05:14 +0000 (UTC) Received: by ywf7 with SMTP id 7so840712ywf.13 for ; Thu, 12 May 2011 13:05:14 -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=5Nh1Kcky7d9GfanfqxxazLIWMP628CdVceGtbslN7aU=; b=l3zlP27SaxJKb8r1LivxNjBoMMbRlhknyZBjZDYWmRdX5SsJFgkJdfpN4LX0LAyMs1 BOTEsn2zyaophbMYvA74fzpxb1eQlrknvO5ijgE2P5GnM1CoNKU9Mfnt75ZgQbF63+Nn +ukk7gxaXeZigVgqT0IW8ALhcIU7c6hPK0nsw= 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=gXmtlTPijWVkpu77IaYUToPXWn6FHQU7Db1Wau2sL5bFhaUIqmDnZWN2zM6aJ4WwGA J1jTo9sqTmcM+o7cMyokWD/vDinojs116arCjbFhJyMb+xH0i1XjD5t8HC/DKZkbSkgR iNHk1zgr3fo7dt1YW8HUNZYPjhIXzdQO2kBqE= MIME-Version: 1.0 Received: by 10.236.153.161 with SMTP id f21mr769266yhk.37.1305230713492; Thu, 12 May 2011 13:05:13 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.236.111.33 with HTTP; Thu, 12 May 2011 13:05:13 -0700 (PDT) In-Reply-To: References: <201105080039.p480doiZ021493@svn.freebsd.org> Date: Thu, 12 May 2011 22:05:13 +0200 X-Google-Sender-Auth: nX85gUS-rJnOKTiu5kxV_7ovvpk 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 20:05:15 -0000 2011/5/12 Attilio Rao : > 2011/5/12 Attilio Rao : >> 2011/5/12 Artem Belevich : >>> On Thu, May 12, 2011 at 3:22 PM, Attilio Rao wrot= e: >>>> 2011/5/12 Artem Belevich : >>>>> On Thu, May 12, 2011 at 5:15 AM, Attilio Rao wr= ote: >>>>>> 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, ui= nt64_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 missin= g 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. I spoke in person with Artem and in the end I just decided to make the smallest possible subset of changes to fix the _long on 32 bits and then "completed" (as some of them already exist today) the macro converting the arguments to u_int stuff: http://www.freebsd.org/~attilio/largeSMP/mips-atomic2.diff I compiled several kernels for MIPS (with sparse configurations and they all compile well). If you agree with this patch, tonight I'll commit to my tree and add the mips support for cpuset_t soon, so that it all can be tested. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein