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

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

It looks like the FP routines use up the return stack and it overflows 
to the parameter stack.
With
hex r0 @ operator 3 + c@ dump
you can see the contents of the return stack.
The return stack area is usually zero where it has never been used.

Note that there is no extra return stack allocated for the FP lib 
routines.
The FF return stack is used both for FF and the FP-lib

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