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~