[Vm-dev] Fwd: [Pharo-users] Set Rounding mode for IEEE floating point operations

[Levente Uzonyi]

Hi Steffen,

I can only guess that there's some library (IIRC Pharo uses e.g. FreeType)
used by the VM setting the rounding mode for its own purposes.
I would try to see if the rounding mode stays the same while vmParameter
56 (number of process switches since startup) stays the same. And if it 
does, I'd use that to minimize the number of times the FFI call has to be 
done to have the rounding mode you need. Because polling the parameter is 
probably faster than the FFI call.

Levente

On Thu, 24 May 2018, Steffen Märcker wrote:

>
> Hi Levente,
>
> I managed to change the rounding mode via an FFI call (Pharo, OSX). 
> However, the change seem to be not persistent/reliable, as the issues 
> below suggest. I suspect some context switching/restauration to be the 
> cause. Do you maybe have an idea what's going on?
>
> Best, Steffen
>
>
> Am .05.2018, 13:26 Uhr, schrieb Steffen Märcker <merkste at web.de>:
>
>> Hi,
>>
>> now I've observed the same issue. It might be related to context 
>> switching, since introducing a delay has a similar effect. Consider:
>>
>>    | FE_TONEAREST FE_DOWNWARD FE_UPWARD FE_TOWARDZERO |
>>    FE_TONEAREST  := 16r0000.
>>    FE_DOWNWARD   := 16r0400.
>>    FE_UPWARD     := 16r0800.
>>    FE_TOWARDZERO := 16r0C00.
>>    "For some reasons we have to call fegetround once."
>>    "c := LibC new fegetround."
>>    LibC new fesetround: FE_DOWNWARD.
>>    (Delay forSeconds: 1) wait.
>>    v1 := 1.0/10.0.
>>    LibC new fesetround: FE_UPWARD.
>>    v2 := 1.0/10.0.
>>    LibC new fesetround: FE_TONEAREST.
>>    v1 < v2.
>>
>> If the delay is inserted, the script evaluates to false. Using the same 
>> LibC-instance or creating a new one does not seem to change anything 
>> here. Interestingly, a similar approach in VisualWorks does not show 
>> this issue yet.
>>
>> Actually, I expect the FE_* macros to be platform/implementation 
>> dependent, as suggested here:
>> 
> http://www.enseignement.polytechnique.fr/informatique/INF478/docs/Cpp/en/c/numeric/fenv/FE_round.html
>>
>> [...]
>>
>> Am .05.2018, 11:57 Uhr, schrieb Serge Stinckwich 
>> <serge.stinckwich at gmail.com>:
>>
>>> What is really strange is when I print the following lines, I obtain 
>>> 2048:
>>>
>>> current := LibC uniqueInstance fegetround.
>>> LibC uniqueInstance fesetround: 2048.
>>> LibC uniqueInstance fegetround.
>>>
>>> and 0 when I remove the first line :
>>> LibC uniqueInstance fesetround: 2048.
>>> LibC uniqueInstance fegetround.
>>>
>>> [...]
>>>
>>>> On Thu, May 24, 2018 at 10:31 AM Steffen Märcker <merkste at web.de> 
>>>> wrote:
>>>>
>>>>> I actually made progress: It works like a charm! Basically, I
>>>>> implemented
>>>>> the same code as you. Testing is straightforward (using the constant
>>>>> values from libc):
>>>>>
>>>>>    current := LibC fegetround.
>>>>>    LibC fesetround: FE_DOWNWARDS.
>>>>>    v1 := 1.0/10.0.
>>>>>    LibC feesetround: FE_UPWARDS.
>>>>>    v2 := 1.0/10.0.
>>>>>    LibC feesetround: current.
>>>>>    v1 < v2. "true"
>>>>>
>>>>> > ​but apparently nothing happens when you do :
>>>>> >   LibC uniqueInstance fesetround: 1024.
>>>>> >   LibC uniqueInstance fegetround.
>>>>> > always return 0.​
>>>>>
>>>>> This is expected, since the fesetround function returns 0 only if the
>>>>> set
>>>>> operation was successful.
>