Re: [Flashforth-devel] Floating point library - open issues

[Mikael N. <mik...@fl...>]

I have no problem running your tests with FOR NEXT.
DO LOOP uses a two words more stack.
After running 256 loops there are no crashes.
You can see there are 3 words (1111) unused
on the return stack(96 byte ).
Adding some extra interrupt routines and DO LOOP will overflow the stack 
and crash the system.

  ok<$,ram>
hex r0 @ operator 3 + c@ dump
0f9c :f6 29 00 00 14 28 00 00 05 00 06 00 38 2f 00 00 .)...(......J/..
0fac :80 25 00 00 66 18 00 00 00 00 4a 19 00 00 6e 18 .%..n.....J...v.
0fbc :00 00 00 00 00 00 06 00 30 00 00 00 dc 08 00 00 ........0.......
0fcc :02 07 00 00 83 00 20 39 00 00 00 00 02 07 00 00 ...... 9........
0fdc :83 00 96 00 7f 00 00 00 c0 7a 48 03 00 00 02 07 .........zH.....
0fec :00 00 7f 07 00 00 7e 00 00 00 11 11 11 11 11 11 ......~......... 
ok<$,ram>


On 01.06.2015 12:32, om1zz wrote:
> 4. Stack(s) issue?
>
> When running following test (math functions calculations in a simple loop):
>
> https://github.com/igor-m/EXPERIMENTAL_ZZ/blob/master/examples/Big%20Torture%20Test%20NO%20NANS%20and%20BIG%20_POS_NEG.txt
>
> it locks (with "rtc time" clock running or not (inerrupt not init), with do-loop or for-next loop as the main test loop).
>
> With default settings:
> data stack = 96
> return stack = 96
> min XC16 stack = 128
> with dspic33 and pic24 chips, FF - 17.5.2015,
> @27MHz
>
> it usually locks near the end of the first loop.
>
> With settings like:
>
> data stack = 180
> return stack = 180
> min XC16 stack = 128
> with dspic33 and pic24 chips, with FF - 17.5.2015,
> @27MHz
>
> it locks after a longer time and ~dozens/hundreds of loops,
>
> With
>
> data stack = 254
> return stack = 254
> min XC16 stack = 128
> with dspic33 and pic24 chips, with FF - 17.5.2015,
> @27MHz
>
> it passes the test (it runs for about 8 minutes).
>
> With default 96 settings it restarts with OS after the crash, with 180 settings with W.
>
> When doing the specific calculations (at which it crashes) from the prompt, I get correct results and I see no issues.
> I think it should work with the 96 default, as the calculation within the test are single line, simple primitive
> calculations without any loops, nestings or recursions.
> It seems there is a subtile issue somewhere, I cannot find the cause however.
>
> Igor
>
>
>
> ______________________________________________________________
>> Od: "om1zz" <om...@vo...>
>> Komu: "flashforth-devel" <fla...@li...>
>> Datum: 30.05.2015 10:53
>> Předmět: Floating point library - open issues
>>
>> Hi,
>> as discussed with Mike before, there are few open issues with floating point library, which are not critical, but needs some tweaking to be perfect, however.
>>
>> 1. handling largest positive and largest negative number, it crashes now.
>> 2. printing NaN, crashes
>> 3. "e" for exponent
>>
>> 1.
>>
>> 0x7f7fffff == 3.402823466385288598E38
>> 0xff7fffff ==  -3.402823466385288598E38
>>
>> does
>>
>> $ffff $7f7f fs.  - crash
>> $ff7f $ffff fs. - crash
>>
>> 2.
>>
>> -1.0e3 flog fs. crash
>> -1.0e3 fsqrt fs. crash
>> $ffff $7fff fs. crash
>> $ffff $ffff fs. crash
>>
>> Those calcs shall print something like "NaN"
>>
>> The bove issues come from following - the floating point library was written for amorth, and the math written in asm returned specific agreed values for those results. XC16 returns different values in FF.
>>
>> 3.
>>
>> Mainly an issue with 0e 3e 123e as it could be recognised as HEX value when in hex. "E" may solve the problem, when agreed so.
>>
>> Igor
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>