From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IkTnq-0007vA-JM for qemu-devel@nongnu.org; Tue, 23 Oct 2007 20:08:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IkTnl-0007nT-Vn for qemu-devel@nongnu.org; Tue, 23 Oct 2007 20:08:54 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IkTnl-0007nJ-SU for qemu-devel@nongnu.org; Tue, 23 Oct 2007 20:08:49 -0400 Received: from relay01.mx.bawue.net ([193.7.176.67]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IkTnl-0004oo-7c for qemu-devel@nongnu.org; Tue, 23 Oct 2007 20:08:49 -0400 Date: Wed, 24 Oct 2007 01:08:13 +0100 From: Thiemo Seufer Subject: Re: [Qemu-devel] PreP kernels boot using Qemu Message-ID: <20071024000813.GG25397@networkno.de> References: <1193038567.16781.108.camel@rapid> <20071022162810.GA12778@hall.aurel32.net> <1193087522.16781.121.camel@rapid> <471D1E98.50303@aurel32.net> <1193092572.16781.128.camel@rapid> <20071023114737.GD25397@networkno.de> <1193176403.16781.189.camel@rapid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1193176403.16781.189.camel@rapid> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "J. Mayer" Cc: qemu-devel@nongnu.org, Aurelien Jarno J. Mayer wrote: [snip] > > > I can say both: > > > for most program, using floating point arithmetic ala "fast-math", it's > > > not necessary to maintain a precise FPU state, as those program will > > > never raise any FPU exception, never generate NaNs, infinites, ... > > > The other reason is that it would need to check every FPU insn arguments > > > and results at run time and treat all special cases following the actual > > > PowerPC implementations behavior if we want to get a precise emulation. > > > This behavior could be for example selected at compile time: then one > > > would have the choice to have a quick FPU emulation model or a precise > > > one. > > > > For mips I chose the middle ground: The emulation is architecturally > > correct but may not reflect FPU behaviour of the specific silicon. > > E.g. one effect is that in certain cases the emulation computes values > > close to underflow, while real hardware would throw the (mips FPU > > specific) unimplemented exception. > > > > For most cases this should be good enough, since only specialized > > software will rely on a specific implementation's oddities. > > Well, what you've done for Mips is exactly what I called the "precise > emulation" and is far slower than the "fast math" emulation I got for > PowerPC. I was wrong talking about "PowerPC implementations" when I > should have said "PowerPC specification"; but there should be no > difference between the two (or it's not a PowerPC CPU...) because the > POWER/PowerPC specification describes very precisely the behavior of the > FPU. > > The "fast math" model relies on the native-softmmu code and is suficient > for most applications. But there are a few instructions that should > always take care (or maybe at least reset) the FPSCR register, which is > not done in the current code. My theory is that occasional FP users won't suffer from the performance impact, and heavy FP users are likely to expect IEEE conformance. Thus I gave priority to correctness. Implementing a R8000-style fast FP mode sounds like fun, but for the moment I have already enough unfinished bits and pieces in Qemu. :-) Thiemo