Re: [Qemu-ppc] [PATCH v3 03/10] target/ppc: support for 32-bit carry and overflow

[David Gibson]

On Thu, Feb 23, 2017 at 10:39:47AM +0530, Nikunj A Dadhania wrote:
> David Gibson <address@hidden> writes:
> >> 
> >> diff --git a/target/ppc/cpu.c b/target/ppc/cpu.c
> >> index de3004b..89c1ccb 100644
> >> --- a/target/ppc/cpu.c
> >> +++ b/target/ppc/cpu.c
> >> @@ -23,8 +23,15 @@
> >>  
> >>  target_ulong cpu_read_xer(CPUPPCState *env)
> >>  {
> >> -    return env->xer | (env->so << XER_SO) | (env->ov << XER_OV) |
> >> +    target_ulong xer;
> >> +
> >> +    xer = env->xer | (env->so << XER_SO) | (env->ov << XER_OV) |
> >>          (env->ca << XER_CA);
> >> +
> >> +    if (is_isa300(env)) {
> >> +        xer |= (env->ov32 << XER_OV32) | (env->ca32 << XER_CA32);
> >> +    }
> >> +    return xer;
> >>  }
> >>  
> >>  void cpu_write_xer(CPUPPCState *env, target_ulong xer)
> >> @@ -32,5 +39,13 @@ void cpu_write_xer(CPUPPCState *env, target_ulong xer)
> >>      env->so = (xer >> XER_SO) & 1;
> >>      env->ov = (xer >> XER_OV) & 1;
> >>      env->ca = (xer >> XER_CA) & 1;
> >> -    env->xer = xer & ~((1u << XER_SO) | (1u << XER_OV) | (1u << XER_CA));
> >> +    if (is_isa300(env)) {
> >> +        env->ov32 = (xer >> XER_OV32) & 1;
> >> +        env->ca32 = (xer >> XER_CA32) & 1;
> >
> > I think these might as well be unconditional - as long as the read_xer
> > doesn't read the bits back, the guest won't care that we track them in
> > internal state.
> 
> Sure.
> 
> 
> > I'm also wondering if it might be worth adding a xer_mask to the env,
> > instead of explicitly checking isa300 all over the place.
> 
> Let me try that out.
> 
> Can we also update ov32/ca32 in all the arithmetic operations as if its
> supported. And as you suggested, whenever there is a read attempted,
> only give relevant bits back(xer_mask). This would save lot of
> conditions in translations (couple of more tcg-ops for non-isa300)

So if it was a straight trade-off between conditions and math
operations, I'd pick the extra math every time.  However, in this case
we're trading off math on every execution, versus a condition only on
translation, which should occur less often.  So in this case I suspect
it's worth keeping the conditional.

> >> +        env->xer = xer & ~((1ul << XER_SO) |
> >> +                           (1ul << XER_OV) | (1ul << XER_CA) |
> >> +                           (1ul << XER_OV32) | (1ul << XER_CA32));
> >> +    } else {
> >> +        env->xer = xer & ~((1u << XER_SO) | (1u << XER_OV) | (1u << 
> >> XER_CA));
> >> +    }
> >
> > And you can definitely use the stricer mask for both archs.  If it's
> > ISA300, you've stashed them elsewhere, if it's not those bits are
> > invalid anyway,
> >
> > (Incidentally given the modern balance between the cost of
> > instructions and cachelines, I wonder if all these split out bits of
> > the XER are a good idea in any case, but that would be a big change
> > out  of scope for what you're attempting here)
> 
> Will have a look at this after finishing isa300. I have faced issues
> with RISU wrt having the state stashed in different tcg variables.

Thanks.

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