From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BVFaR-0000wx-8X for qemu-devel@nongnu.org; Tue, 01 Jun 2004 16:10:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BVFaQ-0000wE-9k for qemu-devel@nongnu.org; Tue, 01 Jun 2004 16:10:14 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BVFaQ-0000w0-4S for qemu-devel@nongnu.org; Tue, 01 Jun 2004 16:10:14 -0400 Received: from [62.253.162.94] (helo=mta10-svc.ntlworld.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BVFa2-0001Aj-NU for qemu-devel@nongnu.org; Tue, 01 Jun 2004 16:09:50 -0400 Received: from [10.10.10.100] ([81.107.87.144]) by mta05-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040531132106.UASX2927.mta05-svc.ntlworld.com@[10.10.10.100]> for ; Mon, 31 May 2004 14:21:06 +0100 Subject: Re: [Qemu-devel] Running QEMU on FreeBSD From: Antony T Curtis In-Reply-To: <40BB21D5.2070409@fabianowski.de> References: <1085865953.93476.3.camel@pcgem.rdg.cyberkinetica.com> <1085966664.347.8.camel@pcgem.rdg.cyberkinetica.com> <40BA8D68.3070204@fabianowski.de> <200405301859.03523.kyle@silverbeach.net> <40BB21D5.2070409@fabianowski.de> Content-Type: text/plain Message-Id: <1086009759.347.69.camel@pcgem.rdg.cyberkinetica.com> Mime-Version: 1.0 Date: Mon, 31 May 2004 14:22:39 +0100 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Mon, 2004-05-31 at 13:15, Bartosz Fabianowski wrote: > > You're either up very, very late, or very early :-) > > Very late :). > > > I didn't see a patch attached to this email. Did my mailer drop it? > > I was referring to Antony's latest patch. It wasn't quite a patch, in > fact, just the following idea: > > Replace the rintl() function in target-i386/op.c with the following: > > CPU86_LDouble rintl(CPU86_LDouble __x) { > register CPU86_LDouble __result; > __asm __volatile__ ("frndint" : "=t" (__result) : "0" (__x)); > return __result; > } > > So what I meant to say is that with this change, the FPU stops reporting > a NaN when it obviously shouldn't, but starts doing weird rounding > again. Sorry if my late-night mail wasn't quite clear. I think the errors are being introduced in the routines in target-i386/helper.c I'm going to investigate replacing them with more 'native' operations -- Antony T Curtis