qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

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