From owner-p4-projects@FreeBSD.ORG Thu Mar 3 22:15:21 2005 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 6481416A4F4; Thu, 3 Mar 2005 22:15:20 +0000 (GMT) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1579B16A4EC for ; Thu, 3 Mar 2005 22:15:20 +0000 (GMT) Received: from mail28.sea5.speakeasy.net (mail28.sea5.speakeasy.net [69.17.117.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id C266843D58 for ; Thu, 3 Mar 2005 22:15:19 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24151 invoked from network); 3 Mar 2005 22:15:19 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 3 Mar 2005 22:15:19 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j23MEqDx092866; Thu, 3 Mar 2005 17:15:13 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Alan Cox Date: Thu, 3 Mar 2005 16:52:47 -0500 User-Agent: KMail/1.6.2 References: <200503032104.j23L4Pjw010114@repoman.freebsd.org> <20050303212558.GA16936@cs.rice.edu> In-Reply-To: <20050303212558.GA16936@cs.rice.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503031652.47596.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: Perforce Change Reviews Subject: Re: PERFORCE change 72450 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 22:15:21 -0000 On Thursday 03 March 2005 04:25 pm, Alan Cox wrote: > On Thu, Mar 03, 2005 at 09:04:25PM +0000, John Baldwin wrote: > > http://perforce.freebsd.org/chv.cgi?CH=72450 > > > > Change 72450 by jhb@jhb_slimer on 2005/03/03 21:03:35 > > > > Clobber memory for cas{x,}a() inlines. > > > > Suggested by: alc > > > > Affected files ... > > > > .. //depot/projects/smpng/sys/sparc64/include/cpufunc.h#20 edit > > > > Differences ... > > > > ==== //depot/projects/smpng/sys/sparc64/include/cpufunc.h#20 (text+ko) > > ==== > > > > @@ -63,14 +63,14 @@ > > #define casa(rs1, rs2, rd, asi) ({ \ > > u_int __rd = (uint32_t)(rd); \ > > __asm __volatile("casa [%1] %2, %3, %0" \ > > - : "+r" (__rd) : "r" (rs1), "n" (asi), "r" (rs2)); \ > > + : "+r" (__rd) : "r" (rs1), "n" (asi), "r" (rs2) : "memory");\ > > __rd; \ > > }) > > > > #define casxa(rs1, rs2, rd, asi) ({ \ > > u_long __rd = (uint64_t)(rd); \ > > __asm __volatile("casxa [%1] %2, %3, %0" \ > > - : "+r" (__rd) : "r" (rs1), "n" (asi), "r" (rs2)); \ > > + : "+r" (__rd) : "r" (rs1), "n" (asi), "r" (rs2) : "memory");\ > > __rd; \ > > }) > > The other, arguably "more correct", option is to declare the memory > location referenced by rs1 as an input and output operand, like so > from i386: (I say "more correct" because the true operand here is the > memory location referenced by rs1 not rs1 the register.) Ah, yes, I can try that. > static __inline pt_entry_t > pte_load_store(pt_entry_t *ptep, pt_entry_t pte) > { > pt_entry_t r; > > __asm __volatile( > "xchgl %0,%1" > > : "=m" (*ptep), > > "=r" (r) > > : "1" (pte), > > "m" (*ptep)); > return (r); > } > > (Note: this example does not use "+m" as an output constraint because > Tor convinced me a few months ago that the gcc docs prohibit that: "+" > is only to be used with registers.) Hmm, this is what gcc info page says: `+' Means that this operand is both read and written by the instruction. When the compiler fixes up the operands to satisfy the constraints, it needs to know which operands are inputs to the instruction and which are outputs from it. `=' identifies an output; `+' identifies an operand that is both input and output; all other operands are assumed to be input only. If you specify `=' or `+' in a constraint, you put it in the first character of the constraint string. It does say that '&' can't be used with a memory address it seems: `&' Means (in a particular alternative) that this operand is an "earlyclobber" operand, which is modified before the instruction is finished using the input operands. Therefore, this operand may not lie in a register that is used as an input operand or as part of any memory address. This is important to sort out as the i386 atomic ops use '+m' rather extensively. > Returning to the sparc, I'm not sure what the right constraint is for > cas{x,}a's rs1. I don't believe that "m" is appropriate because this > particular instruction doesn't allow the destination to be a register > plus an constant offset. Perhaps, "V"? > > That said, we should add a "memory" clobber to the sparc64 atomic ops > that include a memory barrier, particularly, the acquires. Agreed. > Regards, > Alan -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org