J. Mayer a écrit : > On Tue, 2007-10-23 at 12:47 +0100, Thiemo Seufer wrote: >> J. Mayer wrote: >>> On Tue, 2007-10-23 at 00:05 +0200, Aurelien Jarno wrote: >>>> J. Mayer a écrit : >>>>> On Mon, 2007-10-22 at 18:28 +0200, Aurelien Jarno wrote: >>>>>> On Mon, Oct 22, 2007 at 09:36:07AM +0200, J. Mayer wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I've been investigating more about PreP kernel boot using Qemu and I >>>>>>> achieved to boot 2.4.35, 2.6.12 and 2.6.22 kernels using Qemu CVS and >>>>>>> unmodified OHW. >>> [...] >>>>>> - The "floating point" problem I reported during the week-end does >>>> not >>>>>> exists, probably because of the switch from powerpc to ppc. I >>>> still >>>>>> don't know if it is a kernel problem or a QEMU problem (or both). >>>>> There may be issues with the floating point emulation, especially if >>>>> some kernel or programs relies on the FPSCR (floating-point status) >>>>> register which is never updated in Qemu. >>>>> >>>> Is there any technical reason behind that, or is it just a lack of >>>> time? >>> 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. >
Then I guess it is what has been done on the SPARC target: after each FP instruction, check_ieee_exceptions() is called to accumulate the IEEE exceptions and generate real exceptions if they are enabled. That doesn't look really complex, but I agree that could slow down a bit the emulation. I will get a closer look in two or three weeks. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `- people.debian.org/~aurel32 | www.aurel32.net
