Re: [PATCH v5 23/23] target/ppc: Move cmp/cmpi/cmpl/cmpli to decodetree

[David Gibson]

On Wed, May 26, 2021 at 12:17:48PM -0300, Matheus K. Ferst wrote:
> On 24/05/2021 15:51, Richard Henderson wrote:
> > On 5/21/21 10:25 AM, Matheus K. Ferst wrote:
> > > On 18/05/2021 07:12, Richard Henderson wrote:
> > > > On 5/17/21 3:50 PM, matheus.ferst@eldorado.org.br wrote:
> > > > > +    if(a->l && (ctx->insns_flags & PPC_64B)) {
> > > > 
> > > > Space after IF.
> > > > > If I look back to the 6xx manual, I see
> > > > 
> > > >    NOTE: If L = 1, the instruction form is invalid.
> > > > 
> > > > The fact that we're allowing L=1 for ppc32 is an existing bug,
> > > > afaics. We should fix that.
> > > > 
> > > > 
> > > > r~
> > > 
> > > The previous commit on this line in translate.c says that "on most
> > > 32bit CPUs we should always treat the compare as 32bit compare, as
> > > the CPU will ignore the L bit", so maybe it was intentional. Should
> > > we change it anyway?
> > 
> > The actual change of 36f48d9c78c is about NARROW_MODE, which is about
> > the MSR.SF bit, and is correct.
> > 
> > The commit message mentions the e500mc specifically does check the L
> > bit, and then hand-waves about the others not checking.  But the text I
> > found in the 6xx manual says that one checks too.
> > 
> > I wonder if the IBM folk can shed any further light on this?
> > 
> > 
> > r~
> 
> I was pointed to the 601 manual, which says:
> 
> "While the PowerPC architecture specifies that the value in the L field
> determines whether the operands are treated as 32- or 64-bit values, the 601
> ignores the value in the L field and treats the operands as 32-bit values."
> 
> There is also a section in Appendix B called "Reserved Bits in
> Instructions", which says:
> 
> "These are shown with '/'s in the instruction opcode definitions. In the
> POWER architecture such bits are ignored by the processor. In PowerPC
> architecture they must be 0 or the instruction form is invalid. In several
> cases the PowerPC architecture assumes that such bits in POWER instructions
> are indeed 0. The cases include the following:
> - cmpi, cmp, cmpli, and cmpl assume that bit 10 in the POWER instructions is
> 0.
> - mtspr and mfspr assume that bits 16–20 in the POWER instructions are 0."
> 
> Searching the manuals for other processors, I identified that the manuals
> for 405, 440, e500, and e500mc explicit says that the L bit should always be
> 0, and manuals for 603e, 604, 604e, 740/745/750/755, 750CX, 750CL, 750FX,
> 7400/7410, 7447/7447A/7448/7450/7455, e300, and e600 list the bit L in
> operand syntax but do not mention any restrictions on its value.
> 
> Alfredo Dal Ava Junior (adalva) did some tests for us on his G4 MacBook,
> confirming that the bit is ignored in PowerPC 7447A v1.2, one of which the
> manual does not specify the behavior, but I don't know if can assume the
> same for other processors.
> 
> If we do bother to emulate the specific behavior for each CPU, what would be
> the default for those whose manual is not explicit and we cannot test? Also,
> I not sure how to check for it, do we need a new POWERPC_FLAG in pcc->flags?

My inclination would be to make L=1 program check on all 32-bit cpus
for now, and if someone pipes up with a guest broken because it
assumes L=1 is ignored, we can fix it then.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

signature.asc
Description: PGP signature