flashforth-devel — FlashForth users and developers

[Flashforth-devel] Pic24_33 Stack sizes in 16byte multiplies

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

Hi, while playing with calling external C functions (with an intention to run larger drivers - fat, tft, etc) I see the rstack of max 256 bytes is not enough. Even a smaller Cfun (with rtc running in intr) consumes ~240bytes of rstack (rstack is used as the Cfun stack afaik).

I did following (I would suggest that for pic24/33 as the default setting, as the current sizing is not sufficient with these parts):

As the rstack (pstack) size is stored as a single byte in Operator_area, I am using N multiplies of 16bytes now.

The change is simple (param stack is not critical, but let us do it consistent):

24/33configs:
----------------
;;; USER AREA sizes for the OPERATOR task
.equ RETURN_STACK_SIZE, 20          ; 320, N*16 cells return stack
.equ PARAMETER_STACK_SIZE, 6        ; 96, N*16 cells parameter stack

ff os .s:
------------------
.equ urbuf,        ustart-us0 + UADDSIZE + 2        ; return stack
.equ usbuf,        urbuf + (16*RETURN_STACK_SIZE)        ; Parameter stack
.equ usbuf0,       usbuf - 2
.equ utibbuf,      usbuf + (16*PARAMETER_STACK_SIZE) ; Terminal Input buffer

;;;  Initial USER area pointer (operator)
.equ u0,           ustart-us0
.equ uareasize,    -us0+(16*RETURN_STACK_SIZE)+(16*PARAMETER_STACK_SIZE)+TIB_SIZE+HOLD_SIZE+UADDSIZE+2

stack dumps:
-----------------------------
hex r0 @ operator 3 + c@ 16 * dump
hex s0 @ operator 4 + c@ 16 * dump

It works fine here with all my stuff running.

I did not check which words may use the traditional sizes in bytes, but my bet is none :)
So it needs to be reviewed by experts.
Igor

[Flashforth-devel] External Cfun - Double Precison calculation example

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

Hi,
you may find the 9degee precision test in Double Precision, as an example how to call a quite heavy external C function.

https://github.com/igor-m/EXPERIMENTAL_ZZ/tree/master/examples/Cfun

9 Ctest hex  ok<$,ram> e23b 0 0 4022

where 0x402200000000e23b = 9.00000000010287770635

Igor.

Re: [Flashforth-devel] Fwd: Re: C function with more parameters in W0-W7

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

Solved, see examples.
I.

_____________________________________________________________
>> Od: "om1zz" <om...@vo...>
>> Komu: Mikael Nordman <mik...@fl...>
>> Datum: 04.06.2015 19:00
>> Předmět: C function with more parameters in W0-W7
>>
>>MIke, I cope with following issue:
>>
>>I have a Cfunction, with 5 parameters, returning float.
>>
>>So I am using W0-W7 for params.
>>
>>The strange:
>>First time after the fresh flash the Cfun (when pasting the below into teraterm) returns good result:
>>
>>decimal 100 2000 5. $0fdb $4049 $0fdb $4049 Ctest hex ok<#,ram> fa36 3eea
>>
>>I can do it repeatedly, I always get good results.
>>
>>decimal 100 2000 5. $0fdb $4049 $0fdb $4049 Ctest hex ok<#,ram> fa36 3eea
>>decimal 100 2000 5. $0fdb $4049 $0fdb $4049 Ctest hex ok<#,ram> fa36 3eea fa36 3eea
>>decimal 100 2000 5. $0fdb $4049 $0fdb $4049 Ctest hex ok<#,ram> fa36 3eea fa36 3eea fa36 3eea
>>
>>In the moment as I do something via prompt (before or after playing with Cfun), the Cfun returns garbage (and also it corrupts the system).
>>
>>For example, I cannot get good results when after the fresh flash I do:
>>$0fdb $4049 2constant pi
>>decimal 100 2000 5. pi pi Ctest hex
>>
>>I've tried push/pop W4-W7, but the same.
>>I.
>>
>
>
>
>------------------------------------------------------------------------------
>_______________________________________________
>Flashforth-devel mailing list
>Fla...@li...
>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

Re: [Flashforth-devel] Parameter stack size issue

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

hex s0 @ operator 4 + c@  ok<$,ram> 10e2 60

So 3 was wrong.
Thanks!
Igor

______________________________________________________________
> Od: Mikael Nordman <mik...@fl...>
> Komu: <fla...@li...>
> Datum: 06.06.2015 08:35
> Předmět: Re: [Flashforth-devel] Parameter stack size issue
>
>Read the operator code.
>
>Sent from my LG Mobile
>
>------ Original message------
>
>From: om1zz
>
>Date: Fri, 05/06/2015 23:05
>
>To: flashforth-devel;
>
>Subject:[Flashforth-devel] Parameter stack size issue
>
>With the 03.06.2015 release the param stack size is equal to rstack even when compiled with .equ RETURN_STACK_SIZE, 160 ; cells return stack .equ PARAMETER_STACK_SIZE, 96 ; cells parameter stack hex r0 @ operator 3 + c@ ok<$,ram> 1024 a0 hex s0 @ operator 3 + c@ ok<$,ram> 10c2 a0 sdump 10c2 :00 00 c4 10 00 00 06 0e 06 0e 80 11 22 10 78 11 ........_._. .x. 10d2 :03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 10e2 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 10f2 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 1102 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 1112 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 1122 :00 05 73 64 75 6d 70 6d 70 03 68 65 78 02 73 30 ..sdumpmp.hex.s0 1132 :01 40 08 6f 70 65 72 61 74 6f 72 01 33 01 2b 02 .@.operator.3.+. 1142 :63 40 04 64 75 6d 70 07 64 65 63 69 6d 61 6c 01 c@.dump.decimal. 1152 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .........
 ....... ok<#,ram> 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] Parameter stack size issue

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

<div style="font-size:10pt;"><p style="margin-top:0;margin-bottom:0;">Read the operator code.</p><div><signature_tag><p style="margin-top:0;margin-bottom:0;">Sent from my LG Mobile</p></signature_tag></div><p style="margin-top:0;margin-bottom:0;">&nbsp;</p><p style="margin-top:0;margin-bottom:0;">------ Original message------</p> <p style="margin-top:0;margin-bottom:0;"><b>From:&nbsp;</b>om1zz<om...@vo...></p><p style="margin-top:0;margin-bottom:0;"><b>Date:&nbsp;</b>Fri, 05/06/2015 23:05</p><p style="margin-top:0;margin-bottom:0;"><b>To:&nbsp;</b>flashforth-devel;</p><p style="margin-top:0;margin-bottom:0;"><b>Subject:</b>[Flashforth-devel] Parameter stack size issue</p><p style="margin-top:0;margin-bottom:0;">&nbsp;</p><pre>With the 03.06.2015 release the param stack size is equal to rstack even when compiled with

.equ RETURN_STACK_SIZE, 160 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;; &nbsp;cells return stack
.equ PARAMETER_STACK_SIZE, 96 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;; cells parameter stack

hex r0 @ operator 3 + c@ &nbsp;ok&lt;$,ram&gt; 1024 a0
hex s0 @ operator 3 + c@ &nbsp;ok&lt;$,ram&gt; 10c2 a0

sdump
10c2 :00 00 c4 10 00 00 06 0e 06 0e 80 11 22 10 78 11 ........_._. .x.
10d2 :03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
10e2 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
10f2 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
1102 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
1112 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
1122 :00 05 73 64 75 6d 70 6d 70 03 68 65 78 02 73 30 ..sdumpmp.hex.s0
1132 :01 40 08 6f 70 65 72 61 74 6f 72 01 33 01 2b 02 .@.operator.3.+.
1142 :63 40 04 64 75 6d 70 07 64 65 63 69 6d 61 6c 01 c@.dump.decimal.
1152 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ok&lt;#,ram&gt;

Igor.

------------------------------------------------------------------------------
_______________________________________________
Flashforth-devel mailing list
Fla...@li...
https://lists.sourceforge.net/lists/listinfo/flashforth-devel

</pre></div>

[Flashforth-devel] Parameter stack size issue

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

With the 03.06.2015 release the param stack size is equal to rstack even when compiled with

.equ RETURN_STACK_SIZE, 160           ;  cells return stack
.equ PARAMETER_STACK_SIZE, 96        ; cells parameter stack

hex r0 @ operator 3 + c@  ok<$,ram> 1024 a0
hex s0 @ operator 3 + c@  ok<$,ram> 10c2 a0

sdump
10c2 :00 00 c4 10 00 00 06 0e 06 0e 80 11 22 10 78 11 ........_._. .x.
10d2 :03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
10e2 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
10f2 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
1102 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
1112 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
1122 :00 05 73 64 75 6d 70 6d 70 03 68 65 78 02 73 30 ..sdumpmp.hex.s0
1132 :01 40 08 6f 70 65 72 61 74 6f 72 01 33 01 2b 02 .@.operator.3.+.
1142 :63 40 04 64 75 6d 70 07 64 65 63 69 6d 61 6c 01 c@.dump.decimal.
1152 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ok<#,ram>

Igor.

[Flashforth-devel] PIC24_33 Clock and Baudrate Calculator

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

Hi,
this is an excel table which may help pic24/33(HJ,FJ) users to calculate clock and baudrate such it fits within some limits.
Just enter into yellow fields and the table gets updated.
https://github.com/igor-m/EXPERIMENTAL_ZZ/tree/master/PIC24_33%20Clock%20and%20Baud%20Calc
I've created the table after messing with the suff for several hours, looking for a fit with usb/serial at 2.4576Mbit (my usbdongle and win7 allow), which works fine now (inclusive a smooth upload).
Igor

[Flashforth-devel] Fwd: Re: C function with more parameters in W0-W7

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

the files

https://github.com/igor-m/EXPERIMENTAL_ZZ/tree/master/examples/Cfun

______________________________________________________________
> Od: "om1zz" <om...@vo...>
> Komu: Mikael Nordman <mik...@fl...>
> Datum: 04.06.2015 19:00
> Předmět: C function with more parameters in W0-W7
>
>MIke, I cope with following issue:
>
>I have a Cfunction, with 5 parameters, returning float.
>
>So I am using W0-W7 for params.
>
>The strange:
>First time after the fresh flash the Cfun (when pasting the below into teraterm) returns good result:
>
>decimal 100 2000 5. $0fdb $4049 $0fdb $4049 Ctest hex ok<#,ram> fa36 3eea
>
>I can do it repeatedly, I always get good results.
>
>decimal 100 2000 5. $0fdb $4049 $0fdb $4049 Ctest hex ok<#,ram> fa36 3eea
>decimal 100 2000 5. $0fdb $4049 $0fdb $4049 Ctest hex ok<#,ram> fa36 3eea fa36 3eea
>decimal 100 2000 5. $0fdb $4049 $0fdb $4049 Ctest hex ok<#,ram> fa36 3eea fa36 3eea fa36 3eea
>
>In the moment as I do something via prompt (before or after playing with Cfun), the Cfun returns garbage (and also it corrupts the system).
>
>For example, I cannot get good results when after the fresh flash I do:
>$0fdb $4049 2constant pi
>decimal 100 2000 5. pi pi Ctest hex
>
>I've tried push/pop W4-W7, but the same.
>I.
>

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.

>

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

[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...>]

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

[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...>]

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

[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

[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

[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

[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] For-next loops - the New Design

[RMH <in...@ib...>]

Hello Igor,

maybe that floating point is sometimes used in some
circumstance, but in a real embedded pic-design you
will see it seldom in typical applications. That is
a forth approach and therefore the theme is not
really accessible to me.
The second one is, that a forth environment like FF
is a base for everyone to achieve his special goals
with his own labour. So, you have your agenda and the
toolbox and do it by yourself at first, if it is
really important. If you are successful, the community
will receive the result with friendliness and applaud
to you.

regards rmh



> 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] 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] For-next loops - the New Design

[RMH <in...@ib...>]

Yeah, me too!

With a lot of pepper and salt (more salt) in my beard
I appreciate the work of Mikael very very high.
Unfortunately my focus is today is not on pic, because
my actual customer need arm cortex M... , but in the
last time FF save my work, because their was a reliable
design ongoing.

With best wishes to Mikael,
have a good time,
RMH

Am 29.05.2015 um 14:09 schrieb Joe Ennis:
> Bravo!
>
> On 5/29/2015 2:28 AM, Mikael Nordman wrote:
>> Igor, this was the last service I will ever do for you.
>>
>> Why do want on purpose to make an incompatible fork on github ????????
>> And you have to rename it to something else than FlashForth.
>>
>> Go fuck yourself !
>>
>> On 29.05.2015 11:08, om1zz wrote:
>>> Mike, FANTASTIC!
>>> Thanks!
>>>
>>> PS: @Mike:
>>> I could not resist, of course :) , to make a small mod (editing two
>>> short ascii NFA strings in the pulled asm) and have the
>>> FOR and FOR2 working as per my spec :) :) (DISCLAIMER: FOR MY
>>> PERSONAL USE ONLY!)
>>> I did some quick tests, and run floats, fram stuff, etc. and it seems
>>> it works. I will test during the weekend more.
>>> Hopefully, internally you do not call FOR and FOR2 (here ?FOR FOR)
>>> with theirs NFAs :)
>>> Thanks,
>>> 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] For-next loops - the New Design

[Hedley D. <hed...@gm...>]

I concur ,

Thank you Mikael for all the time and effort you have put into this . My
prime use of Forth on Z80 30 years ago was getting prototype hardware up
and running .

Hedley .

On Friday, May 29, 2015, Joe Ennis <jo...@wh...> wrote:

> Bravo!
>
> On 5/29/2015 2:28 AM, Mikael Nordman wrote:
> > Igor, this was the last service I will ever do for you.
> >
> > Why do want on purpose to make an incompatible fork on github ????????
> > And you have to rename it to something else than FlashForth.
> >
> > Go fuck yourself !
> >
> > On 29.05.2015 11:08, om1zz wrote:
> >> Mike, FANTASTIC!
> >> Thanks!
> >>
> >> PS: @Mike:
> >> I could not resist, of course :) , to make a small mod (editing two
> >> short ascii NFA strings in the pulled asm) and have the
> >> FOR and FOR2 working as per my spec :) :) (DISCLAIMER: FOR MY
> >> PERSONAL USE ONLY!)
> >> I did some quick tests, and run floats, fram stuff, etc. and it seems
> >> it works. I will test during the weekend more.
> >> Hopefully, internally you do not call FOR and FOR2 (here ?FOR FOR)
> >> with theirs NFAs :)
> >> Thanks,
> >> Igor
> >>
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Flashforth-devel mailing list
> > Fla...@li... <javascript:;>
> > https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> >
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li... <javascript:;>
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

Re: [Flashforth-devel] RTC PCF8563T driver

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

Hi, 
if somebody seeks a driver for popular PCF8563T RTC (with lowest backup current consuption (200nA), afaik) you may find it at:
https://github.com/igor-m/EXPERIMENTAL_FF/tree/master/examples
Needs an i2c low level driver, for example from PeterJ for pic24.
Igor


______________________________________________________________
> Od: "om1zz" <om...@vo...>
> Komu: "flashforth-devel" <fla...@li...>
> Datum: 27.05.2015 19:36
> Předmět: Re: [Flashforth-devel] SPI FRAM and MRAM memory drivers
>
>Hi,
>there is a new driver for magnetoresistive MRAM (Everspin) MR25H40, 512kBytes, 8pin.
>Together with below FRAM (Ramtron, now Cypress) this is a great solution when you require a nonvolatile external 8pin SPI memory
>with up to 40/50Mhz SPI clock and write such fast as read (no write delays like eeprom/flash, no page buffers).
>Unlimited endurance.
>Could be used as a standard SPI sram, but nonvolatile (no external backup battery needed).
>Now we need a tiny filesystem written in forth :)
>Igor
>

Re: [Flashforth-devel] For-next loops - the New Design

[Herman A. <exp...@vn...>]

Igor
I think, we do not understand each other. Maybe I was not clear enough.
The current for-next in FF is very good for general purpose, when there 
is no problem with missing loop, and the skip function of  0 for  is 
beneficial. So, it needn't change.

My hypothetical n mfor...mnext would be an optional loop type to solve 
the full 16bit problem. It would be as fast, as the original for-next. 
In this case the meaning of n is the maximal distance from the reference 
position, that you want to rich.  If you substitute the for-next to 
mfor-mnext in your example, you will get the next results:

1 memtest
65535

2 memtest
131071

n memtest
n*65536-1

Because it is a non-standad loop structure, I think use it from a 
loadable text file, as Craig said.

BR
Attila


2015.05.28. 20:52 keltezéssel, om1zz írta:
> Attila
> with properly working 0 FOR you can do for example:
>
> 2variable count   \  just a counter to see the number of loops
>
> : memtest ( 64k_blocks -- )
>          0. count 2!      \ reset the counter
>          \ the BIG memory access loop, max 4,294,967,296 bytes
>          for
>                  65535 \ this should be normally 0
>                  for
> 		count 2@ 1. d+ count 2!   \ here you do something with memory
> 		next
> 	next
>          cr count 2@ ud. ;
>
> 1 memtest
> 65535  ok<#,ram>
> 2 memtest
> 131070  ok<#,ram>
> 16 memtest
> 1048560  ok<#,ram>
>    ok<#,ram>
>    ok<#,ram>
> 64 memtest
> 4194240  ok<#,ram>
>
> Now the count does not match as you miss a count every loop, but this is how the stuff works.
> It could be done with do-loop (which works with zero), but I think it would be more elegant with FOR.
> Igor
> ______________________________________________________________
>> Od: Herman Attila <exp...@vn...>
>> Komu: <fla...@li...>
>> Datum: 28.05.2015 17:21
>> Předmět: Re: [Flashforth-devel] For-next loops - the New Design
>>
>> I think the best solution of the  n for ... next  cycle, witch run
>> n-times, including n=0, as it is in the FF now. This principle
>> incopatible to cover the for full 16-bit range.
>>
>> To rich the full 16bit range must be defined an other for-next like
>> cycle, with different approach. In this case the goal is not to makes n
>> count, but to cover a non-zero long range. The cycle must run n to 0,
>> including n and 0. The 'next' decrements after testing for zero. We need
>> only to find the appropriate word-names.
>> Because it is mostly usable for memory addressing, maybe mfor-mnext.
>> n mfor r@ u. mnext   --->  n ... 0
>> 0 mfor r@ u. mnext   --->  0
>> 5 mfor r@ u. mnext   --->  5 4 3 2 1 0
>> 65535 mfor r@ u. mnext   --->  65535 65534 ... 1 0
>>
>> BR
>> Attila
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Flashforth-devel mailing list
>> Fla...@li...
>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>

Re: [Flashforth-devel] For-next loops - the New Design

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

Attila
with properly working 0 FOR you can do for example:

2variable count   \  just a counter to see the number of loops

: memtest ( 64k_blocks -- )
        0. count 2!      \ reset the counter
        \ the BIG memory access loop, max 4,294,967,296 bytes
        for
                65535 \ this should be normally 0
                for
		count 2@ 1. d+ count 2!   \ here you do something with memory
		next
	next
        cr count 2@ ud. ; 

1 memtest
65535  ok<#,ram>
2 memtest
131070  ok<#,ram>
16 memtest
1048560  ok<#,ram>
  ok<#,ram>
  ok<#,ram>
64 memtest
4194240  ok<#,ram>

Now the count does not match as you miss a count every loop, but this is how the stuff works.
It could be done with do-loop (which works with zero), but I think it would be more elegant with FOR.
Igor
______________________________________________________________
> Od: Herman Attila <exp...@vn...>
> Komu: <fla...@li...>
> Datum: 28.05.2015 17:21
> Předmět: Re: [Flashforth-devel] For-next loops - the New Design
>
>I think the best solution of the  n for ... next  cycle, witch run 
>n-times, including n=0, as it is in the FF now. This principle 
>incopatible to cover the for full 16-bit range.
>
>To rich the full 16bit range must be defined an other for-next like 
>cycle, with different approach. In this case the goal is not to makes n 
>count, but to cover a non-zero long range. The cycle must run n to 0, 
>including n and 0. The 'next' decrements after testing for zero. We need 
>only to find the appropriate word-names.
>Because it is mostly usable for memory addressing, maybe mfor-mnext.
>n mfor r@ u. mnext   --->  n ... 0
>0 mfor r@ u. mnext   --->  0
>5 mfor r@ u. mnext   --->  5 4 3 2 1 0
>65535 mfor r@ u. mnext   --->  65535 65534 ... 1 0
>
>BR
>Attila
>
>
>------------------------------------------------------------------------------
>_______________________________________________
>Flashforth-devel mailing list
>Fla...@li...
>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>