From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:34176)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <tg@gmplib.org>) id 1Ua5xO-0004IM-TZ
	for qemu-devel@nongnu.org; Wed, 08 May 2013 11:07:08 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <tg@gmplib.org>) id 1Ua5ly-00070Q-5U
	for qemu-devel@nongnu.org; Wed, 08 May 2013 10:55:16 -0400
References: <1368019560-25218-1-git-send-email-agraf@suse.de>
	<20130508142515.GS5000@ohm.aurel32.net>
From: Torbjorn Granlund <tg@gmplib.org>
Sender: tg@gmplib.org
Date: Wed, 08 May 2013 16:48:22 +0200
In-Reply-To: <20130508142515.GS5000@ohm.aurel32.net> (Aurelien Jarno's message
	of "Wed\, 8 May 2013 16\:25\:15 +0200")
Message-ID: <86sj1xv87d.fsf@shell.gmplib.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH] PPC: Depend behavior of cmp instructions
	only on instruction encoding
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: Aurelien Jarno <aurelien@aurel32.net>
Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org, Alexander Graf <agraf@suse.de>, Richard Henderson <rth@twiddle.net>

Aurelien Jarno <aurelien@aurel32.net> writes:

  That said this does implement neither the specification nor the silicon
  behaviour. This is fine for 1.5 as we are in freeze period, but this=20
  should be fixed for the 1.6 release.

I talked to IBM now.  Reserved fields should be ignored by hardware.

The architecture owner is IBM, not Freescale.  That Freescale deviates
from the architecture, is something that you may decide to ignore,
unless it is vital for qemu's behaviour in practice.

I very much doubt that L =3D 1 often, for code targeting a 32-bit
processor.

Trying to mimic decoding flaws on a per-processor basis, is going to
take a lot of research, and will be prone to errors.

So as far as I can tell, the patch is correct as per the architecture
specification.

One caveat though: Does 32-bit implementations define the SF bit, or
else, does qemu define it and make sure it is 0 for 32-bit emulation?
If not, the patch might cause trouble.

Congrats, you read a "user message" until the last line.  :-)

--=20
Torbj=C3=B6rn