On 6/17/2014 6:05 AM, BALATON Zoltan wrote:
> On Tue, 17 Jun 2014, Alexander Graf wrote:
>>>>> http://goliat.eik.bme.hu/~balaton/oftest/results/
>>>>>
>>>>> The results show that the stwx instruction with reserved bit set does not
>>>>> change status bits and does not generate an exception on any CPU tested
>>>>> (G3 and G4) so it is most probably just ignored as we thought.
>>>>
>>>> [adding qemu-ppc and tom to CC]
>>>>
>>>> Tom already commented on this. Is there a pattern that matches all the
>>>> indexed load/store instructions or is stwx a one-off?
>>>
>>> Is this a question to whom? If to me I don't understand it.
>>
>> stwx is part of a group of instructions. It's very rare that hardware only
>> shows certain behavior (like ignore a reserved bit) for single instructions.
>> Usually it happens on complete groups.
>
> Who would know that? The test only tested stwx and I assume the same that
> this should not behave differently than any other instruction. Also this is
> the only instruction that was used with the set reserved bit in MorphOS and
> the patch ignoring reserved
> bits for this group of instructions that we discussed earlier seems to fix
> it. (There's another case with an altivec instruction with a similar failure
> but I did not look at that yet if that's a reserved bit too or something
> else.) As to why it's in
> MorphOS I don't know, I got no answer from them.
>
> Regards,
> BALATON Zoltan
I am looking at the test case source code and do not see how you are setting
the reserved bit. Maybe I am missing some cleverness in how the test is built?
#include <prom.h>
void stwxtest(void)
{
unsigned int val, cr, cr1, cr2;
prom_printf("Testing stwx reserved bit\n");
val = 0;
asm volatile("mfcr %0 \n\t"
"bl 1f \n\t"
"mfcr %1 \n\t"
"mflr 10 \n\t"
"lwz %0, 36(10) \n\t"
"ori %0, %0, 1 \n\t"
"stw %0, 36(10) \n\t"
"mfcr %0 \n\t"
"bl 1f \n\t"
"mfcr %2 \n\t"
"b 2f \n\t"
"1: stwx %0, %4, %6 \n\t" <<<<<<<<<<<<< just a
normal stwx, right?
"blr \n\t"
"2: \n\t"
: "=&r"(cr), "=&r"(cr1), "=&r"(cr2), "=m"(val)
: "r"(&val), "m"(val), "r"(8)
: "r8", "r9", "r10", "cc", "memory");
prom_printf("old cr (mem):\t%#x\n", val);
prom_printf("old cr (reg):\t%#x\n", cr);
prom_printf("new cr1 (reg):\t%#x\n", cr1);
prom_printf("new cr2 (reg):\t%#x\n", cr2);
}
But the objdump of your test binary does not show that it is set either:
00102784 <stwxtest>:
stwxtest():
102784: 7c 08 02 a6 mflr r0
102788: 94 21 ff d0 stwu r1,-48(r1)
10278c: 3c 60 00 10 lis r3,16
102790: 38 63 32 29 addi r3,r3,12841
102794: bf a1 00 24 stmw r29,36(r1)
102798: 90 01 00 34 stw r0,52(r1)
10279c: 4c c6 31 82 crclr 4*cr1+eq
1027a0: 4b ff e2 75 bl 100a14 <prom_printf>
1027a4: 7c 27 0b 78 mr r7,r1
1027a8: 39 20 00 00 li r9,0
1027ac: 95 27 00 08 stwu r9,8(r7)
1027b0: 38 c0 00 08 li r6,8
1027b4: 7f a0 00 26 mfcr r29
1027b8: 48 00 00 29 bl 1027e0 <stwxtest+0x5c>
1027bc: 7f c0 00 26 mfcr r30
1027c0: 7d 48 02 a6 mflr r10
1027c4: 83 aa 00 24 lwz r29,36(r10)
1027c8: 63 bd 00 01 ori r29,r29,1
1027cc: 93 aa 00 24 stw r29,36(r10)
1027d0: 7f a0 00 26 mfcr r29
1027d4: 48 00 00 0d bl 1027e0 <stwxtest+0x5c>
1027d8: 7f e0 00 26 mfcr r31
1027dc: 48 00 00 0c b 1027e8 <stwxtest+0x64>
1027e0: 7f a7 31 2e stwx r29,r7,r6
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
1027e4: 4e 80 00 20 blr
