On 05/11/2010 02:31 PM, Artyom Tarasenko wrote:
Nack. It looks like you reverted carry generation to the previous
(broken) behavior.
Oh? I suppose I should go back and look at the logs, but the way
it's written there sure seems to match 5.1.5.1 of the sparcv9 manual:
You'll only get carry into
On 05/11/2010 02:31 PM, Artyom Tarasenko wrote:
Nack. It looks like you reverted carry generation to the previous
(broken) behavior.
Perhaps you could point out the change I'm reverting? I don't see
any change to the actual computation of the flags since
2010/5/12 Richard Henderson r...@twiddle.net:
On 05/11/2010 02:31 PM, Artyom Tarasenko wrote:
Nack. It looks like you reverted carry generation to the previous
(broken) behavior.
Oh? I suppose I should go back and look at the logs, but the way
it's written there sure seems to match 5.1.5.1
On 05/12/2010 08:18 AM, Artyom Tarasenko wrote:
It is last year, but
3e6ba503400c34cbe0f9ad6e289921688bf303a3
The page 108 of the SPARC Version 8 Architecture Manual describes
that addcc and addxcc shall compute carry flag the same way.
The page 110 claims the same about subcc
2010/5/11 Richard Henderson r...@twiddle.net:
Use int32 types instead of target_ulong when computing ICC. This
simplifies the generated code for 32-bit host and 64-bit guest.
Use the same simplified expressions for ICC as were already used
for XCC in carry flag generation.
ADDX ICC carry
Use int32 types instead of target_ulong when computing ICC. This
simplifies the generated code for 32-bit host and 64-bit guest.
Use the same simplified expressions for ICC as were already used
for XCC in carry flag generation.
ADDX ICC carry generation was using the same routines as ADD ICC,
