David Gibson <da...@gibson.dropbear.id.au> writes: > [ Unknown signature status ] > On Fri, Feb 10, 2017 at 09:49:17AM +0530, Nikunj A Dadhania wrote: >> David Gibson <da...@gibson.dropbear.id.au> 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 <nik...@linux.vnet.ibm.com> >> > >> > 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
