On Thu, Feb 23, 2017 at 10:39:47AM +0530, Nikunj A Dadhania wrote:
> David Gibson <da...@gibson.dropbear.id.au> 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
