qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 00/14] VSX Stage 4


From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH 00/14] VSX Stage 4
Date: Fri, 08 Nov 2013 10:23:44 +1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

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~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]