From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46165 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCDhq-0001IG-Qt for qemu-devel@nongnu.org; Wed, 12 May 2010 11:18:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCDho-0008St-2z for qemu-devel@nongnu.org; Wed, 12 May 2010 11:18:42 -0400 Received: from fg-out-1718.google.com ([72.14.220.159]:29301) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OCDhn-0008Sh-Id for qemu-devel@nongnu.org; Wed, 12 May 2010 11:18:39 -0400 Received: by fg-out-1718.google.com with SMTP id 16so1496716fgg.10 for ; Wed, 12 May 2010 08:18:38 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4BEAC18C.80208@twiddle.net> References: <4BEAC18C.80208@twiddle.net> From: Artyom Tarasenko Date: Wed, 12 May 2010 17:18:18 +0200 Message-ID: Subject: Re: [Qemu-devel] [PATCH 2/3] target-sparc: Simplify ICC generation; fix ADDX carry generation. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: blauwirbel@gmail.com, qemu-devel@nongnu.org 2010/5/12 Richard Henderson : > On 05/11/2010 02:31 PM, Artyom Tarasenko wrote: >> Nack. It looks like you reverted carry generation to the previous >> (broken) behavior. > > Oh? =A0I 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 the high bit on X - Y if X < Y. > > In any case, if you meant to fix carry computation for subtraction, > you missed changing the 64-bit carry computation too. May very well be the case. I cared only about sparcv8. Was sort of expecting that someone would stop me telling I broke v9... > It is still > written the same way before and after my patch, and matches both > the expectation I have from the v9 manual and the post-patch code > along the 32-bit path. Probably v9 differs from v8? > Perhaps you could point out the change I'm reverting? I don't > see any change to the actual computation of the flags since > f0f26a06d51b7e7764f8951cdbf67ac9ad507f6d, last year. It is last year, but 3e6ba503400c34cbe0f9ad6e289921688bf303a3 --=20 Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/