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)
>
>> + 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.
Regards
Nikunj
