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. -- J. Mayer <[EMAIL PROTECTED]> Never organized
