[Qemu-devel] emu errors for creqv,crnand,crnor,crorc ?

[Qemu-devel] emu errors for creqv,crnand,crnor,crorc ?

[Julian Seward]

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;
}

[Qemu-devel] Re: emu errors for creqv,crnand,crnor,crorc ?

[Jocelyn Mayer]

On Wed, 2007-10-31 at 12:37 +0100, Julian Seward wrote:
> Hi Jocelyn

Hi,

> 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.

Thanks for testing and for the report !
I have to admit I never did extensive test on CR operations the same way
I did for arithmetic and logical ones.
 What is strange is that 0xFC + 0x04... I will have to check all the CR
ops, I guess...
I also got a 74xx CPU at home, then I will try to compare running
step-by-step, if needed.

I'll tell you when I'll find the bug...

-- 
Jocelyn Mayer <l_indien@magic.fr>

[Qemu-devel] Re: emu errors for creqv,crnand,crnor,crorc ?

[Julian Seward]

> > 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.

J

[Qemu-devel] Re: emu errors for creqv,crnand,crnor,crorc ?

[Jocelyn Mayer]

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.