From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KbLZC-0006kX-Q4 for qemu-devel@nongnu.org; Thu, 04 Sep 2008 16:36:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KbLZB-0006kH-BE for qemu-devel@nongnu.org; Thu, 04 Sep 2008 16:36:33 -0400 Received: from [199.232.76.173] (port=45259 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KbLZB-0006kE-6m for qemu-devel@nongnu.org; Thu, 04 Sep 2008 16:36:33 -0400 Received: from hall.aurel32.net ([91.121.138.14]:60689) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KbLZA-0004bb-O1 for qemu-devel@nongnu.org; Thu, 04 Sep 2008 16:36:33 -0400 Date: Thu, 4 Sep 2008 22:36:19 +0200 From: =?iso-8859-15?Q?Aur=E9lien?= Jarno Subject: Re: [Qemu-devel] [PATCH 8/x] ppc: Convert op_set_FT0 to TCG Message-ID: <20080904203619.GA1819@volta.aurel32.net> References: <20080903112840.GC17474@networkno.de> <7F235F5C-A1C9-4617-8C8D-900778862BBD@web.de> <67BC3D0E-6819-426A-BD93-ADE75621E6E4@web.de> <3D7FC18B-1027-4AB9-ACDE-E7B650F259F2@googlemail.com> <519F0BAB-FCDE-40D4-9255-48CB569909E5@googlemail.com> <20080904143931.GC11924@volta.aurel32.net> <9F25F767-0618-4970-88E0-83FD155753C4@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9F25F767-0618-4970-88E0-83FD155753C4@googlemail.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?iso-8859-15?Q?F=E4rber?= Cc: qemu-devel@nongnu.org On Thu, Sep 04, 2008 at 07:59:37PM +0200, Andreas Färber wrote: > Replace op_set_FT0 with tcg_gen_movi_i64. > > Signed-off-by: Andreas Faerber > > --- > Here's a small one since we now seem to be both working on ppc. > > I'm not sure if this is correct since the dyngen op set the upper half > to zero. Do we need an explicit cast to 32 bits for the immediate > argument to assure they will be zero? Or was that just to avoid garbage > with dyngen? No we don't. If you like at the instruction decoding, or at the PowerPC manual, you will see that the resulting number is always representable with a 32-bit variable. In dyngen, I guess it was to avoid passing both PARAM1 and PARAM2. Patch applied. > > Andreas > > target-ppc/op.c | 10 ---------- > target-ppc/translate.c | 2 +- > 2 files changed, 1 insertions(+), 11 deletions(-) > > diff --git a/target-ppc/op.c b/target-ppc/op.c > index a31b41f..81329e3 100644 > --- a/target-ppc/op.c > +++ b/target-ppc/op.c > @@ -424,16 +424,6 @@ void OPPROTO op_load_fpscr_FT0 (void) > RETURN(); > } > > -void OPPROTO op_set_FT0 (void) > -{ > - CPU_DoubleU u; > - > - u.l.upper = 0; > - u.l.lower = PARAM1; > - FT0 = u.d; > - RETURN(); > -} > - > void OPPROTO op_load_fpscr_T0 (void) > { > T0 = (env->fpscr >> PARAM1) & 0xF; > diff --git a/target-ppc/translate.c b/target-ppc/translate.c > index 9dd2506..5139ae6 100644 > --- a/target-ppc/translate.c > +++ b/target-ppc/translate.c > @@ -2090,7 +2090,7 @@ GEN_HANDLER(mtfsfi, 0x3F, 0x06, 0x04, 0x006f0800, > PPC_FLOAT) > bf = crbD(ctx->opcode) >> 2; > sh = 7 - bf; > gen_optimize_fprf(); > - gen_op_set_FT0(FPIMM(ctx->opcode) << (4 * sh)); > + tcg_gen_movi_i64(cpu_FT[0], FPIMM(ctx->opcode) << (4 * sh)); > gen_reset_fpstatus(); > gen_op_store_fpscr(1 << sh); > if (unlikely(Rc(ctx->opcode) != 0)) { > -- > 1.5.5.1 > > -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net