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