Re: [Qemu-ppc] [PATCH 5/6] target-ppc: support for 32-bit carry and overflow

[Nikunj A Dadhania]

David Gibson <address@hidden> writes:

> [ Unknown signature status ]
> On Fri, Feb 10, 2017 at 09:49:17AM +0530, Nikunj A Dadhania wrote:
>> David Gibson <address@hidden> writes:
>> 
>> > [ Unknown signature status ]
>> > On Thu, Feb 09, 2017 at 04:04:04PM +0530, Nikunj A Dadhania wrote:
>> >> POWER ISA 3.0 adds CA32 and OV32 status in 64-bit mode. Add the flags
>> >> and corresponding defines. Moreover, CA32 is set when CA is set and
>> >> OV32 is set when OV is set, there is no need to have a new
>> >> fields in the CPUPPCState structure.
>> >> 
>> >> Signed-off-by: Nikunj A Dadhania <address@hidden>
>> >
>> > Um.. I don't quite understand this.  If CA always has the same value
>> > as CA32, what's the point?
>> 
>> I am not clear either. I think that as CA was set for both 32/64-bit
>> mode, that couldn't be changed for backward compatibility. CA32 should
>> have affected only the instructions working one word variants.
>> 
>> Re-scanning the ISA 3.0, found this in 3.3.9 Fixed-Point Arithmetic
>> Instructions:
>> 
>> =================================================================
>> addic, addic., subfic, addc, subfc, adde, subfe,
>> addme, subfme, addze, and subfze always set CA, to
>> reflect the carry out of bit 0 in 64-bit mode and out of bit
>> 32 in 32-bit mode. These instructions also always set
>> CA32 to reflect the carry out of bit 32.
>> =================================================================
>> 
>> Which is conflicting to what is said in 3.2.2 Fixed-Point Exception
>> Register:
>> =================================================================
>> Carry32 (CA32)
>> CA32 is set whenever CA is set, and is set to
>> the same value that CA is defined to be set to
>> in 32-bit mode.
>> =================================================================
>
> Ok, I've had a look at the ISA and discussed this with Michael
> Ellerman.  We think what's going on here is that it's using some
> unfortunately unclear wording.  When it says "OV32 is set when OV is
> set" we think that means "OV32 is updated when OV is updated", not
> that "OV32 is set to the same value as OV".
>
> So although they're updated at the same time, the 32-bit variants can
> have different values and will need real representation in the CPU
> model.  Well, at least in 64-bit mode.  When the CPU is in 32-bit
> mode, I believe they really will have the same values.
>
> That would make your implementation suggested here incorrect.

Yes, you are right. I had a discussion with Paul Mackerras yesterday, he
explained to me in detail about the bits. I am working on the revised
implementation. Will detail it in the commit message.

Regards
Nikunj