From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1InE47-0003wU-Kf for qemu-devel@nongnu.org; Wed, 31 Oct 2007 09:57:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1InE45-0003uC-S2 for qemu-devel@nongnu.org; Wed, 31 Oct 2007 09:57:03 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1InE45-0003u6-Q9 for qemu-devel@nongnu.org; Wed, 31 Oct 2007 09:57:01 -0400 Received: from honiara.magic.fr ([195.154.193.36]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1InE45-0008Hp-8H for qemu-devel@nongnu.org; Wed, 31 Oct 2007 09:57:01 -0400 From: Jocelyn Mayer In-Reply-To: <200710311439.04939.jseward@acm.org> References: <200710311237.22174.jseward@acm.org> <1193837243.24629.22.camel@jma4.dev.netgem.com> <200710311439.04939.jseward@acm.org> Content-Type: text/plain Date: Wed, 31 Oct 2007 14:56:57 +0100 Message-Id: <1193839017.24629.33.camel@jma4.dev.netgem.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: emu errors for creqv,crnand,crnor,crorc ? Reply-To: l_indien@magic.fr, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Julian Seward Cc: qemu-devel@nongnu.org On Wed, 2007-10-31 at 14:39 +0100, Julian Seward wrote: > > > way around. Below is a simple test case. On QEMU it prints > > > > > > result is 000fc000 > > > > > > and on a real 7447 > > > > > > result is 00004000 > > > > > What is strange is that 0xFC + 0x04... I will have to check all the CR > > ops, I guess... > > Another strange thing is that 000fc000 does not have 'fc' byte-aligned > inside CR, if you see what I mean. If it was 0000fc00 or 00fc0000, some > byte-inversion mistake would seem likely. > > This isn't a 74xx specific result. I'm sure any ppc should produce > 00004000. The test is very simple: make CR=0 then do crorc 17,14,15. > So only 1 bit in CR will then be set - all others are zero. I guess the problem is the CRops are implemented this way: - get the bit from crfA - get the bit from crfB - do the logical operation - store the result bit As the faulting ops are the one that do a complement, it's quite sure that the problem is that the result bit is not properly masked before being stored. Then the '4' bit is OK, but you also get 'noisy' other bits that should have been masked before the store. As the condition register is stored as 8 4 bits registers, this would affect only the updated CR field.