From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:41830)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1bHeJa-0000WO-Ea
	for qemu-devel@nongnu.org; Mon, 27 Jun 2016 17:43:35 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1bHeJW-0003XU-Cd
	for qemu-devel@nongnu.org; Mon, 27 Jun 2016 17:43:34 -0400
Received: from mail-qk0-x229.google.com ([2607:f8b0:400d:c09::229]:35094)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1bHeJW-0003XJ-8F
	for qemu-devel@nongnu.org; Mon, 27 Jun 2016 17:43:30 -0400
Received: by mail-qk0-x229.google.com with SMTP id a125so29787109qkc.2
	for <qemu-devel@nongnu.org>; Mon, 27 Jun 2016 14:43:30 -0700 (PDT)
Sender: Richard Henderson <rth7680@gmail.com>
References: <1467054136-10430-1-git-send-email-cota@braap.org>
	<1467054136-10430-2-git-send-email-cota@braap.org>
	<be7d1df1-031e-f442-f280-68e287a47a29@twiddle.net>
	<20160627211958.GB15173@flamenco>
From: Richard Henderson <rth@twiddle.net>
Message-ID: <50313453-8df7-d237-fe7d-d2775ec8896d@twiddle.net>
Date: Mon, 27 Jun 2016 14:43:26 -0700
MIME-Version: 1.0
In-Reply-To: <20160627211958.GB15173@flamenco>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC 01/30] softmmu: add cmpxchg helpers
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Emilio G. Cota" <cota@braap.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>, MTTCG Devel <mttcg@greensocs.com>, Peter Maydell <peter.maydell@linaro.org>, Alvise Rigo <a.rigo@virtualopensystems.com>, Sergey Fedorov <serge.fdrv@gmail.com>, Paolo Bonzini <pbonzini@redhat.com>, =?UTF-8?Q?Alex_Benn=c3=a9e?= <alex.bennee@linaro.org>

On 06/27/2016 02:19 PM, Emilio G. Cota wrote:
>> Host endian operation?
>
> I forgot to add byte ordering in the cover letter under "why this is
> an RFC" -- I admit I'm confused by all the macro trickery done for
> regular loads and stores.
>
> We store data in memory as per the guests' byte ordering, right?

Sometimes.  The guest can also explicitly request a reversed byte load/store. 
This is used both for explicit byte-reversing instructions (e.g. x86 movbe) and 
toggling the system byte order (arm setbe).


> If so, I don't see how it would be possible to leverage the
> host compiler for things like atomic_add -- we'd increment garbage,
> not a meaningful value.

All you need to do is byte-reverse the data.

   bswap(a + b) == bswap(a) + bswap(b).


r~