On 20 December 2013 17:34, Richard Henderson <r...@twiddle.net> wrote: > On 12/19/2013 01:57 PM, Peter Maydell wrote: >> If the input to float*_scalbn() is denormal then it represents >> a number 0.[mantissabits] * 2^(1-exponentbias) (and the actual >> exponent field is all zeroes). This means that when we convert >> it to our unpacked encoding the unpacked exponent must be one >> greater than for a normal number, which represents >> 1.[mantissabits] * 2^(e-exponentbias) for an exponent field e. >> >> This meant we were giving answers too small by a factor of 2 for >> all denormal inputs. >> >> Note that the float-to-int routines also have this behaviour >> of not adjusting the exponent for denormals; however there it is >> harmless because denormals will all convert to integer zero anyway.
> At least the float128 routine needs the same fix. > > I'm less certain about the floatx80 routine, since IIRC > that format has no implicit 1 bit -- it's always explicit. It still needs the increment, because according to http://en.wikipedia.org/wiki/Extended_precision#x86_Extended_Precision_Format the value for a denormal is m * 2^(1-exponentbias) versus m * (2^(e-exponentbias), so the off-by-one effect still holds; the explicitness of the integer bit isn't relevant here (it just means 'm' is the integer and mantissa bits, rather than either 0.mantissa or 1.mantissa as in the commit message above). thanks -- PMM
