From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FZ3e2-0001Sc-MO for qemu-devel@nongnu.org; Thu, 27 Apr 2006 06:22:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FZ3e0-0001SE-2d for qemu-devel@nongnu.org; Thu, 27 Apr 2006 06:22:46 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FZ3dz-0001SB-W2 for qemu-devel@nongnu.org; Thu, 27 Apr 2006 06:22:44 -0400 Received: from [62.8.134.5] (helo=mail.sysgo.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FZ3gs-0003ak-GP for qemu-devel@nongnu.org; Thu, 27 Apr 2006 06:25:42 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.sysgo.com (Postfix) with ESMTP id B46E5FB84C for ; Thu, 27 Apr 2006 12:22:41 +0200 (CEST) Received: from donald.sysgo.com (unknown [172.20.1.30]) by mail.sysgo.com (Postfix) with ESMTP id 9DBB9FB84C for ; Thu, 27 Apr 2006 12:22:41 +0200 (CEST) Received: from mag.sysgo.com (mag.sysgo.com [172.24.2.130]) by donald.sysgo.com (Postfix) with ESMTP id A2A17D0015D for ; Thu, 27 Apr 2006 12:22:39 +0200 (CEST) Date: Thu, 27 Apr 2006 12:22:39 +0200 (CEST) From: Marius Groeger Sender: mag@sysgo.com Subject: Re: [Qemu-devel] [PATCH][MIPS] FPU support for MIPS In-Reply-To: <444FF164.2060104@bellard.org> Message-ID: References: <444FF164.2060104@bellard.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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 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