Re: [Qemu-devel] [Patch] target-ppc mtcrf instruction not recognized

2005-05-18 Thread Pierre d'Herbemont
On 16 mai 05, at 09:54, Benjamin Herrenschmidt wrote:

OK, I did put this in my working repository and I'll submit this to
Fabrice.
Please try to do this change to check if other bits need to be relax 
or
not:

Index: target-ppc/translate.c
===
RCS file: /cvsroot/qemu/qemu/target-ppc/translate.c,v
retrieving revision 1.31
diff -u -r1.31 translate.c
--- target-ppc/translate.c  12 May 2005 18:46:11 -  1.31
+++ target-ppc/translate.c  14 May 2005 17:14:35 -
@@ -2123,7 +2123,7 @@
 }
 /* mtcrf */
-GEN_HANDLER(mtcrf, 0x1F, 0x10, 0x04, 0x00100801, PPC_MISC)
+GEN_HANDLER(mtcrf, 0x1F, 0x10, 0x04, 0x0801, PPC_MISC)
 {
 gen_op_load_gpr_T0(rS(ctx-opcode));
 gen_op_store_cr(CRM(ctx-opcode));
I've tested it: it works fine as expected.
And maybe someone should fill an Apple bug report to tell them their 
as
is buggy ;-)
It is definitely a bug in Apple assembler I would say, so I suggest you
add a comment in the above patch in order to avoid somebody later on
fixing your mask :)
I thought it was, but it seems to be not so buggy ;)
I have had a look at the Apple's as source code of Darwin 8.0 (10.4) 
[1] and I have found an interesting comment :
	/*
	 * If this is the mtcrf opcode (0x7c000120) and val is not zero and
	 * has exactly one bit set then use the new form of the mtcrf
	 * opcode.  This has bit 0x0010 set and the FXM field is a bit
	 * mask. Else use the old form without bit 0x0010 set.
  */

I don't know what they are refering to, but that may have been 
introduced by the PowerPC 970 or an other new PPC, since it was not 
present on the Mac OS X 10.2's as [2].

Pierre.
 [1] http://darwinsource.opendarwin.org/10.4/cctools-576/as/ppc.c
 [2] http://darwinsource.opendarwin.org/10.2/cctools-435/as/ppc.c

___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] [Patch] target-ppc mtcrf instruction not recognized

2005-05-17 Thread Benjamin Herrenschmidt

 OK, I did put this in my working repository and I'll submit this to
 Fabrice.
 Please try to do this change to check if other bits need to be relax or
 not:
 
 Index: target-ppc/translate.c
 ===
 RCS file: /cvsroot/qemu/qemu/target-ppc/translate.c,v
 retrieving revision 1.31
 diff -u -r1.31 translate.c
 --- target-ppc/translate.c  12 May 2005 18:46:11 -  1.31
 +++ target-ppc/translate.c  14 May 2005 17:14:35 -
 @@ -2123,7 +2123,7 @@
  }
  
  /* mtcrf */
 -GEN_HANDLER(mtcrf, 0x1F, 0x10, 0x04, 0x00100801, PPC_MISC)
 +GEN_HANDLER(mtcrf, 0x1F, 0x10, 0x04, 0x0801, PPC_MISC)
  {
  gen_op_load_gpr_T0(rS(ctx-opcode));
  gen_op_store_cr(CRM(ctx-opcode));
 
 And maybe someone should fill an Apple bug report to tell them their as
 is buggy ;-)

It is definitely a bug in Apple assembler I would say, so I suggest you
add a comment in the above patch in order to avoid somebody later on
fixing your mask :)

Ben.
 



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] [Patch] target-ppc mtcrf instruction not recognized

2005-05-14 Thread Pierre d'Herbemont
Hi,
I have been playing with ppc-darwin-user. And I have to say that qemu- 
ppc is too strict with ppc opcode validity:
On Mac OS X binary release called Tiger (or 10.4), the __bzero  
function [1] contains a mtcrf, which has been translated to  
0x7c901120, by Apple's as. Current qemu rejects it, saying it is  
invalid. According to the IBM Specification the mtcrf instruction  
[2], contains reserved flags, for which the values are unknown. qemu  
assumes that those are set to 1, which is obviously wrong. The  
attached patch provides a fix.

The mtcrf case might not be the only case in which such a situation  
occurs. That would need a special attention, though being strict is  
better than letting pass.

Pierre.
[1] http://fxr.watson.org/fxr/source/osfmk/ppc/commpage/bzero_32.s? 
v=DARWIN8#L98
[2] http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixassem/ 
alangref/mtcrf.htm

Index: target-ppc/translate.c
===
RCS file: /cvsroot/qemu/qemu/target-ppc/translate.c,v
retrieving revision 1.31
diff -u -r1.31 translate.c
--- target-ppc/translate.c  12 May 2005 18:46:11 -  1.31
+++ target-ppc/translate.c  14 May 2005 17:14:35 -
@@ -2123,7 +2123,7 @@
 }
 
 /* mtcrf */
-GEN_HANDLER(mtcrf, 0x1F, 0x10, 0x04, 0x00100801, PPC_MISC)
+GEN_HANDLER(mtcrf, 0x1F, 0x10, 0x04, 0x, PPC_MISC)
 {
 gen_op_load_gpr_T0(rS(ctx-opcode));
 gen_op_store_cr(CRM(ctx-opcode));
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] [Patch] target-ppc mtcrf instruction not recognized

2005-05-14 Thread J. Mayer
On Sat, 2005-05-14 at 19:20 +0200, Pierre d'Herbemont wrote:
 Hi,
 
 I have been playing with ppc-darwin-user. And I have to say that qemu- 
 ppc is too strict with ppc opcode validity:
 On Mac OS X binary release called Tiger (or 10.4), the __bzero  
 function [1] contains a mtcrf, which has been translated to  
 0x7c901120, by Apple's as. Current qemu rejects it, saying it is  
 invalid. According to the IBM Specification the mtcrf instruction  
 [2], contains reserved flags, for which the values are unknown. qemu  
 assumes that those are set to 1, which is obviously wrong. The  
 attached patch provides a fix.

Qemu assume all reserved fields are set to zero, not 1.
PowerPC specifications says: (section 8.1 of PEM)
Some instructions fields are reserved or must contain a predefined
value as shown in the individual instruction layouts. If a reserved
field does not have all bits cleared, or if a field that must contain a
particular value does not contains that value, the instruction form is
invalid ...
In section 4.1.3.2:
Invalid forms result when a bit or openrands is coded incorrectly, for
example, or when a reserved bit (shown as '0') is coded as '1'.
and
an attempt to execute an invalid form of an instruction either invokes
the illegal instruction error handler (or program exception) or yields
boundedly-undefined results.

In the case of mtcrf, the PowerPC specification says the bits 11, 21 and
31 (IBM notation) _must_ be zero.
This is what is described in 32 bits PEM as well as 64 bits PEM
(including the latest revision dated on 31/03/2005) and the 740/750
PowerPC user manual (which is the one currently emulated by Qemu).

It would be acceptable to relax the check if it would make MacOS X 10.4
boot.
But in this case, only the bit 11 (which causes the problem here) should
be relaxed.
Then, the bit mask becomes 0x0801 (not 0x).


 [2]
http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixassem/alangref/mtcrf.htm

This is the language reference for POWER  PowerPC.
Some forms described in this documentation are valid only for POWER
CPUs.
Please use PowerPC Environment Manual for PowerPC only specifications.

-- 
J. Mayer [EMAIL PROTECTED]
Never organized



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel