From owner-svn-src-projects@FreeBSD.ORG Thu May 12 17:30: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 56366106566B; Thu, 12 May 2011 17:30: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 B58548FC13; Thu, 12 May 2011 17:30:33 +0000 (UTC) Received: by gwb15 with SMTP id 15so768324gwb.13 for ; Thu, 12 May 2011 10:30: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=KMG5QOTeW+StcNAkyaBIhEe4Jz3AVWAyxuLgKJKLSk8=; b=KqjdC1kQp9z7aUrF8M+hvnVonV5yxllNbmjnu9/Y/e5vTTGq8ZrZdGc+kaOxG1Dhti Rg0Dd8MoIH/5RILG3MJ0gmq+QqSHm6US4iFNJWk85cuGnMW0fujbrmunxGSY10K5GBvm wRA1OqlUFXbPw++ojaSVM1hs2PHcHJxmO1OR0= 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=PJnazh+FntpTm85qb498QcpJf12x4RBNZzK1ckXturkUbTtlSr7IsYpoxuXzDB8y2V wd7zZ8JdK98dpQqeh0N6jeHyZ4CxMVSNkvQT6EWEiGxnuptVAELiXMiA2cOgLUhScCAN mQOtakiLRTkWWVe2WfkKILAhUPNesvd9ffqY4= MIME-Version: 1.0 Received: by 10.236.180.36 with SMTP id i24mr543541yhm.305.1305221432767; Thu, 12 May 2011 10:30:32 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.236.111.33 with HTTP; Thu, 12 May 2011 10:30:32 -0700 (PDT) In-Reply-To: References: <201105080039.p480doiZ021493@svn.freebsd.org> Date: Thu, 12 May 2011 19:30:32 +0200 X-Google-Sender-Auth: htVGEWqmD731UZK3oeD0lyR2xjU 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:30:34 -0000 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 wrot= e: >>>> 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, uint= 64_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 a= s 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 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 Do you have a specifi opinion on _char/_short operands? Do you have strong feeling on the _longlong stuff? Do you think it will be useful in mips? About the last question I think that it would be more fair to use _64 directly, when possible. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein