All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Musta <tommusta@gmail.com>
To: Richard Henderson <rth@twiddle.net>, qemu-devel@nongnu.org
Cc: qemu-ppc@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 00/14] VSX Stage 4
Date: Fri, 08 Nov 2013 08:53:39 -0600	[thread overview]
Message-ID: <527CFAF3.50003@gmail.com> (raw)
In-Reply-To: <527C2F10.7040701@twiddle.net>

On 11/7/2013 6:23 PM, Richard Henderson wrote:
> 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.

Richard:

Thanks for your comments.  I concur with this comment on fp_status.

I am looking into the comments on fused multiply-add.

  reply	other threads:[~2013-11-08 14:54 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-06 20:31 [Qemu-devel] [PATCH 00/14] VSX Stage 4 Tom Musta
2013-11-06 20:31 ` [Qemu-devel] [PATCH 01/14] VSX Stage 4: Add VSX 2.07 Flag Tom Musta
2013-11-06 20:31 ` [Qemu-devel] [PATCH 02/14] VSX Stage 4: Refactor lxsdx Tom Musta
2013-11-06 20:31 ` [Qemu-devel] [PATCH 03/14] VSX Stage 4: Add lxsiwax, lxsiwzx and lxsspx Tom Musta
2013-11-06 20:31 ` [Qemu-devel] [PATCH 04/14] VSX Stage 4: Refactor stxsdx Tom Musta
2013-11-06 20:31 ` [Qemu-devel] [PATCH 05/14] VSX Stage 4: Add stxsiwx and stxsspx Tom Musta
2013-11-06 20:31 ` [Qemu-devel] [PATCH 06/14] VSX Stage 4: Add xsaddsp and xssubsp Tom Musta
2013-11-06 20:31 ` [Qemu-devel] [PATCH 07/14] VSX Stage 4: Add xsmulsp Tom Musta
2013-11-06 20:31 ` [Qemu-devel] [PATCH 08/14] VSX Stage 4: Add xsdivsp Tom Musta
2013-11-06 20:31 ` [Qemu-devel] [PATCH 09/14] VSX Stage 4: Add xsresp Tom Musta
2013-11-06 20:31 ` [Qemu-devel] [PATCH 10/14] VSX Stage 4: Add xssqrtsp Tom Musta
2013-11-06 20:31 ` [Qemu-devel] [PATCH 11/14] VSX Stage 4: add xsrsqrtesp Tom Musta
2013-11-06 20:31 ` [Qemu-devel] [PATCH 12/14] VSX Stage 4: Add Scalar SP Fused Multiply-Adds Tom Musta
2013-11-07 23:28   ` Richard Henderson
2013-11-07 23:30     ` Richard Henderson
2013-11-08  0:13       ` Richard Henderson
2013-11-13 20:49         ` Tom Musta
2013-11-13 23:14           ` Richard Henderson
2013-11-14 20:58             ` Tom Musta
2013-11-06 20:31 ` [Qemu-devel] [PATCH 13/14] VSX Stage 4: Add xscvsxdsp and xscvuxdsp Tom Musta
2013-11-06 20:31 ` [Qemu-devel] [PATCH 14/14] VSX Stage 4: Add xxleqv, xxlnand and xxlorc Tom Musta
2013-11-08  0:23 ` [Qemu-devel] [PATCH 00/14] VSX Stage 4 Richard Henderson
2013-11-08 14:53   ` Tom Musta [this message]
2013-11-13 14:35   ` Tom Musta
2013-11-08 15:55 ` Andreas Färber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=527CFAF3.50003@gmail.com \
    --to=tommusta@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.