[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [PATCH] mac99: Bring memory layout closer to real hardwar

From: BALATON Zoltan
Subject: Re: [Qemu-ppc] [PATCH] mac99: Bring memory layout closer to real hardware
Date: Sun, 27 Apr 2014 22:14:03 +0200 (CEST)
User-agent: Alpine 2.02 (LMD 1266 2009-07-14)


Mark Cave-Ayland suggested I should contact you as someone who might have the experience and access to necessary hardware to help in testing needed for the patch below. Some context for the discussion below can be found in this message: http://lists.nongnu.org/archive/html/qemu-ppc/2014-04/msg00277.html

It seems we have some code that contains instructions with a reserved bit set in an stwx instruction that works on real hardware but causes an invalid instruction exception on QEMU.

I'd be grateful if you'd have some insight you could share.


On Thu, 17 Apr 2014, Programmingkid wrote:
On Apr 17, 2014, at 3:16 AM, address@hidden wrote:
On Wed, 16 Apr 2014, Alexander Graf wrote:
On 16.04.14 12:24, BALATON Zoltan wrote:
On Tue, 15 Apr 2014, Alexander Graf wrote:
Try to do the same with the _E macro. Be creative :)

This one did it:

diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index e3fcb03..d1e175e 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -10341,7 +10341,7 @@ GEN_HANDLER(stop##u, opc, 0xFF, 0xFF, 0x00000000,
#define GEN_STUX(name, stop, opc2, opc3, type)
GEN_HANDLER(name##ux, 0x1F, opc2, opc3, 0x00000001, type),
#define GEN_STX_E(name, stop, opc2, opc3, type, type2)
-GEN_HANDLER_E(name##x, 0x1F, opc2, opc3, 0x00000001, type, type2),
+GEN_HANDLER_E(name##x, 0x1F, opc2, opc3, 0x00000000, type, type2),
#define GEN_STS(name, stop, op, type)
GEN_ST(name, stop, op | 0x20, type)
GEN_STU(name, stop, op | 0x21, type)

Cool. Could you please write a small program similar to the one I sent you
that runs all of these instructions and checks that really none of them
trigger a program interrupt on real hardware? We can then remove the reserved
1 bit from the mask.

Would something like this work? (You should be able to change the
instruction to test at the 1: label.) I can't test it though without a PPC

#include <stdio.h>

int main(int argc, char **argv)
  register unsigned long r8 asm("r8");
  register unsigned long r9 asm("r9");
  register unsigned long r10 asm("r10");
  register unsigned long r11 asm("r11");
  register unsigned long r12 asm("r12");
  long val = 0;

  r8 = 0;
  r9 = (long)&val;
  r10 = 0;

  asm volatile("mfcr 8                \n\t"
               "bl 1f                 \n\t"
               "mfcr 11               \n\t"
               "mflr 0                \n\t"
               "lwz 8, 36(0)          \n\t"
               "ori 8, 8, 1           \n\t"
               "stw 8, 36(0)          \n\t"
               "mfcr 8                \n\t"
               "bl 1f                 \n\t"
               "mfcr 12               \n\t"
               "b 2f                  \n\t"
               "1: stwx 8, 9, 10      \n\t"
               "blr                   \n\t"
               "2:                    \n\t"
                : "=r"(r8), "=r"(r11), "=r"(r12)
                : "r"(r8), "r"(r9), "r"(r10)
                : "cc");

  printf("old cr  (mem):\t%#lx\n", val);
  printf("old cr  (reg):\t%#lx\n", r8);
  printf("new cr1 (reg):\t%#lx\n", r11);
  printf("new cr2 (reg):\t%#lx\n", r12);

  return 0;


Just tried out your program on a Macintosh with a G3 processor. It doesn't 
compile under Mac OS X. Under Linux it crashes with a segmentation fault.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]