From owner-p4-projects@FreeBSD.ORG Fri Mar 4 23:26:47 2005 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id A2EC716A4D1; Fri, 4 Mar 2005 23:26:46 +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 5C9B516A4CF for ; Fri, 4 Mar 2005 23:26:46 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 5616F43D41 for ; Fri, 4 Mar 2005 23:26:45 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 31166 invoked by uid 89); 4 Mar 2005 23:26:43 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 4 Mar 2005 23:26:43 -0000 Received: (qmail 31151 invoked by uid 89); 4 Mar 2005 23:26:43 -0000 Received: from unknown (HELO ?66.23.216.52?) (66.23.216.52) by duchess.speedfactory.net with SMTP; 4 Mar 2005 23:26:43 -0000 From: Stephan Uphoff To: John Baldwin In-Reply-To: <200503031652.47596.jhb@FreeBSD.org> References: <200503032104.j23L4Pjw010114@repoman.freebsd.org> <200503031652.47596.jhb@FreeBSD.org> Content-Type: text/plain Message-Id: <1109978713.645.626.camel@beach> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 04 Mar 2005 18:25:16 -0500 Content-Transfer-Encoding: 7bit cc: Perforce Change Reviews cc: Alan Cox 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: Fri, 04 Mar 2005 23:26:47 -0000 On Thu, 2005-03-03 at 16:52, John Baldwin wrote: > 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. The linux code wraps the target of the atomic operations in structures to avoid aliasing problems. I really, really would like to know exactly why the developers thought that this is necessary. So far I have had no luck finding a reference. > > 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