From: Tom Musta <tommusta@gmail.com>
To: BALATON Zoltan <balaton@eik.bme.hu>, Alexander Graf <agraf@suse.de>
Cc: Programmingkid <programmingkidx@gmail.com>,
qemu-ppc <qemu-ppc@nongnu.org>,
qemu-devel@nongnu.org, "Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [Qemu-ppc] Help needed testing on ppc
Date: Tue, 17 Jun 2014 06:54:20 -0500 [thread overview]
Message-ID: <53A02C6C.1010501@gmail.com> (raw)
In-Reply-To: <alpine.LMD.2.02.1406171258390.2477@jedlik.phy.bme.hu>
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
next prev parent reply other threads:[~2014-06-17 11:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-06 10:03 [Qemu-devel] Help needed testing on ppc BALATON Zoltan
2014-05-06 12:20 ` Tom Musta
2014-05-06 23:17 ` BALATON Zoltan
2014-05-07 15:31 ` Tom Musta
2014-05-07 16:59 ` Alexander Graf
2014-06-12 0:49 ` BALATON Zoltan
2014-06-16 23:42 ` BALATON Zoltan
2014-06-17 8:42 ` Alexander Graf
2014-06-17 9:34 ` [Qemu-devel] [Qemu-ppc] " BALATON Zoltan
2014-06-17 9:37 ` Alexander Graf
2014-06-17 11:05 ` BALATON Zoltan
2014-06-17 11:54 ` Tom Musta [this message]
2014-06-17 15:17 ` BALATON Zoltan
2014-06-18 12:40 ` Tom Musta
2014-06-19 13:21 ` BALATON Zoltan
2014-06-23 17:07 ` Alexander Graf
2014-05-20 23:55 ` [Qemu-devel] " BALATON Zoltan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53A02C6C.1010501@gmail.com \
--to=tommusta@gmail.com \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=balaton@eik.bme.hu \
--cc=programmingkidx@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).