amforth-devel — Development discussion and user support

Re: [Amforth-devel] Minicom Uploader

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

I don't know how to turn word wrap on in the minirc.amforth file which is why 
you need the -w flag (or ^AW when running). Anyone know how to turn that on in 
the config file?


On Friday, September 17, 2010 14:09:46 pm Erich Waelde wrote:
> Hi Al,
> 
> On 09/17/2010 08:11 PM, Al Williams wrote:
> > http://dl.dropbox.com/u/360343/am4up.c
> 
> superb! Works for my arduino duemilanove, which is very
> resistive to amforth-upload.py.
> 
> Thanks for sharing this!
> 
> Erich
> 
> ---------------------------------------------------------------------------
> --- 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] Minicom Uploader

[Erich W. <ew....@na...>]

Hi Al,

On 09/17/2010 08:11 PM, Al Williams wrote:
> http://dl.dropbox.com/u/360343/am4up.c

superb! Works for my arduino duemilanove, which is very
resistive to amforth-upload.py.

Thanks for sharing this!

Erich

Re: [Amforth-devel] Minicom Uploader

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

Al, few years back somebody offered to me the 1802.. I was not fast
enough, a pity. Pito

Re: [Amforth-devel] Minicom Uploader

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

Ah the Python scripts are way more portable though. If you wish to include the 
uploader in the distribution tools, feel free.


On Friday, September 17, 2010 13:43:43 pm Matthias Trute wrote:
> Hi Al,
> 
> > I remembered that I wrote a simple upload program for the RCA 1802 a few
> > years back that had a lot of the same serial comm issues (handshaking,
> > etc). So I pulled the code out and ported it for amforth. Probably not
> > as useful for Windows users though since iti depends on minicom to
> > handle the serial I/O.
> > 
> > Very handy to be able to just be working at the terminal and upload a
> > word.
> > 
> > http://dl.dropbox.com/u/360343/am4up.c
> 
> Smart tool, cool. It simply works. Thank you. It makes the
> python-script(s) obsolete ;=)
> 
> 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] Minicom Uploader

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

Hi Al,

> I remembered that I wrote a simple upload program for the RCA 1802 a few years 
> back that had a lot of the same serial comm issues (handshaking, etc). So I 
> pulled the code out and ported it for amforth. Probably not as useful for 
> Windows users though since iti depends on minicom to handle the serial I/O.
> 
> Very handy to be able to just be working at the terminal and upload a word.
> 
> http://dl.dropbox.com/u/360343/am4up.c

Smart tool, cool. It simply works. Thank you. It makes the 
python-script(s) obsolete ;=)

Matthias

[Amforth-devel] Minicom Uploader

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

I remembered that I wrote a simple upload program for the RCA 1802 a few years 
back that had a lot of the same serial comm issues (handshaking, etc). So I 
pulled the code out and ported it for amforth. Probably not as useful for 
Windows users though since iti depends on minicom to handle the serial I/O.

Very handy to be able to just be working at the terminal and upload a word.

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

Here's the instructions from the comments inside the file:
// Filter to upload files to amforth from minicom
 // Al Williams http://www.hotsolder.com
// Originally for the elf (if you were wondering about the names)
// 17 Sept 2010 -- Public Domain

 // Minicom uploader has stdin connected to serial input,
 // stdout connected to serial output
 // stderr connects back to minicom
 // exit code 0 for success or non zero for fail
 
 // To set this up, use Control+AO and configure file transfer 
 // protcols. Set a name and the program file name 
 // Set Name=Y, U/D to U, FullScrn to N, IO-Red to Y, and Multi to N

// OR you can put this in /etc/minicom/minirc.amforth

/****************  Start file on line below
# Machine-generated file - use setup menu in minicom to change parameters.
pu pname10          YUNYNamforth
pu pprog10          am4up
pu baudrate         9600
pu bits             8
pu parity           N
pu stopbits         1
pu minit            
pu mreset           
pu backspace        BS
pu rtscts           No

 **************** Line above was the last line of the file */
// Then start minicom like this:
// minicom -w -D /dev/ttyUSB1 amforth
// This presumes you have am4up (this file compiled with gcc) on your path
// and you are using /dev/ttyUSB1.
// 
// To compile this file:
// gcc -o am4up am4up.c 
// Then copy the am4up executable to your path somewhere 
 
 // The character pacing is handled by waiting for the echo
 // The line pacing is handled by waiting for > or k
 // A ? in the prompt output indicates an error
 // Note you might still be in a defining word so 
 // when you get an error you might have to enter a ; to get back
 // to a normal prompt.


Al W.
 

Re: [Amforth-devel] Word header in asm

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

Pito,

> Hi,
> is there any expalnation available on what these 
> .dw $ff03    ;
> 
> ff02 ff05 in the header of a ams word definition means?

This is the combination of the string length (the lower half)
and some flag information. $ff means: no special flag is set,
$00 means immediate. Strictly speaking only  one bit of
the $00 is the immediate flag. This "strange" behavior
comes from the flash character: it does not cost anything
to set a bit to 0 but you need to erase a whole page when
turning it to 1. But since there are no other flags currently
in use, it does not matter at all. (maybe (again: MAYBE)
one other bit may be used for case insensitive dictionary 
search).

A side effect is, that amforth can use word with up
to 255 characters length. Which is absolutly theoretical
since the terminal input buffer has only 80 bytes and
the ram area the word WORD uses as its scratch buffer has
only 100 bytes. But it makes the code more compact.

> And if
> important, how is the implication when writing words in asm? Thanks,

standard words should use the $ff<length> information.
That should fit almost all cases (immediate words are
rare)

Matthias

Re: [Amforth-devel] Some nitpicking

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

Marcin,

while checking all the old mails, i came across yours
(and sorry for the delay, better late than never...)

> Small tidbits from 4.1:

all of them are now fixed. Thank you


> .include "words/2literal.asm"
> .include "words/2to_r.asm"
> .include "words/2r_from.asm"
> could go into some separate dict file for easy inclusion 
> ("dict_2x.inc" ?). They use rjmp, so I include them in
> my high memory (dict_appl_core.inc)

the rjmp can be changed easily, the dict_2x is worth a try?
maybe.... 

> I tried to add "tibsize.asm", but it complains that we
> have no EE_TIBSIZE. It seems that there is no such thing.

The size of the terminal input buffer is a compile time constant,
it should go to an environment? query.. deleted for now, no-one could
have used it anyway

Matthias

Re: [Amforth-devel] Floating point - f* f/ in asm .. calculate execution times

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

Michael,
here is a little bit more precise function duration measurement tool
(FDMT):

\
*******************************************************************
\ Precise measurement of duration of a FUNCTION
\ Pito 17-9-2010
\ based on the idea on FUNCTION separation by Michael Kalus
\ Pito's 4 primitives flib used
\ Pito's stopwatch used
\ atmega 1284p @25MHz


2000000. 2constant Nloop  \ 2mil measurements
fvariable t_fdrop
fvariable t_empty
fvariable t_empty1
fvariable t_function

: m1
\ measure empty loop1
_pi     100 0 timer-start do 20000 0
do sp@ >r r> sp! loop
loop timer-stop Nloop d>f f/ fdup t_empty1 f! 
cr fs. ." secs elapsed - empty1 loop" fdrop ;

: m2
\ measure fdrop
_pi     100 0 timer-start do 20000 0 
do sp@ >r fdrop r> sp! loop
loop timer-stop Nloop d>f f/ fdup t_fdrop f! 
cr fs. ." secs elapsed - fdrop loop" fdrop 

t_fdrop f@ t_empty1 f@ f- t_fdrop f!
cr t_fdrop f@ fs. ." secs duration of fdrop" ;

: m3
\ measure empty measurement loop
_pi _1e3 f* _e
100 0 timer-start do 20000 0
do fdup fdup fdrop fdrop loop
loop timer-stop Nloop d>f f/  fdup t_empty f! 
cr fs. ." secs elapsed - fdrop fdrop loop" fdrop fdrop ;

: fmeasure
\ did you run m1 m2 m3 already?

\ measure FUNCTION in measurement loop
_pi _1e3 f* _e 

100 0 timer-start do 20000 0
\
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
do fdup fdup f/ fdrop loop    \ <<<<< replaced one fdrop with
FUNCTION
\
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
loop timer-stop Nloop d>f f/ fdup t_function f! 

cr fs. ." secs elapsed - function fdrop loop"  fdrop fdrop

\ calculate clean FUNCTION duration
t_function f@ t_empty f@ f- t_fdrop f@ f+ t_function f!  \
t_function-(t_empty-t_fdrop)

cr t_function f@ fs. ." secs duration of f/ FUNCTION" ;


\
****************************************************************************************

Ex: (@25MHz f_cpu)

> m1

8.9653244E-6 secs elapsed - empty1 loop ok

> m2

1.4795408E-5 secs elapsed - fdrop loop
5.830083E-6 secs duration of fdrop ok

> m3

2.6738689E-5 secs elapsed - fdrop fdrop loop ok 

> fmeasure

2.9554117E-5 secs elapsed - function fdrop loop
8.6455116E-6 secs duration of f+ FUNCTION ok 

> fmeasure

2.858418E-5 secs elapsed - function fdrop loop
7.6755762E-6 secs duration of f- FUNCTION ok

> fmeasure

3.3853273E-5 secs elapsed - function fdrop loop
1.2944672E-5 secs duration of f* FUNCTION ok

> fmeasure

5.3068438E-5 secs elapsed - function fdrop loop
3.2159829E-5 secs duration of f/ FUNCTION ok


Thanks and have a nice weekend! Pito 

Re: [Amforth-devel] Marker etc.

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

Yes, grabbing the head and building for ATMEGA32 marker now works! 

Great!


On Thursday, September 16, 2010 16:46:44 pm Marcin Cieslak wrote:
> Al Williams <al....@aw...> wrote:
> > Not sure why, but I tried running the 8MHz internal RC again and now its
> > fine. Granted, before I was on the 4.1 and now I'm on 3.8 -- doubt
> > that's the difference though. Probably operator error!
> 
> There seems to be a bug in i@ introduced in 4.1 (see other postings). Can
> you try trunk now?
> 
> //Marcin
> 
> 
> ---------------------------------------------------------------------------
> --- 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] Marker etc.

[Marcin C. <sa...@sa...>]

Al Williams <al....@aw...> wrote:
> Not sure why, but I tried running the 8MHz internal RC again and now its fine. 
> Granted, before I was on the 4.1 and now I'm on 3.8 -- doubt that's the 
> difference though. Probably operator error!

There seems to be a bug in i@ introduced in 4.1 (see other postings). Can you 
try trunk now?

//Marcin

Re: [Amforth-devel] Marker etc.

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

Not sure why, but I tried running the 8MHz internal RC again and now its fine. 
Granted, before I was on the 4.1 and now I'm on 3.8 -- doubt that's the 
difference though. Probably operator error!

Re: [Amforth-devel] Marker etc.

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

> 
> Ok, but it is already mentioned ;=)
> 
Whoops I see that.

> Your complaints are welcome, but what could I do? Others complain that
> the scripts do not work at all due to <whatever>. I use the scripts on
> my systems and they work good enough. Maybe I intuitivly circumvent all
> the bugs and deficits already ;=)
> 
Please don't take anything as a complaint! I'm very impressed and I'm enjoying 
exploring. 


> > So as it stands now I must use a crystal or resonator
> 
> Most people who work with atmegas strongly recommend to use a quartz
> when it comes to serial communication (even at low speed such as 9600
> characters per second). The internal oscillator works at 8MHz which is
> cut down to 1MHz and it is known to be very unstable.

The default is 8 with an 8:1 prescaler, but you can pick 1:1 which I did. It 
all worked except for the write to flash.

> 
> And again: marker is currently broken, sorry for that. But it will
> come back. Sooner or later.

I've reverted to an older version and hacked it up with some of the newer 
device stuff and it works great! Thanks.

Re: [Amforth-devel] Marker etc.

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

> Most people who work with atmegas strongly
> recommend to use a quartz 
> when it comes to serial communication (even at low
> speed such as 9600
> characters per second). The internal oscillator
> works at 8MHz which is
> cut down to 1MHz and it is known to be very
> unstable.
> 
Hi,
some points I've gathered with serial i/o and terminals with amforth
(I am using XP, usb connectivity, atmega32 @11.0592MHz, atmega1284p
@25Mhz):
1. there are only 2 terminals which work reliable to me - Forfiter
and Mosaic Serial Terminal, the later I am using now.
2. the speeds - I run Mosaic up to 256kbits - absolutely no problem
3. you CANNOT use terminals which do not commit "ok" or each
character, amforth will not work - it will corrupt when writing new
words !!!!
Amforth needs a lot of time (sometimes fraction of seconds) in order
to compile and flash the word - when not commiting 'ok' terminal
will shoot characters to amforth and amforth will loose them!!
therefore you must wait until ready again. There is none handshaking
except this one!
4. amforth is very demanding as the baudrate precision is concerned,
the 8n1 communication can have +/- 4.5% baudrate precision, but
amforth will not compile with such spread. It means in practise
unless you have so called any_baud crystals (e.g. 11.0592 etc.) you
can compile only for specific speeds!!!
5. baudrate - you may change it in amforth session by: Num UBRR0L c!
where Num is the baudrate_constant - you may see the atmega guide
table 17.9-17.10 or you may calculate it for a given resonator or
crystal (!! with known frequency!!). When reset the amforth reverts
to default baudrate burned in.
Finetuning: you may try to change the constant a little bit until
the serial works reliable (do not forget to change the baudrate in
terminal as well when you change to next baudrate step)
6. crystals, resonators, internal RC - you will not have any issues
with standard crystals, but pls mind the 2 capacitors must have a
specific value as well (15-22pf). Be carefull with higher
frequences, crystals higher than 25MHz are so called overtone
crystals, they oscillate on 1/3 of the frequency depicted on its
body.
Resonators easily have 10-20% deviation from depicted frequency, so
it may not work with serial at given baudrate, however you may
measure its frequency and adjust baudrate constant accordingly. The
stability is good for serial. 
Internal RC - the chip makers claim up to 3% precision, so-so
usable, but it is voltage (! the chip voltage - pls mind very good
decoupling caps near the chip Vcc, Avcc) dependand so you may go out
of baudrate easily as well when voltage fluctuates (mind BOD
Brown-out Detector - when enabled (fuses!) a small drop in voltage
causes an reset (2ns impuls can trigger it), also EEPROM and FLASH
WRITE does not work properly when voltage fluctuates). You may
measure the frequency on a pin, then udjust baudrate accordingly,
or, some chips have internal udjustment (register value) for
finetuning (+/- 10%) of the internal frequency. I would recommend
internal oscillator up to 2400baud to be safe.
7. for amforth the finetuned serial communication with appropriate
terminal supporting 'ok' commit is absolutely vital!! It flashes in
its flash directly from serial, there are no large buffers (as far
as I know) with checksums, so any instability means corruption of
data.
8. From my other experience - electronics - the 97% of instabilities
and corruptions in sw area comes from hardware issues - wrong
capacitors, crystals, decoupling, voltage source instability,
interference between PC and development board, grounding, unreliable
sockets, connectors, cables too long, mobile phones laying near the
testbed, statics, etc.etc.)
Pito

Re: [Amforth-devel] Floating point library - 4 primitives f/ f* f+ f-

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

Marcin,

> Dnia 16.09.2010 Matthias Trute <mt...@we...> napisał/a:
> >
> > btw: I'm still working on the marker issue. strange case....
> 
> Matthias,
> 
> Reverting change 918 to istore_nrww.asm fixes the marker issue.

indeed. fixed. thank you.

Matthias

Re: [Amforth-devel] Floating point library - 4 primitives f/ f* f+ f-

[Marcin C. <sa...@sa...>]

Dnia 16.09.2010 Matthias Trute <mt...@we...> napisał/a:
>
> btw: I'm still working on the marker issue. strange case....

Matthias,

Reverting change 918 to istore_nrww.asm fixes the marker issue.

--Marcin

Re: [Amforth-devel] Floating point library - 4 primitives f/ f* f+ f-

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

Matthias,
if somebody may send to me the ready to run test cases for f* f/ f+
f-which runs in amforth, I will provide the results (e.g. I'am not
going to deal with uppercase words, as you know). Moreover, I cannot
write test cases as it might be an interest conflict then..

Btw, the marker is one of the most used words at least with me.. It
would be nice to have it in marker.asm. 

Pito.

Re: [Amforth-devel] Marker etc.

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

Al,

> I saw amforth and popped it on an ATMega 8. Works but very little code space. 

Yeah, atmega8 is more a mee-too system. Not really usable any more. If
you really want to use such little systems, you will have to go back
in time and use versions around 1.x or so. 

> So I dug up an ATmega 16 (you can mark it as working on the matrix -- it 
> does). 

Ok, but it is already mentioned ;=)

> 
> However, I want to be able to use Marker.

It already worked, and does not currently. But it will do so again.
But dont ask, when...

> I have uploaded the definiton several 
> different ways including the python shell (which appears not to handle 
> backspace well in interactive mode, by the way).  It seems to work, but after 
> you execute it (example: marker blah) the system will say OK but any input 
> will hang the system when you hit enter.

Your complaints are welcome, but what could I do? Others complain that
the scripts do not work at all due to <whatever>. I use the scripts on 
my systems and they work good enough. Maybe I intuitivly circumvent all 
the bugs and deficits already ;=)

> So as it stands now I must use a crystal or resonator

Most people who work with atmegas strongly recommend to use a quartz 
when it comes to serial communication (even at low speed such as 9600
characters per second). The internal oscillator works at 8MHz which is
cut down to 1MHz and it is known to be very unstable.

And again: marker is currently broken, sorry for that. But it will
come back. Sooner or later.

Matthias

Re: [Amforth-devel] Floating point library - 4 primitives f/ f* f+ f-

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

Pito,

> Hi Leon and Matthias,
> enclosed pls find my little contribution to floating with amforth

Great work. Thank you.

> (:-)).
> The library is provided as-is, no guarantees and warrantees, no
> liability fo any direct, indirect, consequent damages or losses..

There is are test programs for floating point numbers
at e.g.
http://www-personal.umich.edu/~williams/archive/forth/utilities/index.html

I've adapted the original hayes tester slightly (yes: the case is the
case ;=) , so it may worth a try for your routines as well.

btw: I'm still working on the marker issue. strange case....

Matthias

Re: [Amforth-devel] Floating point - f* f/ in asm

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

> But there is other Q I would like address - how to
> measure a word
> duration? Imagine to measure f/. So the loop might
> be:
Michael, to be more precise in what I like to address: how to
measure a "function" duration? P.

Re: [Amforth-devel] Floating point - f* f/ in asm

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

Michael, Thanks!! At least you have confirmed 3us, so my guess of
7us for an average amforth word is not so bad (:-)). I am using rtc
as well, however for these time measurements I use ticker (you may
see it somewhere in the post). I am thinking now to use 16bit
counter for the hw timer1 clocked by f_cpu and I will read its value
as well the info from timer variable (incremented by timer1
overflow). So I may get sub usec resoulution. However, the ticker
will make the measured time longer by ticker handling, you are
right.
I am using 30000 do-loop for those measurements so it is ok, I
guess. The resolution of my timer is 10ms (one shot).
But there is other Q I would like address - how to measure a word
duration? Imagine to measure f/. So the loop might be:

30000 0  do _pi _pi   f/    fdrop loop .... 
or
30000 0 _pi _pi do fdup fdup   f/   fdrop loop ...

the empty loop:

30000 0 _pi _pi do fdup fdup  fdrop  fdrop loop ...
or
30000 0 _pi _pi do    loop... Which one. So to measure you need to
know the duration of other words as well..
Simply how to isolate f/ as much as possible? The other possibility
is to fill the f/ and empty it directly in asm,, or simply run
everything in simulator. I've measured the f/ (735 cycles) and f*
(190) in simulator with real data, but not keen do it with every
word (:-))).  Pito







> So I have 3 / 0.05 = 60 cycles for 'one word'.
> 
> So where does amforth spend 24 more cycles? That
> is at an average the  
> overhead caused by my ISR time ticker of RTC, I
> guess.
> 
> To see a word "as is" connect an oscilloscope to a
> port pin. let an  
> empty loop toggle your port pin. Than add your
> word to the loop an  
> run again.
> In the resulting frequency difference you get the
> execution time of  
> your word.
> 
> Michael
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> > 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] Floating point - f* f/ in asm

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

Hi.

Am 16.09.2010 um 14:39 schrieb pito:
..
> PS: I am still thinking why the amforth overhead is so big?? It
> seems from my naive measurements a typical forth word takes ~7us
> plus minus.
> This is about 175 clock cycles @25MHz, or aprox 100 instructions -
> could it be so much? Just a stupid Q. Pito

I have a real time clock (RTC) implemented, so I can use time@ to see  
time in hours minutes seconds on stack. Defining this:

new
: one ;
: tt0 1000 0 do     loop ;
: tt1 1000 0 do one loop ;
: tt20  0 do tt0 loop ;
: tt21  0 do tt1 loop ;
time@ 10000 tt20 time@ 10000 tt21 time@ .s

I get:
» time@ 10000 tt20 time@ 10000 tt21 time@ .s
0 1181 26
1 1183 6
2 1185 0
3 1187 26
4 1189 5
5 1191 0
6 1193 57
7 1195 4
8 1197 0

00:04:57
00:05:26  --> 29s*10^7 empty loop
00:06:26  --> 60s*10^7 one loop

» time@ 10000 tt20 time@ 10000 tt21 time@ .s
0 1181 18
1 1183 40
2 1185 16
3 1187 19
4 1189 39
5 1191 16
6 1193 49
7 1195 38
8 1197 16

16:38:49
16:39:19  --> 30s * 10^7s empty loop
16:40:18  --> 59s * 10^7s one loop

We get 30s per 10^7 times one word,
or 3us for a single into and out word procedure.
On 20MHz atmega168 one instruction cycle takes 0.05us.
So I have 3 / 0.05 = 60 cycles for 'one word'.


The inner interpreter is:
...
           DO_COLON:
C:001c0a 93bf          push XH				2 2
C:001c0b 93af          push XL          ; PUSH IP	2 4
C:001c0c 01db          movw XL, wl			1 5
C:001c0d 9611          adiw xl, 1			2 7
           DO_NEXT:
           .endif
C:001c0e 01fd          movw zl, XL        ; READ IP	1 8
C:001c0f   +      readflashcell wl, wh			
C:001c0f 0fee      lsl zl				1 9
C:001c10 1fff      rol zh				1 10
C:001c11 9165      lpm wl, Z+				3 13
C:001c12 9175      lpm wh, Z+				3 16
C:001c13 9611          adiw XL, 1        ; INC IP	2 18

           DO_EXECUTE:
C:001c14 01fb          movw zl, wl			1 19
C:001c15   +      readflashcell temp0,temp1
C:001c15 0fee      lsl zl				1 20
C:001c16 1fff      rol zh				1 21
C:001c17 9105      lpm temp0, Z+			3 24
C:001c18 9115      lpm temp1, Z+			3 27
C:001c19 01f8          movw zl, temp0			1 28
C:001c1a 9409          ijmp				2 30


; ( -- ) Compiler
; R( xt -- )
; end of current colon word
VE_EXIT:
     .dw $ff04
     .db "exit"
     .dw VE_HEAD
     .set VE_HEAD = VE_EXIT
XT_EXIT:
     .dw PFA_EXIT
PFA_EXIT:
     pop XL						2 32
     pop XH						2 34
     rjmp DO_NEXT					2 36

total of 36 cycles, right?

So where does amforth spend 24 more cycles? That is at an average the  
overhead caused by my ISR time ticker of RTC, I guess.

To see a word "as is" connect an oscilloscope to a port pin. let an  
empty loop toggle your port pin. Than add your word to the loop an  
run again.
In the resulting frequency difference you get the execution time of  
your word.

Michael

Re: [Amforth-devel] Floating point - f* f/ in asm

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

Hi, the last one is f-. Even the amforth overhead compared to asm
float primitives is huge I did f- in asm too (all measurements
@25MHz):

> > test_empty_loop
> 4.0894465E-5 sec per empty loop operation ok

f- :

> test_sub_asm
4.0894465E-5 sec per fsub-asm operation ok
> _pi _pi f* _pi f- fs.
6.728013  ok
> _pi _pi f+ _pi f- fs.
3.141593  ok
> -10000 s>f -20000 s>f f- fs.
1.0E4  ok
>

PS: I am still thinking why the amforth overhead is so big?? It
seems from my naive measurements a typical forth word takes ~7us
plus minus.
This is about 175 clock cycles @25MHz, or aprox 100 instructions -
could it be so much? Just a stupid Q. Pito

Re: [Amforth-devel] Floating point - f* f/ in asm

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

Hi, the f+ works as well:

> test_empty_loop
4.0894465E-5 sec per empty loop operation ok
> test_fadd_asm
4.194304E-5 sec per fadd-asm operation ok
> test_fmul_asm
4.5088768E-5 sec per fmul-asm operation ok
> test_fdiv_asm
6.6060295E-5 sec per fdiv-asm operation ok
> test_sub_forth_asm  (f- as "fnegate f+")
8.5633698E-5 sec per fsub-forth-asm operation ok

And the fadd in full forth
> test_fadd_forth
1.06011045E-3 sec per fadd-forth operation ok

> _pi _pi f+ fs.
6.2831855  ok
> -11111 s>f -22222 s>f f+ fs.
-3.3333001E4  ok
> _1e3  _1e6 f+ fs.
1.00100005E6  ok
> 

Pito

Re: [Amforth-devel] Marker etc.

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

Hi, interesting! After dozens of dozens of reflashings I downloaded
the image of my flash and eeprom to investigate - after a few hours
of work with amfort (4.0, 1284p) I saw a couple (~6)of random words
written in eeprom's empty space as well as in flash'. So when you
write a code which hangs it may write randomly. So my first thougt
was to inhibit i! when not compiling word or not setting variable or
constant as it is deffered. But it is not possible, only with fuses.
So I did few words for XOR checksums (eexor, ffxor, which put the
simple XOR sum of flash and eeprom into eeprom (2 cells). It works,
and you may check the consistency of the system on boot fast (takes
~1sec to XOR 128kbytes @ 20MHz in amforth). However the sum changes
each time you do a i!. Not easy to track. My idea was to check at
boot time the XOR sum, when in error - to reflash the eeprom or
flash from an image stored in an external spi flash (e.g cheap
AT45DB041D 4mbit 8pin 66MHz). The idea was to write an actually
valid image to the external flash when brown-out detected, maybe asm
code could be fast enough to do it in few miliseconds until power
drops. However, to use the amforth with students means to calculate
with a lot of reflashes.. Pito

----- PŮVODNÍ ZPRÁVA -----
Od: "Kalus Michael" <mic...@on...>
Komu: "Everything around amforth"
<amf...@li...>
Předmět: Re: [Amforth-devel] Marker etc.
Datum: 16.9.2010 - 1:51:35

> Hi Al.
> 
> Seems the list does not take any attachments.
> Try these links:
> http://dl.dropbox.com/u/1170761/marker.asm
> http://dl.dropbox.com/u/1170761/savesystem.asm
> 
> > I presume this is broken because of the changes
> > to here and dp  
> > > recently.
> 
> 
> This is the old version I have on amforth3.6, may
> be its still good  
> with 3.8 :
> : pushee ( -- )
> here , heap , edp ,  edp 8 do i e@ ,  2 +loop ;
> : popee ( adr n -- )
> 0 do dup i + i@  i 2* 2 + e! loop drop ;
> : marker ( -- )
> edp >r here >r
> pushee create r> , r> ,
> does> >r r@ i@ r> 1+ i@ popee ;
> 
> Michael
> 
> 
> Am 16.09.2010 um 00:49 schrieb Al Williams:
> 
> > I tried entering this as Forth code and got the
> > same result. Not  
> > > sure what
> > changes you mean (since you define pushee and
> > popee). Also, I don't  
> > > think the
> > list took your attachment.
> >
> > I presume this is broken because of the changes
> > to here and dp  
> > > recently.
> > Anyway, for now I'm sticking with a hybrid 3.8
> > -- I did take some  
> > > of the
> > device and driver stuff out of 4.1 and got it
> > working with 3.8.
> > >
> >
> > On Wednesday, September 15, 2010 16:59:25 pm
> > Kalus Michael wrote:
> > >> Hi.
> >>
> >>
> >> Am 15.09.2010 um 21:24 schrieb Al Williams:
> >> ..
> >>
> >>> Any ideas on getting marker to work?
> >>
> >> maybe this version works. It copies the
> >> _entire_ system vector to
> >> >> flash, and pops it back when executing the
> >> marker word.
> >> >>
> >> : pushee ( -- )   dp , here , edp ,  edp 8 do i
> >> e@ ,  2 +loop ;
> >> >> : popee ( adr n -- ) 0 do dup i + i@  i 2* 2 +
> >> e! loop drop ;
> >> >> : marker ( -- )
> >>
> >>      edp >r dp >r
> >>      pushee create r> , r> ,
> >>      does> >r r@ i@ r> 1+ i@ popee ;
> >>
> >> I append marker.asm, include it in your
> >> application words if you  
> >> >> like.
> >> BUT since it was written for amforth-3.6 on
> >> atmega168 you have to do
> >> >> the changes mentioned in the file. (pushee has
> >> been called ,ee  
> >> >> there.)
> >>
> >> Michael
> >
> > ----------------------------------------------------------------------
> > > > 
> > > --------
> > 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
> > 
> 
> ------------------------------------------------------------------------------
> > 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