From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KZrer-0007Pe-On for qemu-devel@nongnu.org; Sun, 31 Aug 2008 14:28:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KZrep-0007PS-I6 for qemu-devel@nongnu.org; Sun, 31 Aug 2008 14:28:16 -0400 Received: from [199.232.76.173] (port=51060 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZrep-0007PP-Dz for qemu-devel@nongnu.org; Sun, 31 Aug 2008 14:28:15 -0400 Received: from wf-out-1314.google.com ([209.85.200.175]:40298) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KZreo-0003Sy-T7 for qemu-devel@nongnu.org; Sun, 31 Aug 2008 14:28:15 -0400 Received: by wf-out-1314.google.com with SMTP id 27so1557786wfd.4 for ; Sun, 31 Aug 2008 11:28:13 -0700 (PDT) Message-ID: Date: Sun, 31 Aug 2008 21:28:13 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] [PATCH] SH4: convert fmov/fadd to TCG In-Reply-To: <48BAD4DB.6070907@juno.dti.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48B9A131.7080400@juno.dti.ne.jp> <48BAD4DB.6070907@juno.dti.ne.jp> 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 On 8/31/08, Shin-ichiro KAWASAKI wrote: > Thank your for comments, Blue Swirl! > The new patch is shown at the end of this mail. > Reviews are welcome, again. > > Blue Swirl wrote: > > > > On 8/30/08, Shin-ichiro KAWASAKI wrote: > > > > > >> This patch converts two SH4 float instructions, 'fmov Rm,Rn' and > > > >> 'fadd' into TCG. Before converting other float instructions > > > >> into TCG, comments on it will be appreciated. > > > >> > > > >> - TCG variables intorudced for float operation : FT[01], and DT[01]. > > > >> - I think float registers 'fregs' are not to be mapped for > > > >> TCG variables, because TCG does not support float operations, now. > > > > > > > > > In TCG README Fabrice mentioned that he's working on a floating point > > > version. It would be nice to get that committed, already m68k has a > > > fake version. I did not use TCG variables for float just because I've > > > been waiting for that. It's not possible to pass env->fp_status > > > cleanly now (for example to call softfloat functions directly). And > > > for example on Sparc host, moving data from integer registers to > > > floating point registers must use memory in between them so there the > > > integer TCG registers should be separate from float TCG registers. > > > > I agree that it is important to conisder mapping fregs ot TCG feature > like m68k implementation does. But I think this work will take too long > time, if I do it, and it will be some break for converting TCG work. > I think it is not too late to do this work after eliminating 'op.c'. That's a valid approach, of course. > And I have a question on it. > As you pointed out below, two 32 bit registers are concatanated as one > 64 bit register. When floating point TCG variables introduced in the > future, > it is straight to map one memory region for 32bit TCG variable and 64bit > TCG variable. I wonder such two way mapping suit for TCG, or not. I think it depends how well TCG can detect aliased variables. As i386 does not use TCG variables for AL, AX and EAX, I guess that it can't. This is of course just speculation. > > > There is no need to pass env as a parameter, it's available to > > > op_helper.c code anyway. > > > > Indeed. Thanks! > > > > > I guess that like in Sparc, two 32 bit fregs can be combined to a 64 > > > bit double. Please have a look at target-sparc/translate.c on the use > > > of CPU_DoubleU, there should be a safer way to access the registers. > > > > Thanks. I wrote new codes for load/store function, following sparc. Looks good, except this small thing below: > + printf("initial offset : %d\n", offsetof(CPUState, dt0));