[Vm-dev] Re: Potential issue of primitiveTimesTwoPower in Spur 64
Nicolas Cellier
nicolas.cellier.aka.nice at gmail.com
Thu Feb 12 00:15:07 UTC 2015
2015-02-12 0:00 GMT+01:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:
>
>
> 2015-02-11 23:57 GMT+01:00 Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com>:
>
>> Some C functions in libm only take an int, not a long.
>> In 32 bits int=long, so no problem.
>> In 64 bits generally int=32 bits, long=64 bits, so casting a long to int
>> might lead to catastrophic loss and unexpected behavior.
>>
>> This is the case for example in primitiveTimesTwoPower
>> | rcvr arg |
>> <var: #rcvr type: #double>
>> arg := self popInteger.
>> rcvr := self popFloat.
>> self successful
>> ifTrue: [ self pushFloat: (self cCode: 'ldexp(rcvr, arg)'
>> inSmalltalk: [rcvr timesTwoPower: arg]) ]
>> ifFalse: [ self unPop: 2 ]
>>
>> arg will be a long in Spur64, won't it?
>> but ldexp only takes an int
>> double ldexp(double x, int exp);.
>>
>> So guess what if we call (1.0 timesTwoPower: 16r10000000001)...
>>
>
ah ah, but these do not even work in 32 bits COG currently:
Float infinity timesTwoPower: -16r10000000001.
0.0 timesTwoPower: 16r10000000001.
Both answer NaN but shouldn't...
The image side fallback code needs more care...
> Normally there should be a C compiler warning, and we should care of it.
>>
>> To solve this, maybe we need a
>>
>> <var: #arg type: #int>
>> arg := self signed32BitValueOf: stackTop.
>>
>
> of course, it's the same for primitiveSmallFloatTimesTwoPower (where
> things will really happen most of the time in Spur64)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150212/024920d8/attachment.htm
More information about the Vm-dev
mailing list