On 11 March 2011 18:28, Nathan Froyd <froy...@codesourcery.com> wrote: > On Fri, Mar 11, 2011 at 06:12:25PM +0000, Peter Maydell wrote: >> Add min and max operations to softfloat. This allows us to implement >> propagation of NaNs and handling of negative zero correctly (unlike >> the approach of having target helper routines return one of the operands >> based on the result of a comparison op). > > Are these useful anyplace beside ARM? i.e. do they implement the > correct AltiVec/VSX/SSE* (any others?) semantics?
I had a look at the Altivec manual and I believe they're the right semantics for Altivec/VSX vminfp/vmaxfp. So that's two use cases (currently PPC has some hand-rolled stuff in op_helper.c which specialcases NaNs but a quick glance suggests it will get the -0 case wrong.) Intel's SSE MAXSD/MINSD etc have very weird behaviour for the special cases: if both operands are 0.0s of any sign you always get the second operand, so max(-0,+0) != max(+0,-0), and if only one operand is a NaN then the second operand is returned whether it is the NaN or not (so max(NaN, 3) != max(3, NaN). This is clearly hopelessly target-specific :-) I think the ARM/PPC semantics are the "obvious" ones: * handle input denormals by squashing to zero like other ops (you can always flip the status flags in your target wrapper if a particular instruction behaves differently) * handle NaN propagation in the same way as all other ops * maximum of (-0,+0) is +0, minimum of (-0,+0) is -0 so I think they have a pretty good chance of being useful for other architectures that have a floating point min/max. (They're the Java Math.min() and Math.max() semantics too.) -- PMM
