Hi Fabrice,
thanks for the review.
On Thu, 27 Apr 2006, Fabrice Bellard wrote:
1) Why do you use 3 temporaries ? Maybe two suffice in most cases.
Well, I less temporaries don't gain performance, while a
FDT2 = FDT0 * FDT1
fpu_dump_state()
allows for easier debugging. Therefore I'd rather keep three temps,
but I can change that if you think it's too much bloat.
2) do_cmp_d() should be completely decoded at translation time.
Hm. Yeah. I just don't quite now about the limitations of generated
code. In the !CONFIG_SOFTFLOAT case, the softfloat-native will use
compiler/libc defined stuff like isgreater(), libm, whatever. Is is
really safe to assume all that code can be generated? I felt better
with a CALL_FROM_TB(). Maybe you can enlighten me a bit there.
Also, is a call really that much slower? It might even benefit from
the called function being in the host cpu cache already. Any figures
on that available?
3) I suspect the macro FPR() does too many things at runtime which gives an
important performance loss. CP0St_FR should be known at translation time.
I'll see what I can do.
You should use CONFIG_SOFTFLOAT to validate your code. The ARM target does
it, so it works (see the configure script).
Ok, I got pretty weird errors in the floatx80 area and it kind of
looked like this is broken. I must have missed something then.
While there: I noticed it's very difficult at best to properly emulate
floating point states and exceptions when using native float; the
softfloat has a nice interface for that stuff. How's the world order
to handle this?
Thanks,
Marius
--
Marius Groeger <[EMAIL PROTECTED]>
SYSGO AG Embedded and Real-Time Software
Voice: +49 6136 9948 0 FAX: +49 6136 9948 10
www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel