From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35147) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VeZrk-0008Cp-O7 for qemu-devel@nongnu.org; Thu, 07 Nov 2013 19:24:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VeZrc-0004CQ-AB for qemu-devel@nongnu.org; Thu, 07 Nov 2013 19:24:00 -0500 Sender: Richard Henderson Message-ID: <527C2F10.7040701@twiddle.net> Date: Fri, 08 Nov 2013 10:23:44 +1000 From: Richard Henderson MIME-Version: 1.0 References: <1383769916-5582-1-git-send-email-tommusta@gmail.com> In-Reply-To: <1383769916-5582-1-git-send-email-tommusta@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 00/14] VSX Stage 4 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Tom Musta , qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org On 11/07/2013 06:31 AM, Tom Musta wrote: > The single-precision scalar arithmetic instructions all interpret the most > significant 64 bits of a VSR as a single precision floating point number > stored in double precision format (similar to the standard PowerPC floating > point single precision instructions). Thus a common theme in the supporting > code is rounding of an intermediate double-precision number to single > precision. Modulo my comments wrt the actual computation of fma, the patches all look fine. But I'd like to also mention a pre-existing flaw/niggle in the ppc port. The conversions to/from in-register representation for the single-precision values should never raise exceptions. Yet we always use d.d = float32_to_float64(f.f, &env->fp_status); f.f = float64_to_float32(d.d, &env->fp_status); The use of env->fp_status is either wrong or extremely misleading. It sure looks like the operation affects global cpu state. It may be that that state is never copied back to the "real" fpscr and so doesn't actually affect cpu state, but how can I see that for sure? I think it would be better to implement ConvertSPtoDP_NP and ConvertSP64toSP exactly as written in the spec. Or at minimum use a dummy fp_status that's not associated with env. It should not matter what the "real" rounding mode is in either case, since values that are not exactly representable as single-precision values give undefined results. r~