amforth-devel — Development discussion and user support

Re: [Amforth-devel] >FLOAT

[pito <pi...@vo...>]

> surprised you get this answer without a '.' before
> 'FS.'.
so after a fresh install 4.0:

> .s
ok
> bl parse 7.77854e-12 >float fs.
7.1231794E-12  ok
> .s
0 16377 7 
1 16379 370 
2 16381 11 
3 16383 370 
ok
> .....
^
?? -13 6 
> .s
ok
> bl parse 7.77854e-12 >float . fs.
11514 -9.698532E-20  ok
> .s
0 16379 370 
1 16381 11 
2 16383 370 
ok
> 

Re: [Amforth-devel] >FLOAT

[Leon N M. <leo...@gm...>]

> > bl parse 7.77854e-12 >float fs.
> 
> 7.1231794E-12  ok

Like I said, 7.77854e-12 will give you a funky answer becasue 77854 > 32767 -- 
it can't fit in a regular integer. The top of the stack should be TRUE or FALSE 
(depending on whether it could do the coversion or not), so I'm a little 
surprised you get this answer without a '.' before 'FS.'.

Yesterday I uploaded a small change without testing it (the code to handle 
e,E,d,D) -- maybe that's causing a problem too.
-Leon

Re: [Amforth-devel] >FLOAT

[pito <pi...@vo...>]

Again with a clean stacK:
> .s
ok
> 
ok
> .s
ok
> bl parse 7.77854e-12 >float fs.
7.1231794E-12  ok
> .s
0 16377 7 
1 16379 370 
2 16381 11 
3 16383 370 
ok
> 

a lot of stuff on the stack there..P.

Re: [Amforth-devel] >FLOAT

[pito <pi...@vo...>]

my result (I am using the asm 4 primitives flib):

> bl parse 7.77854e-12 >float . fs.
11514 -9.698532E-20  ok
> Pito

Re: [Amforth-devel] >FLOAT

[Leon N M. <leo...@gm...>]

When you get it working, you'll find a bug -- 77854 is too large for a regular 
integer, so you'll get a wacky answer:

> bl parse 7.77854e-12 >float . fs.
-1 7.1231751E-12  ok

Take off a digit, and things get better:

> bl parse 7.7785e-12 >float . fs.
-1 7.7784925E-12  ok

I'm working on a rewrite with double length integers to fix this (and other 
problems).

-Leon

>Thursday 30 September 2010
>From: "pito" <pi...@vo...>
>Subject: Re: [Amforth-devel] >FLOAT
> Michael, thanks for the patch I will try!
> 
> Unfortunately I have >float there, I did upload it several times,
> but it seems this come with amf4.2. I'll try 4.0..Pito
> 
> 
> ---------------------------------------------------------------------------
> --- Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] >FLOAT

[pito <pi...@vo...>]

Yes, it is something with 4.2. I'm back to 4.0 and:

> bl parse 4.2232e-12 type
4.2232e-12 ok
> bl parse 4.2232e-12 >float
ok
> fs.
4.2231998E-12  ok
> bl parse 4.2232e-12 >float fs.
4.2231998E-12  ok
> 

I wrote to Matthias on 4.2 "issue", there must be something
different against 4.0 which is cousing me issues..P.

Re: [Amforth-devel] >FLOAT

[pito <pi...@vo...>]

Michael, thanks for the patch I will try!

Unfortunately I have >float there, I did upload it several times,
but it seems this come with amf4.2. I'll try 4.0..Pito

Re: [Amforth-devel] >FLOAT

[Kalus M. <mic...@on...>]

Hi.

Am 30.09.2010 um 14:18 schrieb pito:
..
>> bl parse 7.77854e-12 >float
> ^
> ?? -13 28
>>
> Why?? Pito

This indicates that >float is unknown to your system.
28 characters from the beginning of the line is the end of the  
unknown word = >float

There was a patch recently for quit.asm that moves the ^ sign to a  
more obvious position.
In quit.asm you find:
..
	.dw PFA_QUIT5
     	.dw XT_SLITERAL
	    .dw 4
	    .db  " ?? "
         .dw XT_ITYPE
	    .dw XT_BASE
	    .dw XT_FETCH
	    .dw XT_TO_R
	    .dw XT_DECIMAL
     	.dw XT_DOT
     	.dw XT_G_IN
     	.dw XT_FETCH
     	.dw XT_DOT
	    .dw XT_R_FROM
	    .dw XT_BASE
	    .dw XT_STORE

replace with following code:

; indicate error position:
         .dw XT_G_IN
         .dw XT_FETCH
         .dw XT_SPACES
         .dw XT_DOLITERAL
         .dw '^'
         .dw XT_EMIT
         .dw XT_CR
; show error code and position count
         .dw XT_SLITERAL
         .dw 4
         .db  " ?? "
         .dw XT_ITYPE
         .dw XT_BASE
         .dw XT_FETCH
         .dw XT_TO_R
         .dw XT_DECIMAL
         .dw XT_DOT
         .dw XT_G_IN
         .dw XT_FETCH
         .dw XT_DOT
         .dw XT_R_FROM
         .dw XT_BASE
         .dw XT_STORE           ; then
         .dw XT_CR    ; mk
     .dw XT_EXIT

You may play with this till it satisfies your needs.
Michael

Re: [Amforth-devel] >FLOAT

[pito <pi...@vo...>]

Hi,
I am doing following:

> bl parse 7.77854e-12
ok
> .s
0 16381 11 
1 16383 380 
ok
> type
7.77854e-12 ok
> bl parse 7.77854e-12 type
7.77854e-12 ok
> bl parse 7.77854e-12 >float
^
?? -13 28 
> 
Why?? Pito

[Amforth-devel] >FLOAT

[Leon N M. <leo...@gm...>]

Ok, I've added a very rough version of >FLOAT, which takes the address and 
length of a string and returns a float.

For example, here's an 8 character long string starting at address 471 -- first 
displayed using TYPE, then converted to a float and printed with FS.

> 471 8 type
46.3e-42 ok
> 471 8 >float fs.
4.6298862E-41  ok

It's not so accurate (and it's slow) because it's using some floating point 
arithmetic where integer arithmetic will do, but I'll deal with that later (I 
even hope to use a nice conversion algorithm, like 
<http://portal.acm.org/citation.cfm?id=368376>).

Two things:

1) How does exception handling work? >FLOAT is supposed to return FALSE if 
it's can't convert something to a string, but currently it will just throw an 
error because NUMBER will throw an error (since NUMBER is used under the 
hood). I'd like to catch any error NUMBER throws and then return FALSE as 
required.

2) Currently NUMBER accepts numbers with a leading negative sign, but not a 
leading positive sign (e.g. -101 works, but +101 causes an error). ANS94 
requires floats to work with both, so it would be easier for me if NUMBER works 
with both. (Does ANS94 say anything about accepting positive signs for 
integers?)

-Leon

Re: [Amforth-devel] Updated minicom uploader

[Al W. <al....@aw...>]

Thanks -- although I own a sourceforge project and use SVN, I'm not sure about 
the ettiquite or feasability of accesssing SVN directly. I doubt it will 
change again, anyway.


On Sunday, September 26, 2010 06:29:41 am Matthias Trute wrote:
> hi Al
> 
> Thank you for the update
> 
> > http://dl.dropbox.com/u/360343/am4up.c
> > 
> > A small change so that if the last character sent is not a end of line,
> > the uploader sends an end of line.
> 
> I put is right beside to the floating point library into
> the subversion tree.
> 
> 
> Matthias
> 
> 
> 
> ---------------------------------------------------------------------------
> --- Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] Interrupts in Forth

[Al W. <al....@aw...>]

> And it works for all cases where the hardware does not need to be reset
> to some "interrupt-handled" state. e.g. some interrupts need to be
> cleared somehow (mostly by reading one or more bytes from pre-defined
> IO registers). If that is _not_ done within the ISR, the interrupt will
> re-fire immediatly after the reti instruction.
> 
> Other interrupt sources such as timer interrupts do not need to
> acknowledged and they work absolutly fine with forth words.
> 
Understood.


> moving the reti instruction to some other place is crazy, but it could
> work and could solve the interrupt handling problem.

Actually, it seemssto work great. I just put the finish on an IR remote control 
transceiver using Amforth. It uses interrupt serial (your code, so not Forth 
interrupts), an  input capture interrupt, and output compare interrupt, and 
timer overflow interrupt (not all on the same timer) for different timing 
functions. I can read IR remotes and then rebroadcast what they send or do 
some analysis and send either previously read commands or "synthesized" 
commands. The interrupt handlers run with interrupts disabled and all end with 
+int using the patch from my previous e-mail.

I'd encourage others to try it. It actually helps with the above problem too, 
I think, although I have not tested that. My reasoning is that interrupts will 
stay disabled until you Forth code can reset the interrupt state. It does mean 
that interrupts stay off for  comparatively "long time" -- but remember that 
interrupt source flags will get set regardless of if interrupts are on or not. 
So if you get another interrupt, it will simply fire when the int+ executes. 
Theh only real danger is missing the same interrupt or multiple occurances of 
other interrupts. So keep the isr short and fast.  In my system, it limits how 
short an IR pulse I can emit (the pulse length, not the modulation) I can emit 
(but that length is still shorter than anything I've ever found with a real 
remote -- a small number of microseconds).

Anyway, something to try if you are working with interrupts.

Re: [Amforth-devel] Floating point - fatan

[pito <pi...@vo...>]

Hi, who needs urgently fatan - this is an aproximation, 5+ digits
precision for small arguments (-1..+1).

\ fatan library
\ amforth 4.0
\ Pito 26-9-2010
\ v 1.0.
\ needs Leon's flib (and Pito's asm flib v1.1 for speed)
-fatan
marker -fatan
\ calculate fatan
: fatan ( RAD -- arctangens )
\ x
fdup fdup f* 	\ x^2
fover fover f* 	\ x^3
fover fdup f* 	\ x x^2 x^3 x^4 --	
$E04D $3D6E f*  \ 0.05831938*x^4
frot   $B24E $3F43 f*       \ 0.76443945*x^2
$0000 $3f80 f+ f+            \ 1 + 0.76443945*x^2 + 0.05831938*x^4
frot frot $F805 $3EDC f* f+   \ (x + 0.43157974*x^3)
fswap f/ ;

******************************
Ex:
> _half fatan fs.
4.636495E-1  ok
> _third fatan fs.
3.2175684E-1  ok
> _-1 _1e-2 f* fatan fs.
-9.999667E-3  ok
> _1 _1e-3 f* fatan fs.
9.999997E-4  ok
> _1 _1e-3 f- fatan fs.
7.848919E-1  ok
> _-1 _half fatan fs.
4.636495E-1  ok
> _-1 _half f* fatan fs.
-4.636495E-1  ok
> _-1 _third f* fatan fs.
-3.2175684E-1  ok
> _third fatan fs.
3.2175684E-1  ok

Re: [Amforth-devel] Interrupts in Forth

[Matthias T. <mt...@we...>]

hi Al,

> 
> Howeer, if you use int! to set a "Forth" interrupt vector, the default isr 
> sets the "T" flag when an interrupt trips. It also stores the current vector in 
> a location where the interpreter can find it.
> 
> When the interpreter is about to dispatch it looks to see if the T flag is set 
> and, if it is, it forces the XT you set with int! for the given vector. Sounds 
> good.

And it works for all cases where the hardware does not need to be reset
to some "interrupt-handled" state. e.g. some interrupts need to be
cleared somehow (mostly by reading one or more bytes from pre-defined
IO registers). If that is _not_ done within the ISR, the interrupt will
re-fire immediatly after the reti instruction.

Other interrupt sources such as timer interrupts do not need to
acknowledged and they work absolutly fine with forth words.

> 
> However, it seems like using reti in the generic ISR is a bad idea. When an 
> interrupt fires, the AVR clears the global interrupt enable in status and it 
> stays clear until the reti. But that means you could get a nested interrupt 
> which would cause the previous interrupt to be dropped.

> I changed the reti to ret and then, of course, my "Forth" handler has to 
> execute +int before it exits to get interrupts back on again. I also added a 
> few lines of code so that if the Forth vector is 0, it doesn't try to execute 
> it. This all seems to work (although I'm having another apparently unrelated 
> problem with the code I actually want to write).


moving the reti instruction to some other place is crazy, but it could
work and could solve the interrupt handling problem. 

following algorithm: the forth system executes some code. An interrupt
fires and the ISR routine will start immediatly. Until now, it only sets
the T flag, saves the interrupt number and finishes with reti. This is
changed to a final ret in the generic isr. That means that the
interrupted code will continue to work and whenever the inner
interpreter gets called, the forth-level interrupt code can be executed.
The basic trick is: for the controller the interrupt handling is still
active. Thus no other interrupt will disturb us. Whenever the forth
level interrupt word finishes, the inner interpreter will call the reti
and signals the controller "yeah, interrupt handled". 

There are a few downsides: Any primitive word that changes the SREG
flags will need to take care for the externally set t flag. The most
important word is probably i!, which needs both a lot of time and 
disables interruptes internally.

The following (not really tested) patch should contain the basic ideas
so far..


diff --git a/core/amforth.asm b/core/amforth.asm 
index b339829..c6707c3 100644
--- a/core/amforth.asm
+++ b/core/amforth.asm
@@ -87,15 +87,16 @@ DO_EXECUTE:
 
 DO_INTERRUPT:
     ; here we deal with interrupts the forth way
     clt
+    savetos
     lds temp0, intcur
     ldi zl, LOW(intvec)
     ldi zh, HIGH(intvec)
     add zl, temp0
     adc zh, zeroh
-    ldd wl, Z+0
-    ldd wh, Z+1
-
-    clt ; clear the t flag to indicate that the interrupt is handled
+    ldd tosl, Z+0
+    ldd tosh, Z+1
+    ldi wl, low(XT_ISREXEC)
+    ldi wl, high(XT_ISREXEC)
     rjmp DO_EXECUTE
 
 .include "dict_appl_core.inc"
diff --git a/core/dict_core.inc b/core/dict_core.inc
index 09af97d..624fdc2 100644
--- a/core/dict_core.inc
+++ b/core/dict_core.inc
@@ -3,6 +3,8 @@
 .include "words/int-on.asm"
 .include "words/int-off.asm"
 .include "words/int-restore.asm"
+.include "words/isr-exec.asm"
+.include "words/isr-end.asm"
 
 .include "words/exit.asm"
 .include "words/execute.asm"
diff --git a/core/words/isr-end.asm b/core/words/isr-end.asm
new file mode 100644
index 0000000..105a1ca
--- /dev/null
+++ b/core/words/isr-end.asm
@@ -0,0 +1,15 @@
+; ( --  )  Interrupt
+; R( -- )
+; re-enables interrupts in an ISR
+VE_ISREND:
+    .dw $ff07
+    .db "isr-end",0
+    .dw VE_HEAD
+    .set VE_HEAD = VE_ISREND
+XT_ISREND:
+    .dw PFA_ISREND
+PFA_ISREND:
+    rcall PFA_ISREND1 ; clear the interrupt flag for the controller
+    rjmp DO_NEXT
+PFA_ISREND1:
+    reti
diff --git a/core/words/isr-exec.asm b/core/words/isr-exec.asm
new file mode 100644
index 0000000..94851da
--- /dev/null
+++ b/core/words/isr-exec.asm
@@ -0,0 +1,14 @@
+; ( xt -- ) Interrupt
+; R( -- )
+; executes an interrupt service routine
+VE_ISREXEC:
+    .dw $ff08
+    .db "isr-exec"
+    .dw VE_HEAD
+    .set VE_HEAD = VE_ISREXEC
+XT_ISREXEC:
+    .dw DO_COLON
+PFA_ISREXEC:
+    .dw XT_EXECUTE
+    .dw XT_ISREND
+    .dw XT_EXIT

Re: [Amforth-devel] Floating point - fsin, fcos, ftan

[pito <pi...@vo...>]

Matthias,
pls mind the Pito's asm lib update I've sent you (v1.1.) with a bug
fix.
I've been discussing the flib approach with Leon. There are
currently two ideas: to go full asm or combined. As from my
understanding nobody will be using the amforth for dsp, a forth flib
based on those 4 asm primitives is a good combination. Just my
point..Pito

Re: [Amforth-devel] Updated minicom uploader

[Matthias T. <mt...@we...>]

hi Al

Thank you for the update

> http://dl.dropbox.com/u/360343/am4up.c
> 
> A small change so that if the last character sent is not a end of line, the 
> uploader sends an end of line.

I put is right beside to the floating point library into
the subversion tree.


Matthias

Re: [Amforth-devel] Floating point - fsin, fcos, ftan

[Matthias T. <mt...@we...>]

Hi Pito,

great work, thank you. I've put it into the
application tree of the sourceforge subversion tree.

Matthias

Re: [Amforth-devel] Floating point - fsin, fcos, ftan

[pito <pi...@vo...>]

Hi, this is a new version of the lib - combination of amforth's
look-up table sinus calculus (see examples) within the 0-pi/2 range,
and, the actual sinus calculated by the taylor series. VERY GOOD
precision (6+ digits) and still fast. Pito.

\ fsin fcos ftan library
\ amforth 4.0
\ Pito 25-9-2010
\ v 3.0.
\ based on 4tH library by J.L. Bezemer
\ and amforth's sinus.frt example
\ needs Leon's flib (and Pito's asm flib v1.1 for speed)
-fsincostan
marker -fsincostan

\ the original JLB (taylor) does not work, a bug?
: >taylor fdup f* fover ;        \ setup for Taylor series
: _taylor fover f* frot fover ;
: +taylor f/ f+ frot frot ;      \ add Taylor iteration
: -taylor f/ f- frot frot ;      \ subtract Taylor iteration

\ put x in RADIANS within 2pi range
: >range                              
$0FDB $4049 fdup f+                  ( x pi2 )
fover fover f/                       ( x pi2 x/pi2 )
ffloor fover f*                      ( x pi2 mod )
frot fswap f-                        ( pi2 mod )
$0FDB $4049 fover                    ( pi2 mod pi mod )
f< if fswap f- else fnip then ;

: _fsin 
fdup >taylor                  		( x x2 x )
_taylor $0000 $40C0 -taylor                 ( x-3 x2 x3 )
_taylor $0000 $42F0 +taylor                 ( x+5 x2 x5 )
_taylor $8000 $459D -taylor                 ( x-7 x2 x7 )
_taylor $3000 $48B1 +taylor                 ( x+9 x2 x9 )
_taylor $4540 $4C18 -taylor                 ( x-11 x2 x11 )
_taylor $9466 $4FB9 +taylor                 ( x+13 x2 x13 )
_taylor $3BBC $5398 -taylor                 ( x-15 x2 x15 )
_taylor $BF77 $57A1 +taylor                 ( x+17 x2 x17 )
_taylor $15CA $5BD8 -taylor                 ( x-19 x2 x19 )
fdrop fdrop ;                          		( x-19 ) 

\ calculate fsin
: fsin  ( RAD -- sinus )
fdup f0< >r  fabs
>range 
fdup $0FDB $4049 f> if $0FDB $4049 f- 1 >r else 0 >r then 
fdup  $0FDB $3FC9 f> if $0FDB $4049 fswap f- then  
_fsin 
r> if fnegate then 
r> if fnegate then ;

\ calculate fcos	
: fcos   ( RAD -- cosinus )        
$0FDB $3FC9 f+ fsin ;

\ calculate ftan
: ftan ( RAD -- tangens )  
fdup fsin fswap fcos 
fdup f0= if abort else f/  then ;   

************************************************
Ex:
> _pi fsin fs.
0.0 ok
> _pi fcos fs.
-9.999999E-1  ok
> _-pi fsin fs.
0.0 ok
> _-pi fcos fs.
-1.0  ok
> _pihalf fsin fs.
9.999999E-1  ok
> _pihalf fcos fs.
0.0 ok
> _-pihalf fsin fs.
-9.999999E-1  ok
> _-pihalf fcos fs.
0.0 ok
> 1 s>f fsin fs.
8.414711E-1  ok
> 1 s>f fcos fs.
5.4030247E-1  ok
> 10 s>f fsin fs.
-5.4402137E-1  ok
> 10 s>f fcos fs.
-8.3907166E-1  ok
> -1 s>f fsin fs.
-8.414711E-1  ok
> -1 s>f fcos fs.
5.4030237E-1  ok
> -10 s>f fsin fs.
5.4402137E-1  ok
> -10 s>f fcos fs.
-8.3907127E-1  ok
> _pi ftan fs.
0.0 ok
> _-pi ftan fs.
0.0 ok
> _pihalf ftan fs.

> _-pihalf ftan fs.

> 1 s>f ftan fs.
1.5574075  ok
> 10 s>f ftan fs.
6.4836102E-1  ok
> -1 s>f ftan fs.
-1.5574076  ok
> -10 s>f ftan fs.
-6.483613E-1  ok
> 

Re: [Amforth-devel] Floating point - fsin, fcos, ftan

[pito <pi...@vo...>]

..more compact, faster by 25%.P.

\ fsin fcos ftan library
\ amforth 4.0
\ Pito 23-9-2010
\ based on 4tH library by J.L. Bezemer
\ needs Leon's flib (and Pito's asm flib v1.1 for speed)
-fsincostan
marker -fsincostan
\ the original JLB (taylor) does not work, a bug?
: >taylor fdup f* fover ;        \ setup for Taylor series
: _taylor fover f* frot fover ;
: +taylor f/ f+ frot frot ;      \ add Taylor iteration
: -taylor f/ f- frot frot ;      \ subtract Taylor iteration
\ put x in RADIANS within 2pi range                                 
   
: >range                              
$0FDB $4049 fdup f+                          ( x pi2 )
fover fover f/                       ( x pi2 x/pi2 )
ffloor fover f*                      ( x pi2 mod )
frot fswap f-                        ( pi2 mod )
$0FDB $4049 fover                            ( pi2 mod pi mod )
f< if fswap f- else fnip then ;
\ calculate fcos
: fcos
1 s>f fswap >range >taylor			( 1 x2 1 )
_taylor $0000 $4000 -taylor		( 1-2 x2 x2 )
_taylor $0000 $41C0 +taylor		( 1+4 x2 x4 )
_taylor $0000 $4434 -taylor		( 1-6 x2 x6 )
_taylor $8000 $471D +taylor		( 1+8 x2 x8 )
_taylor $7C00 $4A5D -taylor		( 1-10 x2 x10 )
_taylor $67E0 $4DE4 +taylor		( 1+12 x2 x12 )
\  _taylor $61D9 $51A2 +taylor		( 1-14 x2 x14 )
\  _taylor $3BBC $5598 +taylor		( 1+16 x2 x16 )
fdrop fdrop ;					( 1+12 )
\ calculate fsin 
: fsin $0FDB $3FC9 f- fcos ;
\ calculate ftan
: ftan fdup fsin fswap fcos f/ ;       \ ftan = fsin / fcos

Re: [Amforth-devel] Floating point - fsin, fcos, ftan

[pito <pi...@vo...>]

.. a better fsin:

\ calculate fsin 
: fsin _pihalf f- fcos ;

FYI:
\ Leon's flib and Pito's flib asm v 1.1 and atmega@25MHz:
> fmeasure ( _half fsin )
9.2494154E-3 secs duration of fsin FUNCTION ok
> fmeasure ( _half fcos )
1.23060155E-2 secs duration of fcos FUNCTION ok
> fmeasure ( _half ftan )
2.1606884E-2 secs duration of ftan FUNCTION ok
> fmeasure ( _pihalf fsin)
1.3543334E-2 secs duration of fsin FUNCTION ok
>pito

[Amforth-devel] Floating point - fsin, fcos, ftan

[pito <pi...@vo...>]

Hi,
here are the words for fsin, fcos, ftan. It uses taylor series for
fcos.

\ fsin fcos ftan library
\ amforth 4.0
\ Pito 23-9-2010
\ based on taylor and fsin fcos from 4tH library by J.L. Bezemer
\ needs Leon's flib (and Pito's asm flib v 1.1 for speed if
required)
\ needs Pito's float constants ( _pi)

-fsincostan
marker -fsincostan

\ Table with factorials n!
\ could be inlined in amforth 4.2
2. 2constant d1				\ 2!
24. 2constant d2			\ 4!
720. 2constant d3			\ 6!
40320. 2constant d4			\ 8!
3628800. 2constant d5		\ 10!
479001600. 2constant d6		\ 12!
_pi f2/ fconstant _pihalf
\ the original (taylor) does not work, bug?
: >taylor fdup f* fover ;            \ setup for Taylor series
: _taylor fover f* frot fover ;
: +taylor d>f f/ f+ frot frot ;      \ add Taylor iteration
: -taylor d>f f/ f- frot frot ;      \ subtract Taylor iteration
\ puts x in RADIANS within the 2pi                                  
  
: >range                              
_pi fdup f+                          ( x pi2 )
fover fover f/                       ( x pi2 x/pi2 )
ffloor fover f*                      ( x pi2 mod )
frot fswap f-                        ( pi2 mod )
_pi fover                            ( pi2 mod pi mod )
f< if fswap f- else fnip then
;
\ calculate fcos
: fcos
1 s>f fswap >range >taylor           ( 1 x2 1 )
_taylor d1 -taylor                 ( 1-2 x2 x2 )
_taylor d2 +taylor                 ( 1+4 x2 x4 ) 
_taylor d3 -taylor                 ( 1-6 x2 x6 )
_taylor d4 +taylor                 ( 1+8 x2 x8 )
_taylor d5 -taylor                 ( 1-10 x2 x10 )
_taylor d6 +taylor                 ( 1+12 x2 x12 )
fdrop fdrop                          ( 1+12 )
;
\ calculate fsin 
: fsin _pihalf f- >range fcos ;
\ calculate ftan
: ftan fdup fsin fswap fcos f/ ;         \ ftan = fsin / fcos

******************************
Ex:

> 1 s>f fsin fs.
8.414711E-1  ok
> 1 s>f fcos fs.
5.4030232E-1  ok
> -1 s>f fcos fs.
5.4030232E-1  ok
> -1 s>f fsin fs.
-8.414648E-1  ok
> _pi fsin fs.
-1.24561954E-7  ok
> _pi fcos fs.
-9.9989967E-1  ok
> -1 s>f ftan fs.
-1.5573962  ok
> 1 s>f ftan fs.
1.55740795  ok
> -10 s>f ftan fs.
-6.4836473E-1  ok
>

[Amforth-devel] Updated minicom uploader

[Al W. <al....@aw...>]

http://dl.dropbox.com/u/360343/am4up.c

A small change so that if the last character sent is not a end of line, the 
uploader sends an end of line.

See my last e-mail for how to install.

Re: [Amforth-devel] Some useful Float Constants - Update

[pito <pi...@vo...>]

Hi,
an update of useful floating point constants (rounded, single
precision).
Good for testing of flibs until finput available.
\

marker _float$constants_

\ some floating point constants, rounded

$0fdb $4049		fconstant 		_pi
$0fdb $c049		fconstant		_-pi

$04f3 $3fb5 	fconstant		_sqrt2
$04f3 $bfb5 	fconstant		_-sqrt2

$f854 $402d		fconstant 		_e
$f854 $c02d		fconstant		_-e

$7218 $3f31		fconstant 		_ln2
$7218 $bf31		fconstant		_-ln2

$5d8e $4013		fconstant 		_ln10
$5d8e $c013		fconstant 		_-ln10

$209b $3e9a		fconstant 		_log2
$209b $be9a		fconstant 		_-log2


$0000 $3f00 fconstant 			_half
$0000 $bf00 fconstant 			_-half

$aaab $3eaa fconstant 			_third
$aaab $beaa fconstant 			_-third

5 s>f 127 s>f f/ fconstant 		_mm2inch

10 s>f fconstant				_10
100 s>f fconstant				_1e2
1000 s>f fconstant				_1e3
10000 s>f fconstant				_1e4
_1e3 _1e3 f* fconstant 			_1e6
_1e6  _1e3 f* fconstant 		_1e9
_1e9  _1e3 f* fconstant 		_1e12
_1e12  _1e3 f* fconstant 		_1e15
_1e15  _1e3 f* fconstant 		_1e18

$cccd $3dcc fconstant 			_1e-1
$d70a $3c23 fconstant 			_1e-2
$126f $3a83 fconstant 			_1e-3
$b717 $38d1 fconstant			_1e-4
$c5ac $3727 fconstant			_1e-5
$37bd $3586 fconstant			_1e-6
$705f $3089 fconstant 			_1e-9
$bccc $2b8c fconstant			_1e-12
$1d7d $2690 fconstant			_1e-15
$92ef $2193 fconstant 			_1e-18

0 s>f fconstant _0
-1 s>f fconstant _-1
1 s>f fconstant _1

Re: [Amforth-devel] i! with XOR checksum of the whole flash

[pito <pi...@vo...>]

PS: In practise one has to store fxorsum to eeprom or better to
external i2c eeprom. The same shall be done with atmel eeprom XOR
sum, e.g. word "exor".
Both value shall be written outside the chip. At boot time do
checksum and write as e.g.:
" amforth 4.3 ATmega1284P f:ok e:ok "
The strategy on that needs to be elaborated, however.P.

[Amforth-devel] i! with XOR checksum of the whole flash

[pito <pi...@vo...>]

Hi,
this is just an EXPERIMENT. Words for flash XOR checksum (tested
with 1284p). 
Each i! writes a XOR checksum of the whole flash(!) to the variable
fxorsum. When after a crash something changes in flash the
checkflash shall show non zero. Not easy to simulate (as you cannot
use i!). The duration of fxor is 55ms at 25 MHz. Therefore let us
call it an experiment.

; word fxor ( flashsize-1 -- xorsum) flash XOR sum
; R( -- )
; Pito 21-9-2010
; returns XOR checksum of flash
VE_FXOR:
.dw $ff04
.db "fxor"
.dw VE_HEAD
.set VE_HEAD = VE_FXOR
XT_FXOR:
.dw PFA_FXOR
PFA_FXOR:
movw zl, tosl
ldi tosl, 0x00
ldi tosh, 0x00
loopfxor:
movw R14, zl
clr R18
lsl zl
rol zh
rol R18
out RAMPZ, R18
elpm R16, Z+
elpm R17, Z+
eor tosl, R16
eor tosh, R17
movw zl, R14
sbiw zl, 0x0001
sbiw zl, 0x0000
brne loopfxor
jmp_ DO_NEXT

\ i! with xorchecksum
\ pito 21-9-2010
\
\ XOR sum of flash in forth
: ffxor ( flashsize-1 -- ffxorsum )
0 swap begin 
dup i@ rot xor swap 1-
dup 0 = until drop ; 

variable fxorsum

: ixorsum! (i!) $ffff fxor fxorsum ! ;

' ixorsum! is i!

: checkflash $ffff fxor fxorsum @ - u. ;

*******************************************************
Ex:

> $ffff ffxor u.
A3F9  ok
> $ffff fxor u.
A3F9  ok
> fxorsum @ u.
6607  ok
> variable hello
ok
> $ffff ffxor u.
55B3  ok
> $ffff fxor u.
55B3  ok
> fxorsum @ u.
55B3  ok
> variable amforth
ok
> $ffff ffxor u.
2366  ok
> $ffff fxor u.
2366  ok
> fxorsum @ u.
2366  ok
> 
ok
> : checkflash $ffff fxor fxorsum @ - u. ;
ok
> checkflash
0  ok
> $ffff ffxor u.
B6E3  ok
> $ffff fxor u.
B6E3  ok
> fxorsum @ u.
B6E3  ok
>