From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55634) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aP0Kb-0000cm-Ld for qemu-devel@nongnu.org; Thu, 28 Jan 2016 23:06:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aP0Ka-0002kL-Fr for qemu-devel@nongnu.org; Thu, 28 Jan 2016 23:06:45 -0500 Date: Fri, 29 Jan 2016 14:04:41 +1100 From: David Gibson Message-ID: <20160129030441.GI23043@voom.redhat.com> References: <1453650086-92705-1-git-send-email-jrtc27@jrtc27.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7IgncvKP0CVPV/ZZ" Content-Disposition: inline In-Reply-To: <1453650086-92705-1-git-send-email-jrtc27@jrtc27.com> Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 0/2] PPC handles mcrfs incorrectly List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: James Clarke Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org --7IgncvKP0CVPV/ZZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 24, 2016 at 03:41:24PM +0000, James Clarke wrote: > Here is the description of the mcrfs instruction from the PowerPC Archite= cture > Book, Version 2.02, Book I: PowerPC User Instruction Set Architecture > (http://www.ibm.com/developerworks/systems/library/es-archguide-v2.html),= found > on page 120: Thanks I've merged these fixes to ppc-for-2.6 which I'll send a pull request for shortly. >=20 > The contents of FPSCR field BFA are copied to Condition Register fiel= d BF. > All exception bits copied are set to 0 in the FPSCR. If the FX bit is > copied, it is set to 0 in the FPSCR. >=20 > Special Registers Altered: > CR field BF > FX OX (if BFA=3D0) > UX ZX XX VXSNAN (if BFA=3D1) > VXISI VXIDI VXZDZ VXIMZ (if BFA=3D2) > VXVC (if BFA=3D3) > VXSOFT VXSQRT VXCVI (if BFA=3D5) >=20 > However, currently every bit in FPSCR field BFA is set to 0, including on= es not > on that list. >=20 > I noticed this with the following simple C program: >=20 > #include > #include >=20 > int main(int argc, char **argv) { > int ret; > ret =3D fegetround(); > printf("Current rounding: %d\n", ret); > ret =3D fesetround(FE_UPWARD); > printf("Setting to FE_UPWARD (%d): %d\n", FE_UPWARD, ret); > ret =3D fegetround(); > printf("Current rounding: %d\n", ret); > ret =3D fegetround(); > printf("Current rounding: %d\n", ret); > return 0; > } >=20 > which gave the output: >=20 > Current rounding: 0 > Setting to FE_UPWARD (2): 0 > Current rounding: 2 > Current rounding: 0 >=20 > instead of (with these patches applied): >=20 > Current rounding: 0 > Setting to FE_UPWARD (2): 0 > Current rounding: 2 > Current rounding: 2 >=20 > The relevant disassembly is in fegetround(), which, on my system, is: >=20 > __GI___fegetround: > <+0>: mcrfs cr7, cr7 > <+4>: mfcr r3 > <+8>: clrldi r3, r3, 62 > <+12>: blr >=20 > What happens is that, the first time fegetround() is called, FPSCR field = 7 is > retrieved. However, because of the bug in mcrfs, the entirety of field 7 = is set > to 0, which includes the rounding mode. >=20 > There are other issues this will fix, such as condition flags not persist= ing > when they should if read, and if you were to read a specific field with s= ome > exception bits set, but no others were set in the entire register, then t= he > bits would be cleared correctly, but FEX/VX would not be updated to 0 as = they > should be. >=20 > The first commit is because some FP_ macros needed to calculate > FP_EX_CLEAR_BITS did not exist, and I reordered all the FP_ macros so tha= t they > are defined in the same order as the FPSCR_ macros. >=20 > James Clarke (2): > target-ppc: Make every FPSCR_ macro have a corresponding FP_ macro > target-ppc: mcrfs should always update FEX/VX and only clear exception > bits >=20 > target-ppc/cpu.h | 37 ++++++++++++++++++++++++++++--------- > target-ppc/translate.c | 15 +++++++++++---- > 2 files changed, 39 insertions(+), 13 deletions(-) >=20 --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --7IgncvKP0CVPV/ZZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWqtbJAAoJEGw4ysog2bOSPJQP/RqxAtrFnHJKcbmxQUrInG7/ EmrqcC5+SQiKclAe6yBkJ/azsc/j8fSGJgOzYvFXkFHpywmBI0miMnTlYwT1rvny N5EYWKGsX22qpwx0u3XuJv/7NziwQta5YAeKH6D4mrReLtPqb11f8XjFOjMoBanG LwmV+kOmGdsgbGHfAut8ej0gyJOvKlo8l/cS6h+kFNVCuhNPr+DyJVbAIm3+N0Bu uN2KLZzSsBUXx1SCq8nj3vvrhMvF2zdGE29psNUlWXw3DRAn6dhhuUsc+1UR1/dw yxMaYyyp3u6orzlH5nkKbsYbBs5Y5CRdMOaGdDkn6kv9jW7RSlgtVsM/STApZ1fo hTqzQdi37GnkcJisIGZDIghLKID4mo9XftMdF7xbp3RU1Y3fwOl+007u28mP30Ib OMXOcosL2jpHp0r4f/dnLsPQpG1bRnrOexMDV7aL0H40oOr7J2/UQTJizDNlGWcL XtUtK98OdBR2LoiO5gizbh0PIkcoC+26n2FWSbGuEVVBFKr9B77L6Nb5vN6XpH+i K5wipdtv9Yt+r/TXJeAR1QKr6ltVzW3E7sqkuvmgeFCTi3gbIxypnpqpu/lDRjTh zseZESLNu/4Hec7E7JqTGZiEyUsFmed40yDhFkfGyNdFbwyDgeIc1F+sh6rDFwSJ pf0wS9xF7duaNb1QDLZm =DR3C -----END PGP SIGNATURE----- --7IgncvKP0CVPV/ZZ--