[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH][MIPS] FPU support for MIPS

From: Marius Groeger
Subject: Re: [Qemu-devel] [PATCH][MIPS] FPU support for MIPS
Date: Thu, 27 Apr 2006 12:22:39 +0200 (CEST)

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

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?


Marius Groeger <address@hidden>
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]