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. Thiemo
