On 10/02/2015 14:30, Maciej W. Rozycki wrote: > On Tue, 10 Feb 2015, Leon Alrae wrote: > >>> These cases could be addressed by either replacing subtraction from 0.0 >>> with multiplication by -1.0, or by tweaking the rounding mode as needed >>> temporarily. Given that the computational cost of multiplication is >>> uncertain and likely higher or at best the same as the cost of addition or >>> subtraction, I'd be leaning towards the latter solution. >> >> My first thought was to treat zero in NEG.fmt as a special case and use >> float32_chs() for it. But tweaking the rounding mode temporarily >> probably is better as we will get consistent behaviour for zero as well >> as input denormals which are squashed in float32_sub() when >> flush_inputs_to_zero flag is set (actually I'm not sure if legacy fp >> instructions should flush input denormals, but according to the spec >> this is implementation dependent so I won't worry about this). > > As expected setting CP1.FCSR.FS on a randomly picked R4400 processor: > > CPU0 revision is: 00000440 (R4400SC) > FPU revision is: 00000500 > > does flush a NEG.fmt's input denormal to 0. Given this program:
Good to know, thanks for checking that on the real CPU! Leon
