From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:59908)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1ULGud-0002fB-Od
	for qemu-devel@nongnu.org; Thu, 28 Mar 2013 13:46:58 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1ULGua-0006gu-U0
	for qemu-devel@nongnu.org; Thu, 28 Mar 2013 13:46:55 -0400
Received: from mail-ob0-x22f.google.com ([2607:f8b0:4003:c01::22f]:39490)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1ULGua-0006gi-KG
	for qemu-devel@nongnu.org; Thu, 28 Mar 2013 13:46:52 -0400
Received: by mail-ob0-f175.google.com with SMTP id va7so6477509obc.34
	for <qemu-devel@nongnu.org>; Thu, 28 Mar 2013 10:46:51 -0700 (PDT)
Sender: Richard Henderson <rth7680@gmail.com>
Message-ID: <51548206.1010107@twiddle.net>
Date: Thu, 28 Mar 2013 10:46:46 -0700
From: Richard Henderson <rth@twiddle.net>
MIME-Version: 1.0
References: <1364484781-15561-1-git-send-email-rth@twiddle.net>
	<1364484781-15561-21-git-send-email-rth@twiddle.net>
	<CAFEAcA8bFSexPGY9n+=cPprnRrppvsNOxUAKyRg7L3V6zrN3Zg@mail.gmail.com>
In-Reply-To: <CAFEAcA8bFSexPGY9n+=cPprnRrppvsNOxUAKyRg7L3V6zrN3Zg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v3 20/20] tcg-arm: Convert to
	CONFIG_QEMU_LDST_OPTIMIZATION
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: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org, Aurelien Jarno <aurelien@aurel32.net>

On 03/28/2013 09:44 AM, Peter Maydell wrote:
>> +        /* Prior to that the assembler uses mov r0, r0.  Unlike the nop
>> +           above, this is guaranteed to consume execution resources.  */
> 
> Guaranteed by who? Catching this case in the decoder and treating it
> exactly like NOP is a perfectly legal implementation.
> (For that matter there's nothing restricting an implementation of
> the architectural NOP from tying up every execution resource on
> the core for 500 cycles.)

Hmph, I could have sworn I saw language exactly like that in the AARM,
but I can't find it anymore.  I do see a note about not using NOP in
timing loops in A8.8.119.

As for timing on real hardware, I can make a loop like

1:	subs	r0, r0, #1
	mov	r0, r0
	mov	r0, r0
	mov	r0, r0
	mov	r0, r0
	mov	r0, r0
	mov	r0, r0
	bne	1b

runs in 7 cycles on Cortex-A15, whereas the same loop with nops runs in 6.  Of
course, changing to "mov r1, r1" so that we don't conflict with the subs in the
first cycle also runs in 6 cycles.  So it's all about finding a nop that
doesn't have a RAW conflict with the previous insn.

I don't have any other ARM hw readily available.


r~