From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757400AbbCCRWf (ORCPT ); Tue, 3 Mar 2015 12:22:35 -0500 Received: from foss.arm.com ([217.140.101.70]:51456 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756981AbbCCRWd (ORCPT ); Tue, 3 Mar 2015 12:22:33 -0500 Date: Tue, 3 Mar 2015 17:22:29 +0000 From: Catalin Marinas To: Pranith Kumar Cc: Steve Capper , Will Deacon , open list , "linux-arm-kernel@lists.infradead.org" Subject: Re: [RFC PATCH] arm64: cmpxchg.h: Bring ldxr and stxr closer Message-ID: <20150303172228.GQ28951@e104818-lin.cambridge.arm.com> References: <1425067776-2794-1-git-send-email-bobby.prani@gmail.com> <20150227201526.GH24818@arm.com> <20150303143454.GN28951@e104818-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 03, 2015 at 11:58:26AM -0500, Pranith Kumar wrote: > On Tue, Mar 3, 2015 at 9:34 AM, Catalin Marinas wrote: > > Do you mean the cmpxchg_double() change? Becuase %w0 and %0 is the same > > physical register. You set it to 0 and immediately override it with > > ldxp. > > Thanks Catalin. I realized the blunder a while after Will pointed it > out. The asm here was a bit confusing. %0 usually refers to the first > input/output variable. But for ldxp instruction(which is just a > double-word load, not exclusive), it refers to the physical registers. OK, so please try not to touch any asm code until you understood (a) the AArch64 instruction set and (b) the gcc inline assembly syntax ;). > What about the changes in cmpxchg()? Why do we need to set %w0 to 0 > after the ldxrh instruction? Also, could you please point me to any > arm64 asm reference? "info gcc" for the inline assembly syntax and the ARMv8 ARM for the description of the AArch64 instruction set. It also helps if you look at the code generated by the compiler (e.g. objdump -d). -- Catalin