From owner-svn-src-projects@FreeBSD.ORG Thu May 12 14:49: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 3E3D5106566B; Thu, 12 May 2011 14:49:34 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8A37D8FC19; Thu, 12 May 2011 14:49:33 +0000 (UTC) Received: by qyk27 with SMTP id 27so1101610qyk.13 for ; Thu, 12 May 2011 07:49:32 -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=U9PoVfiZd3xSG2iQ2QXIjukR3XDIcMDpb+wfBjjYhYk=; b=gP64qoIlnK/bBSWX2iO5XYTkPgXnQjqcxlh3fqC/mLZx+I17UR297KQwaNxn5v0ej9 V3CCn8vRWDdK74FxWGY6FiGnIYRtO6HBV+C3rG+akZLisl7H2d1NRLDQCpwpjCOMfHGG bPD8Zp0n5VDe7LZCYQUMQKrMlM5X2m9a1JeT0= 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=xjTsoaNs9cZTaLMw/56wIcnyeYSmcH/7D0XRNynse5ZBtY4e0CB3VuJDR+X3xOu7Jo qaMQlMFD2RxJkuTqdImVU33nXKqJddn1rZcFbSFlLVqBHWNxPrShjuzkqVdrSfeEsmRQ PDnFJ/hL3CR3WjelwibCbttRwpP8BzsFfTitI= MIME-Version: 1.0 Received: by 10.229.27.193 with SMTP id j1mr251323qcc.82.1305211772448; Thu, 12 May 2011 07:49:32 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.229.95.140 with HTTP; Thu, 12 May 2011 07:49:32 -0700 (PDT) In-Reply-To: References: <201105080039.p480doiZ021493@svn.freebsd.org> Date: Thu, 12 May 2011 16:49:32 +0200 X-Google-Sender-Auth: xD_-Xtk_1auLPAlLlhrcmY-N05Q Message-ID: From: Artem Belevich To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 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 14:49:34 -0000 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 : >>>> Author: attilio >>>> Date: Sun May =A08 00:39:49 2011 >>>> New Revision: 221614 >>>> URL: http://svn.freebsd.org/changeset/base/221614 >>>> >>>> Log: >>>> =A0All architectures define the size-bounded types (uint32_t, uint64_t= , etc.) >>>> =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 i= t? 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. > >> 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. In the end you can do it either way, true. What I am trying to point is that atomic ops are ususally involve fair amount of assembly code where it's operand *size* is what matters, not what is the name of the scalar of that size in particular ABI. If you use type to parametrize atomic ops, then you run into the problem above -- you do need to provide different implementation for the way given type is defined in a given ABI. In other words, type maps to assembly instructions in a different way on different ABIs. --Artem