Re: [Qemu-devel] [PATCH v1 07/10] target/ppc: update ov/ov32 for nego

[Nikunj A Dadhania]

Richard Henderson <address@hidden> writes:

> On 02/22/2017 02:53 PM, Nikunj A Dadhania wrote:
>> Richard Henderson <address@hidden> writes:
>>
>>> On 02/21/2017 08:26 PM, Nikunj A Dadhania wrote:
>>>> Richard Henderson <address@hidden> writes:
>>>>
>>>>> On 02/20/2017 09:11 PM, Nikunj A Dadhania wrote:
>>>>>> For 64-bit mode if the register RA contains 0x8000_0000_0000_0000, OV
>>>>>> and OV32 are set to 1.
>>>>>>
>>>>>> For 32-bit mode if the register RA contains 0x8000_0000, OV and OV32 are
>>>>>> set to 1.
>>>>>>
>>>>>> Use the tcg-ops for negation (neg_tl) and drop gen_op_arith_neg() as
>>>>>> nego was the last user.
>>>>>>
>>>>>> Signed-off-by: Nikunj A Dadhania <address@hidden>
>>>>> @@ -1488,7 +1480,20 @@ static void gen_neg(DisasContext *ctx)
>>>>>>
>>>>>>  static void gen_nego(DisasContext *ctx)
>>>>>>  {
>>>>>> -    gen_op_arith_neg(ctx, 1);
>>>>>> +    TCGv t0 = tcg_temp_new();
>>>>>> +    TCGv zero = tcg_const_tl(0);
>>>>>> +
>>>>>> +    if (NARROW_MODE(ctx)) {
>>>>>> +        tcg_gen_xori_tl(t0, cpu_gpr[rA(ctx->opcode)], INT32_MIN);
>>>>>> +    } else {
>>>>>> +        tcg_gen_xori_tl(t0, cpu_gpr[rA(ctx->opcode)], 
>>>>>> (target_ulong)INT64_MIN);
>>>>>> +    }
>>>>>> +
>>>>>> +    tcg_gen_setcond_tl(TCG_COND_EQ, cpu_ov, t0, zero);
>>>>>> +    tcg_gen_mov_tl(cpu_ov32, cpu_ov);
>>>>>> +    tcg_gen_neg_tl(cpu_gpr[rD(ctx->opcode)], cpu_gpr[rA(ctx->opcode)]);
>>>>>> +    tcg_temp_free(t0);
>>>>>> +    tcg_temp_free(zero);
>>>>>>  }
>>>>>
>>>>> Again, you're forgetting "nego.".  Don't try to simplify from 
>>>>> gen_op_arith_subf
>>>>> by hand.
>>>>
>>>> The reason of the simplification was the interpretation of ov and ov32.
>>>> I will add a code to compute the Rc.
>>>
>>> Why do you believe that the computation for overflow is different between 
>>> neg
>>> and subf?
>>
>> For example in 64-bit mode, if we negate INT64_MIN(nego[.]), both OV and
>> OV32 has to be set to 1 according to ISA 3.0. If I use subf, only OV is
>> set to 1.
>
> What an odd corner case for OV32 wrt nego.  But you're right that's what the 
> manual says.  I wonder why the hardware folk designed the chip that way.  It 
> seems broken.
>
> You might want to confirm with the hardware folk that this isn't a bug in the 
> manual.

Sure, moreover I figured out that the hardware simulator isnt following
the ISA3.0 behaviour (setting OV and OV32 both)

Regards
Nikunj