ARM testers, make note.

Iain Buclaw ibuclaw at ubuntu.com
Tue Aug 20 04:02:34 PDT 2013


On 20 August 2013 10:57, Iain Buclaw <ibuclaw at ubuntu.com> wrote:
> On 20 August 2013 10:07, Johannes Pfau <nospam at example.com> wrote:
>> Am Fri, 16 Aug 2013 18:33:14 +0200
>> schrieb "Iain Buclaw" <ibuclaw at ubuntu.com>:
>>
>>> I've pushed in pure implementations of functions in std.math,
>>> removing the workaround in core.stdc.math.
>>>
>>> This passes for x64/x32. Can any ARM testers please report any
>>> problems causecd by this update?
>>>
>>> Thanks
>>> Iain.
>>
>> I found a bug in the floor implementation for 64 bit reals:
>>
>> int exp = (vu[F.EXPPOS_SHORT] & 0x7ff) - 0x3ff;
>> The constants are wrong: At least 0x7ff must be 0x7ff0.
>>
>> (Remember, the 16 bits are s|eeeeeeeeeee|???? )
>>
>> However, the results are still wrong and I don't really understand how
>> that equation should work.
>>
>> The 'naive' and working way to write this is
>> --------
>> int exp = ((vu[F.EXPPOS_SHORT] & 0x7ff0) >> 4) -1023;
>> --------
>>
>> I assume 0x3ff should be changed to 0x3ff0 which is 1023 << 4. But then
>> the result is still left-shifted by 4 and needs to be right-shifted:
>> -------
>> int exp = (((vu[F.EXPPOS_SHORT] & 0x7ff0)) - 0x3ff0) >> 4;
>> -------
>>
>> is also working, but I don't know what's the advantage of this version.
>>
>> floatTraits also has EXPBIAS = 0x3f_e_0? How was that value obtained?
>>
>>
>
> Thanks, it should be:
>
> ---
> int exp = ((vu[F.EXPPOS_SHORT] >> 4) & 0x7ff) - 0x3ff;
>
>
>
> I'll raise a pull to fix as my pull into phobos got merged this morning. :o)
>

Pull:  http://j.mp/171CJl7



-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';


More information about the D.gnu mailing list