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

["J. Mayer" <l_indien@magic.fr>]

On Mon, 2005-05-16 at 19:06 +0100, Piotras wrote:
> You may also want to take a look at mtocrf (with "o" for "one") in the document:
>   ftp://www6.software.ibm.com/software/developer/library/es-ppcbook1.zip
> 

All right, there is a new (optional) form of this instruction.
However, what is currently done in Qemu is perfectly valid:
"On some processor that comply with versions of the architecture that
precede Version 2.00 the new form may be treated as follows:
mtocrf: may cause the system illegal instruction error handler to be
invoked
mfocrf: may copy the content of an SPR, possibly a priviledged SPR, into
register RT"

As I doubt Apple want its OS not to run on G3 & G4, they must have
handled those case in their kernel.

Of course, for performance reasons, and to be able to emulate new
PowerPCs, I will relax the check, but this check should not prevent Mac
OS X to run.

Regards.

> On 5/16/05, Piotras <piotras@gmail.com> wrote:
> > Hi!
> > 
> > I'm not sure if this is relevant, but please search for "new form of
> > the mtcrf" on:
> > http://developer.apple.com/technotes/tn/tn2087.html
> > http://www.opensource.apple.com/darwinsource/10.3.9/gas-573.1/as/ppc.c
> > 
> > There are also some references to "POWER4 optimised mtcrf" (try google).
> > 
> > Do not really have time to research this right now,
> > 
> > Piotr Krysiuk
> > 
> > On 5/15/05, J. Mayer <l_indien@magic.fr> wrote:
> > > On Sat, 2005-05-14 at 21:03 +0200, Pierre d'Herbemont wrote:
> > > > On 14 mai 05, at 20:15, J. Mayer wrote:
> > > >
> > > > > Qemu assume all reserved fields are set to zero, not 1.
> > > >
> > > > > PowerPC specifications says: (section 8.1 of PEM)
> > > [...]
> > > > > 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 0x00000801 (not 0x00000000).
> > > >
> > > [...]
> > > > In fact I was referring to my old PowerPC Spec book in french from
> > > > IBM (titled Architecture PowerPC), this link was the first google
> > > > returned. After looking again in my book, I found what you said. I am
> > > > confused, I wrote this a bit quickly. But the fact remains, would you
> > > > send a correct patch for that? It'll definitely be compulsory in
> > > > order to boot Mac OS X 10.4, and for darwin-user.
> > >
> > > 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 -0000      1.31
> > > +++ target-ppc/translate.c      14 May 2005 17:14:35 -0000
> > > @@ -2123,7 +2123,7 @@
> > >  }
> > >
> > >  /* mtcrf */
> > > -GEN_HANDLER(mtcrf, 0x1F, 0x10, 0x04, 0x00100801, PPC_MISC)
> > > +GEN_HANDLER(mtcrf, 0x1F, 0x10, 0x04, 0x00000801, 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 ;-)
> > >
> > > --
> > > J. Mayer <l_indien@magic.fr>
> > > Never organized
> > >
> > > _______________________________________________
> > > Qemu-devel mailing list
> > > Qemu-devel@nongnu.org
> > > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> > >
> >
-- 
J. Mayer <l_indien@magic.fr>
Never organized