Re: [Qemu-devel] PreP kernels boot using Qemu

[Thiemo Seufer <ths@networkno.de>]

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