From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44545) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXt7C-0007lh-In for qemu-devel@nongnu.org; Tue, 17 Mar 2015 11:09:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YXt77-0003KM-JO for qemu-devel@nongnu.org; Tue, 17 Mar 2015 11:09:06 -0400 Received: from mailapp01.imgtec.com ([195.59.15.196]:38853 helo=imgpgp01.kl.imgtec.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXt76-0003Jz-JL for qemu-devel@nongnu.org; Tue, 17 Mar 2015 11:09:01 -0400 Message-ID: <5508438A.3040504@imgtec.com> Date: Tue, 17 Mar 2015 15:08:58 +0000 From: James Hogan MIME-Version: 1.0 References: <1426586167-1552-1-git-send-email-leon.alrae@imgtec.com> <55080816.5010001@imgtec.com> <55082750.7020401@imgtec.com> In-Reply-To: <55082750.7020401@imgtec.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CFc1T2caV7MKr2vHJUj5Eg0rObVnkw0BT" Subject: Re: [Qemu-devel] [2.4 PATCH] target-mips: add Config5.FRE support allowing Status.FR=0 emulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Leon Alrae , qemu-devel@nongnu.org Cc: aurelien@aurel32.net --CFc1T2caV7MKr2vHJUj5Eg0rObVnkw0BT Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 17/03/15 13:08, Leon Alrae wrote: > Hi James, >=20 > On 17/03/2015 10:55, James Hogan wrote: >> Hi Leon, >> >> On 17/03/15 09:56, Leon Alrae wrote: >>> + case 5: >>> + /* FRE Support - clear Config5.FRE bit */ >>> + if (!((env->active_fpu.fcr0 & (1 << FCR0_FREP)) && (rt =3D=3D= 0))) { >>> + return; >>> + } >> >> If rt !=3D 0, is it really desired for a Config5 bit (which is privile= ged >> state) to be modified? Assuming these behave similarly to UFR/UNFR, th= e >> behaviour is architecturally UNPREDICTABLE when rt !=3D $0, not UNDEFI= NED >> (and at least UNFR is required to produce an RI exception in r5 >> implementations). >=20 > Hmm, I believe the code above is correct and is doing exactly what you > described :) Note that "&& (rt =3D=3D 0)" is inside parenthesis followi= ng > the logical NOT operator. It is no-op if rt !=3D 0. Yep, my apologies. Stupid brackets :-). >>> /* Floating point register moves. */ >>> -static void gen_load_fpr32(TCGv_i32 t, int reg) >>> +static void gen_load_fpr32(DisasContext *ctx, TCGv_i32 t, int reg) >>> { >>> + if (ctx->hflags & MIPS_HFLAG_FRE) { >>> + generate_exception(ctx, EXCP_RI); >> >> Maybe return to avoid generating dead code? >=20 > The reason is to avoid leaving the TCG temp marked as TEMP_VAL_DEAD > which would cause assertion failures in TCG as we still generate code > using this temp after returning from gen_load_fpr(). Okay, fair enough. Cheers James --CFc1T2caV7MKr2vHJUj5Eg0rObVnkw0BT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVCEOKAAoJEGwLaZPeOHZ6Y9wP/Anz+25ozIAzEKGWAQQWlobv ExbVn37dzjQQjeJVbHM5KfOBnen2WJKWck03sns9QCHqt1Qi5EHzMQKFaHMdIKA7 0P7BVkasvXBstJ+9Lenx34GeBfkIHf7DtnZsPm+IZpaE5GukB8q+6BVLShDE7twr ZU/2lX/WKTT6n4r4ZOTHsELn8Ux2WecpFrpT/38Mhhzc+xV+P87tZryMSf7lT8s/ 1bNMiAW/XiNjA8/SrEnutchlmQ+sd+T0tstqhgTd8gdDexMxCovuSz7IYlPTY3LX DLuFTOF+AeEQ5u52vO8qdyAMizyNQHMSw3GfgorKg2lfWNY0Y5880MJFxcLQGJXC 8FF8HlOR+oW2/kGEqDCHh6WuVC+TLhk8TU2t1akunWuZzSos1QQZtJgZE33fFr2a HUuI9AKtSVRRrzwsd4DvjogziodImy+O3h9GuUgKAMJf6s/epqxAhusIzbfkpxjA /yWKVu7bYpnUvvehjDeF6oJoiEatyXgsZYX9L6vXYoXNPb9iZJEDqBpDbMcD7gLh nsDIn0WNgcbu7CARx2EJtI3HgPE8fU3bGWYQgyqhWaiy1zYn+2UkIWaUgoTRCLnY H35aeGIrp/6oCuviSPPy0C35enpFlYCNs9xQkwRwPHXEPlJkuIp42Pv83sGW1CcL OhkSa2AdtFuq6P9Lz17w =bmil -----END PGP SIGNATURE----- --CFc1T2caV7MKr2vHJUj5Eg0rObVnkw0BT--