flashforth-devel

[Flashforth-devel] Floating point library - open issues

[om1zz <om...@vo...>]

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

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

[om1zz <om...@vo...>]

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
>

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

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
>

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

[om1zz <om...@vo...>]

Issue 4.

Mike,
it crashes here with latest trunk's OS, and 24config (except the uart pins def and 115k2) and

; UART buffer sizes
; Valid sizes are 7, 15, 31, 63, 127, 255, 511, 1023, etc.
.equ TX1_BUF_SIZE, 31  ; Use 0 for unbuffered TX.
.equ RX1_BUF_SIZE, 127
.equ RX1_OFF_FILL, 32   ; Fill level for XOFF

;;; USER AREA sizes for the OPERATOR task
.equ RETURN_STACK_SIZE, 96          ; 96=48 cells return stack
.equ PARAMETER_STACK_SIZE, 96        ; 96=48 cells parameter stack
.equ TIB_SIZE, 128                    ; 74 chars tib size
.equ HOLD_SIZE, 10                   ; 10 chars hold area

Look at this:

I ripped off the part were it crashes (2nd loop around pow), and I did following:

: test
for
fpi f-pi fpow fs. ." shall be 0.0274256931 "  cr
f-pi 33 s>f fpow fs. ." shall be -25465124213045828.470 "  cr
f-pi -33 s>f fpow fs. ." shall be -3.92693941578e-17 "  cr
next
;  ok<#,ram>

First manual calculation:

fpi f-pi fpow fs.  2.74257e-2  ok<#,ram>
f-pi 33 s>f fpow fs. -2.54651e16  ok<#,ram>
f-pi -33 s>f fpow fs. -3.92695e-17  ok<#,ram>

Good results.

Then the loop:

2 test 2.74257e-2 shall be 0.0274256931
-1.11997e29 shall be -25465124213045828.470
-9.40317e35 shall be -3.92693941578e-17
5.69610e32 shall be 0.0274256931
-1.11997e29 shall be -25465124213045828.470
-9.40317e35 shall be -3.92693941578e-17
 ok<#,ram>

Wrong results.

Then I've done without strings:

: test2
for
fpi f-pi fpow fs. cr
f-pi 33 s>f fpow fs. cr
f-pi -33 s>f fpow fs.  cr
next
;  ok<#,ram>
3 test2 2.74257e-2 OS FlashForth PIC24 31.05.2015
ESC

And finally I deleted cr:

: test3
for
fpi f-pi fpow fs. 
f-pi 33 s>f fpow fs. 
f-pi -33 s>f fpow fs. 
next
;  ok<#,ram>
3 test3 2.74257e-2 -2.54651e16 -3.92695e-17 2.74257e-2 -2.54651e16 -3.92695e-17 2.74257e-2 -2.54651e16 -3.92695e-17  
ok<#,ram>

Good results even with 1000 test3 .

When I deleted above cr in the bigtest (only the 3 one), it crashes somewhere else.
Igor

______________________________________________________________
> Od: Mikael Nordman <mik...@fl...>
> Komu: <fla...@li...>
> Datum: 01.06.2015 19:54
> Předmět: Re: [Flashforth-devel] Floating point library - open issues
>
>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
>>
>
>------------------------------------------------------------------------------
>_______________________________________________
>Flashforth-devel mailing list
>Fla...@li...
>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

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

[om1zz <om...@vo...>]

Mike, also I use ?? for error recognition

QABORTQ:
        rcall   XSQUOTE
        .byte   2
        ;.byte   '\?',7,7
        .ascii "??"
        .align  2
        bra     QABORT


I.

______________________________________________________________
> Od: "om1zz" <om...@vo...>
> Komu: <fla...@li...>
> Datum: 01.06.2015 23:05
> Předmět: Re: [Flashforth-devel] Floating point library - open issues
>
>Issue 4.
>
>Mike,
>it crashes here with latest trunk's OS, and 24config (except the uart pins def and 115k2) and
>
>; UART buffer sizes
>; Valid sizes are 7, 15, 31, 63, 127, 255, 511, 1023, etc.
>.equ TX1_BUF_SIZE, 31  ; Use 0 for unbuffered TX.
>.equ RX1_BUF_SIZE, 127
>.equ RX1_OFF_FILL, 32   ; Fill level for XOFF
>
>;;; USER AREA sizes for the OPERATOR task
>.equ RETURN_STACK_SIZE, 96          ; 96=48 cells return stack
>.equ PARAMETER_STACK_SIZE, 96        ; 96=48 cells parameter stack
>.equ TIB_SIZE, 128                    ; 74 chars tib size
>.equ HOLD_SIZE, 10                   ; 10 chars hold area
>
>Look at this:
>
>I ripped off the part were it crashes (2nd loop around pow), and I did following:
>
>: test
>for
>fpi f-pi fpow fs. ." shall be 0.0274256931 "  cr
>f-pi 33 s>f fpow fs. ." shall be -25465124213045828.470 "  cr
>f-pi -33 s>f fpow fs. ." shall be -3.92693941578e-17 "  cr
>next
>;  ok<#,ram>
>
>First manual calculation:
>
>fpi f-pi fpow fs.  2.74257e-2  ok<#,ram>
>f-pi 33 s>f fpow fs. -2.54651e16  ok<#,ram>
>f-pi -33 s>f fpow fs. -3.92695e-17  ok<#,ram>
>
>Good results.
>
>Then the loop:
>
>2 test 2.74257e-2 shall be 0.0274256931
>-1.11997e29 shall be -25465124213045828.470
>-9.40317e35 shall be -3.92693941578e-17
>5.69610e32 shall be 0.0274256931
>-1.11997e29 shall be -25465124213045828.470
>-9.40317e35 shall be -3.92693941578e-17
> ok<#,ram>
>
>Wrong results.
>
>Then I've done without strings:
>
>: test2
>for
>fpi f-pi fpow fs. cr
>f-pi 33 s>f fpow fs. cr
>f-pi -33 s>f fpow fs.  cr
>next
>;  ok<#,ram>
>3 test2 2.74257e-2 OS FlashForth PIC24 31.05.2015
>ESC
>
>And finally I deleted cr:
>
>: test3
>for
>fpi f-pi fpow fs. 
>f-pi 33 s>f fpow fs. 
>f-pi -33 s>f fpow fs. 
>next
>;  ok<#,ram>
>3 test3 2.74257e-2 -2.54651e16 -3.92695e-17 2.74257e-2 -2.54651e16 -3.92695e-17 2.74257e-2 -2.54651e16 -3.92695e-17  
>ok<#,ram>
>
>Good results even with 1000 test3 .
>
>When I deleted above cr in the bigtest (only the 3 one), it crashes somewhere else.
>Igor
>
>______________________________________________________________
>> Od: Mikael Nordman <mik...@fl...>
>> Komu: <fla...@li...>
>> Datum: 01.06.2015 19:54
>> Předmět: Re: [Flashforth-devel] Floating point library - open issues
>>
>>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
>>>
>>
>>------------------------------------------------------------------------------
>>_______________________________________________
>>Flashforth-devel mailing list
>>Fla...@li...
>>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>
>

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

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

There seems to be an issue with the NSTDIS bit in INTCON1.
FF PIC24 Interrupt routines rely on that nested interrupts do not 
occur.
Either there is some latent problem in FF or the float lib keeps 
resetting that bit.

There could also be some other conflict with the usage of the shadow 
registers between FF and the float lib.

If you use unbuffered transmission on TX1 you will experience less 
problems, since there are no
disturbing interrupts during the float calculations.

I will check details later.


On 02.06.2015 00:05, om1zz wrote:
> Issue 4.
>
> Mike,
> it crashes here with latest trunk's OS, and 24config (except the uart
> pins def and 115k2) and
>
> ; UART buffer sizes
> ; Valid sizes are 7, 15, 31, 63, 127, 255, 511, 1023, etc.
> .equ TX1_BUF_SIZE, 31  ; Use 0 for unbuffered TX.

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

[om1zz <om...@vo...>]

Yep, you have found it, it seems..

Here:

TXbuffer=0      dstack=96       bigtest passes (20minutes long run now)
TXbuffer=31    dstack=254     bigtest passes (several 8minutes rounds)

Igor.

______________________________________________________________
> Od: Mikael Nordman <mik...@fl...>
> Komu: <fla...@li...>
> Datum: 02.06.2015 08:56
> Předmět: Re: [Flashforth-devel] Floating point library - open issues
>
>There seems to be an issue with the NSTDIS bit in INTCON1.
>FF PIC24 Interrupt routines rely on that nested interrupts do not 
>occur.
>Either there is some latent problem in FF or the float lib keeps 
>resetting that bit.
>
>There could also be some other conflict with the usage of the shadow 
>registers between FF and the float lib.
>
>If you use unbuffered transmission on TX1 you will experience less 
>problems, since there are no
>disturbing interrupts during the float calculations.
>
>I will check details later.
>
>
>On 02.06.2015 00:05, om1zz wrote:
>> Issue 4.
>>
>> Mike,
>> it crashes here with latest trunk's OS, and 24config (except the uart
>> pins def and 115k2) and
>>
>> ; UART buffer sizes
>> ; Valid sizes are 7, 15, 31, 63, 127, 255, 511, 1023, etc.
>> .equ TX1_BUF_SIZE, 31  ; Use 0 for unbuffered TX.
>
>
>------------------------------------------------------------------------------
>_______________________________________________
>Flashforth-devel mailing list
>Fla...@li...
>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

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

[om1zz <om...@vo...>]

Mike,
even with Txbuffer=0 the fpow crashes, see the session below. 

2.3e 4.3e fpow  fs. 3.59277e1  ok<#,ram>

: tpw ticks 1000 for 2.3e 4.3e fpow drop drop next ticks swap - . ;  ok<#,ram>

tpw 170  ok<#,ram>
tpw 170  ok<#,ram>
tpw 170  ok<#,ram>
tpw 170  ok<#,ram>
tpw 170  ok<#,ram>
tpw OS FlashForth PIC24 31.05.2015
ESC
tpw 170  ok<#,ram>
tpw 170  ok<#,ram>
tpw 170  ok<#,ram>
tpw 170  ok<#,ram>
tpw OS FlashForth PIC24 31.05.2015
ESC
tpw 170  ok<#,ram>
tpw OS FlashForth PIC24 31.05.2015
ESC
tpw 170  ok<#,ram>
tpw 170  ok<#,ram>
tpw 170  ok<#,ram>
tpw OS FlashForth PIC24 31.05.2015
ESC
tpw 170  ok<#,ram>
tpw 170  ok<#,ram>
tpw 170  ok<#,ram>
tpw 170  ok<#,ram>
tpw OS FlashForth PIC24 31.05.2015
ESC
tpw 170  ok<#,ram>
tpw 170  ok<#,ram>
tpw 170  ok<#,ram>
tpw 170  ok<#,ram>
tpw 170  ok<#,ram>
tpw OS FlashForth PIC24 31.05.2015
ESC




______________________________________________________________
> Od: "om1zz" <om...@vo...>
> Komu: <fla...@li...>
> Datum: 02.06.2015 09:37
> Předmět: Re: [Flashforth-devel] Floating point library - open issues
>
>Yep, you have found it, it seems..
>
>Here:
>
>TXbuffer=0      dstack=96       bigtest passes (20minutes long run now)
>TXbuffer=31    dstack=254     bigtest passes (several 8minutes rounds)
>
>Igor.
>
>______________________________________________________________
>> Od: Mikael Nordman <mik...@fl...>
>> Komu: <fla...@li...>
>> Datum: 02.06.2015 08:56
>> Předmět: Re: [Flashforth-devel] Floating point library - open issues
>>
>>There seems to be an issue with the NSTDIS bit in INTCON1.
>>FF PIC24 Interrupt routines rely on that nested interrupts do not 
>>occur.
>>Either there is some latent problem in FF or the float lib keeps 
>>resetting that bit.
>>
>>There could also be some other conflict with the usage of the shadow 
>>registers between FF and the float lib.
>>
>>If you use unbuffered transmission on TX1 you will experience less 
>>problems, since there are no
>>disturbing interrupts during the float calculations.
>>
>>I will check details later.
>>
>>
>>On 02.06.2015 00:05, om1zz wrote:
>>> Issue 4.
>>>
>>> Mike,
>>> it crashes here with latest trunk's OS, and 24config (except the uart
>>> pins def and 115k2) and
>>>
>>> ; UART buffer sizes
>>> ; Valid sizes are 7, 15, 31, 63, 127, 255, 511, 1023, etc.
>>> .equ TX1_BUF_SIZE, 31  ; Use 0 for unbuffered TX.
>>
>>
>>------------------------------------------------------------------------------
>>_______________________________________________
>>Flashforth-devel mailing list
>>Fla...@li...
>>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>
>

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

[om1zz <om...@vo...>]

With experimental heap=256 and Cstack=512 dstack=96 rstack=96 and TXbuffer=0 fpow crashes on this kind of tests:

: tpw ticks 10000 for 3 s>f 4 s>f fpow fdrop next ticks swap - u. ; 

It seems fpow is buggy or uses even a bigger Cstack (are we handling Cstack properly?).

I've done this fpow workaround (in my lib):

float Cfpow(float x, float y)
{
    //return powf(x, y);
	// IgorM: simple workaround
    if (x <= 0.0) return 0.0;
    return expf(y*logf(x));
}

Which calculates with positive x, and works with heap=0 Cstack=128 dstack=96 rstack=96 Txbuffer=0 

: tpw ticks 10000 for 3 s>f 4 s>f fpow fdrop next ticks swap - u. ;  ok<#,ram>
tpw 3441  ok<#,ram>
tpw 3441  ok<#,ram>

and also the bigtest passes. 

Note: The workaround is simpler than the powf function, which does more..

But, still with Txbuffer none zero it crashes, so it seems we have got 2 issues here.

Igor.

______________________________________________________________
> Od: om1zz <om...@vo...>
> Komu: <fla...@li...>
> Datum: 02.06.2015 22:22
> Předmět: Re: [Flashforth-devel]Floating point library - open issues
>
>Mike,
>even with Txbuffer=0 the fpow crashes, see the session below. 
>
>2.3e 4.3e fpow  fs. 3.59277e1  ok<#,ram>
>
>: tpw ticks 1000 for 2.3e 4.3e fpow drop drop next ticks swap - . ;  ok<#,ram>
>
>tpw 170  ok<#,ram>
>tpw 170  ok<#,ram>
>tpw 170  ok<#,ram>
>tpw 170  ok<#,ram>
>tpw 170  ok<#,ram>
>tpw OS FlashForth PIC24 31.05.2015
>ESC
>tpw 170  ok<#,ram>
>tpw 170  ok<#,ram>
>tpw 170  ok<#,ram>
>tpw 170  ok<#,ram>
>tpw OS FlashForth PIC24 31.05.2015
>ESC
>tpw 170  ok<#,ram>
>tpw OS FlashForth PIC24 31.05.2015
>ESC
>tpw 170  ok<#,ram>
>tpw 170  ok<#,ram>
>tpw 170  ok<#,ram>
>tpw OS FlashForth PIC24 31.05.2015
>ESC
>tpw 170  ok<#,ram>
>tpw 170  ok<#,ram>
>tpw 170  ok<#,ram>
>tpw 170  ok<#,ram>
>tpw OS FlashForth PIC24 31.05.2015
>ESC
>tpw 170  ok<#,ram>
>tpw 170  ok<#,ram>
>tpw 170  ok<#,ram>
>tpw 170  ok<#,ram>
>tpw 170  ok<#,ram>
>tpw OS FlashForth PIC24 31.05.2015
>ESC
>
>
>
>
>______________________________________________________________
>> Od: "om1zz" <om...@vo...>
>> Komu: <fla...@li...>
>> Datum: 02.06.2015 09:37
>> Předmět: Re: [Flashforth-devel] Floating point library - open issues
>>
>>Yep, you have found it, it seems..
>>
>>Here:
>>
>>TXbuffer=0      dstack=96       bigtest passes (20minutes long run now)
>>TXbuffer=31    dstack=254     bigtest passes (several 8minutes rounds)
>>
>>Igor.
>>
>>______________________________________________________________
>>> Od: Mikael Nordman <mik...@fl...>
>>> Komu: <fla...@li...>
>>> Datum: 02.06.2015 08:56
>>> Předmět: Re: [Flashforth-devel] Floating point library - open issues
>>>
>>>There seems to be an issue with the NSTDIS bit in INTCON1.
>>>FF PIC24 Interrupt routines rely on that nested interrupts do not 
>>>occur.
>>>Either there is some latent problem in FF or the float lib keeps 
>>>resetting that bit.
>>>
>>>There could also be some other conflict with the usage of the shadow 
>>>registers between FF and the float lib.
>>>
>>>If you use unbuffered transmission on TX1 you will experience less 
>>>problems, since there are no
>>>disturbing interrupts during the float calculations.
>>>
>>>I will check details later.
>>>
>>>
>>>On 02.06.2015 00:05, om1zz wrote:
>>>> Issue 4.
>>>>
>>>> Mike,
>>>> it crashes here with latest trunk's OS, and 24config (except the uart
>>>> pins def and 115k2) and
>>>>
>>>> ; UART buffer sizes
>>>> ; Valid sizes are 7, 15, 31, 63, 127, 255, 511, 1023, etc.
>>>> .equ TX1_BUF_SIZE, 31  ; Use 0 for unbuffered TX.
>>>
>>>
>>>------------------------------------------------------------------------------
>>>_______________________________________________
>>>Flashforth-devel mailing list
>>>Fla...@li...
>>>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>>
>>
>
>------------------------------------------------------------------------------
>_______________________________________________
>Flashforth-devel mailing list
>Fla...@li...
>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

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

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

The problem is the use of W14 as the parameter stack pointer.
The math library uses W14 as a frame pointer.
These uses must coexist.
I am working on solution for that.
It uses lnk/ulnk in the interrupt routines.

Now it works much better but still there is one crash which I have not 
figured out.

On 03.06.2015 14:19, om1zz wrote:

> But, still with Txbuffer none zero it crashes, so it seems we have got 2 issues here.
>
> Igor.

>