Re: [Flashforth-devel] Floating point library - open issues
Brought to you by:
oh2aun
Menu
▾
▴
Re: [Flashforth-devel] Floating point library - open issues
|
From: om1zz <om...@vo...> - 2015-06-01 22:39:43
|
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
>>
>
|
