From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1InBtV-0007Ku-SB
	for qemu-devel@nongnu.org; Wed, 31 Oct 2007 07:37:57 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1InBtT-0007Kf-Dx
	for qemu-devel@nongnu.org; Wed, 31 Oct 2007 07:37:56 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1InBtT-0007Kc-8q
	for qemu-devel@nongnu.org; Wed, 31 Oct 2007 07:37:55 -0400
Received: from [66.135.41.201] (helo=server2linux.rebelnetworks.com)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <jseward@acm.org>) id 1InBtS-0003iS-KV
	for qemu-devel@nongnu.org; Wed, 31 Oct 2007 07:37:54 -0400
From: Julian Seward <jseward@acm.org>
Date: Wed, 31 Oct 2007 12:37:22 +0100
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200710311237.22174.jseward@acm.org>
Subject: [Qemu-devel] emu errors for creqv,crnand,crnor,crorc ?
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "J. Mayer" <l_indien@magic.fr>
Cc: qemu-devel@nongnu.org


Hi Jocelyn

I ran valgrind's ppc32 insn set tests and got the impression that
the above insns are not correctly implemented.  It seems like 7 bits
of CR are set to 1 and one is set to 0, when it should be the other
way around.  Below is a simple test case.  On QEMU it prints

  result is 000fc000

and on a real 7447

  result is 00004000

Similar behaviour for creqv, crnand, crnor.  But cror, crand, crxor work
OK.  So maybe it is related to the inverted-result-sense?  But the strange
thing is, ~0xFC != 0x04.

J

#include <stdio.h>
void do_crorc_17_14_15 ( void )
{
  UInt res = 0xFFFFFFFF;
  __asm__ __volatile__(
"li 9,0\n"
"\tmtcr 9\n"
"\tmtxer 9\n"
"\tcrorc 17,14,15\n"
"\tmfcr %0"
: /*out*/"=b"(res) : /*in*/ : /*trash*/ "9"
);
  printf("result is %08x\n", res );
}

int main ( void )
{
  do_crorc_17_14_15();
  return 0;
}