From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lbsdg-0000In-LU for qemu-devel@nongnu.org; Tue, 24 Feb 2009 03:27:40 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lbsdf-0000Ia-Ja for qemu-devel@nongnu.org; Tue, 24 Feb 2009 03:27:39 -0500 Received: from [199.232.76.173] (port=42872 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lbsdf-0000IX-BU for qemu-devel@nongnu.org; Tue, 24 Feb 2009 03:27:39 -0500 Received: from mx20.gnu.org ([199.232.41.8]:52358) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lbsde-0006ZF-TH for qemu-devel@nongnu.org; Tue, 24 Feb 2009 03:27:39 -0500 Received: from fg-out-1718.google.com ([72.14.220.153]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lbsdd-0003Ih-Ai for qemu-devel@nongnu.org; Tue, 24 Feb 2009 03:27:37 -0500 Received: by fg-out-1718.google.com with SMTP id e21so65357fga.8 for ; Tue, 24 Feb 2009 00:27:30 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <49A3A9EA.4040300@nomovok.com> References: <49A3A9EA.4040300@nomovok.com> Date: Tue, 24 Feb 2009 09:27:30 +0100 Message-ID: <761ea48b0902240027k45a6b687o3d1367957a849d00@mail.gmail.com> Subject: Re: [Qemu-devel] [PATCH] Fix qemu_ld64 on arm From: Laurent Desnogues Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 Tue, Feb 24, 2009 at 9:03 AM, Pablo Virolainen wrote: > > Emulating fldl on arm doesn't seem to work too well. It's the way qemu_ld= 64 > is translated to arm instructions. > > =A0 =A0 =A0 =A0tcg_out_ld32_12(s, COND_AL, data_reg, addr_reg, 0); > =A0 =A0 =A0 =A0tcg_out_ld32_12(s, COND_AL, data_reg2, addr_reg, 4); It seems you are using an old version of qemu. Taking a quick look at current svn, I think your patch is not needed anymore. Laurent > > > Consider case where data_reg=3D=3D0, data_reg2=3D=3D1, and addr_reg=3D=3D= 0. First load > overwrited addr_reg. So let's put an if (data_ref=3D=3Daddr_reg). > > Index: tcg-target.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- tcg-target.c =A0 =A0 =A0 =A0(revision 6642) > +++ tcg-target.c =A0 =A0 =A0 =A0(working copy) > @@ -1011,8 +1011,14 @@ > =A0 =A0 case 3: > =A0 =A0 =A0 =A0 /* TODO: use block load - > =A0 =A0 =A0 =A0 =A0* check that data_reg2 > data_reg or the other way */ > - =A0 =A0 =A0 =A0tcg_out_ld32_12(s, COND_AL, data_reg, addr_reg, 0); > - =A0 =A0 =A0 =A0tcg_out_ld32_12(s, COND_AL, data_reg2, addr_reg, 4); > + > + =A0 =A0 =A0 =A0if (data_reg=3D=3Daddr_reg) { > + =A0 =A0 =A0 =A0 =A0 =A0tcg_out_ld32_12(s, COND_AL, data_reg2, addr_reg,= 4); > + =A0 =A0 =A0 =A0 =A0 =A0tcg_out_ld32_12(s, COND_AL, data_reg, addr_reg, = 0); > + =A0 =A0 =A0 =A0} else { > + =A0 =A0 =A0 =A0 =A0 =A0tcg_out_ld32_12(s, COND_AL, data_reg, addr_reg, = 0); > + =A0 =A0 =A0 =A0 =A0 =A0tcg_out_ld32_12(s, COND_AL, data_reg2, addr_reg,= 4); > + =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0 break; > =A0 =A0 } > =A0#endif > > >