amforth-devel — Development discussion and user support

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

Re: [Amforth-devel] Marker etc.

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

Thanks Klaus,

The marker.asm did NOT work on 4.1. I made the 3 changes plus I had to chnage 
EE_SYS0 to 2 (juding from the Forth code and noting a compile error or 
EE_SYS0). 

It did strike me as odd though that there were not 4 places to change.  But I 
didn't get thought theh code enought to tell. 

I will look at the savesystem code. What would be ideal would be to configure a 
pin to boot into "restore mode" -- for example, since I am hooked up to USB 
for power, it could be configured to be the Rx line. Then a jumper could bring 
it low on boot (it would normally be high connected to the serial port) and 
trigger a restore. I'll try that soon.

Thanks again for your help.


On Wednesday, September 15, 2010 18:51:35 pm Kalus Michael wrote:
> 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

Re: [Amforth-devel] Word header in asm

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

Hi.

Here is an explanation example. Comments wellcome.
http://dl.dropbox.com/u/1170761/2dup.asm

Michael





Am 15.09.2010 um 10:01 schrieb Marcin Cieslak:

> On Wed, 15 Sep 2010, pito wrote:
>
>> Hi,
>> is there any expalnation available on what these
>> .dw $ff03    ;
>
> High byte:
>    $75 means the word is immediate word
>    $ff means the word is about to compiled normally
>
> Low byte:
>    $03 is a length of the word name in bytes that follows
>
> See core/words/docreate.asm, core/words/immediate.asm
> how its modified, and core/words/search-wordlist.asm
> how it's used.
>
>> ff02 ff05 in the header of a ams word definition means? And if
>> important, how is the implication when writing words in asm? Thanks,
>> Pito
>
> //Marcin
>
> PS. I am working on the f/ you sent me yesterday.
>
> ---------------------------------------------------------------------- 
> --------
> 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

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

Hi, the f* routine (my template based) works now (a bug - I did not
care on R0,1 - where MULT puts results..), so Marcin may redo it
into amforth look, when required.

> : test_mul_asm timer-start 30000 0  do _pi _ln2 f* drop drop loop
oktimer-stop 30000 s>f f/ fs. ." sec per mul-asm operation" ;
ok
> test_mul_asm
4.5088768E-5 sec per mul-asm operation ok
> _pi _pi f* fs.
9.869605  ok
> _1e9 _1e-12 _pi f* f* fs.
3.1415927E-3  ok
> 
So f* is much faster as the previous one (f* in forth 5ms). As you
may see the most of the time has been consumed by "_pi _ln2 f* drop
drop" overhead comparable to f* duration (my estimation is: f* raw
8us, f/ raw 30us). Still thinking how to precisely measure duration
of such forth words in the do loop..
And the fs. speed is now tremendous.. I like amforth! Pito.

Re: [Amforth-devel] Marker etc.

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

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

Re: [Amforth-devel] Marker etc.

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

Hi Al.
..
> The problem is once you mess up the flash you have to reprogram.

Adding a simple 'restoresystem on reset' helps allot. It just takes a  
copy of the original system vectors and puts them back into eeprom.  
As long as you did not overwrite amforth below DP by mistake this  
will work. Include your restoresystem word in the cold start routine  
cold.asm - here you find how it may be done:

Re: [Amforth-devel] Marker etc.

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

Al Williams <al....@aw...> wrote:
> Right, I understand the i@ word constitutes a bootloader of sorts. But I was 
> trying to get a way a student with no strange equipment could go back to a 
> default state. I guess another way would be to drop a marker at the end of the 
> default dictionary and have a config option that basically says "if the 
> specified pin is low on boot up, drop back to that marker and erase everything" 
> -- of course that could be bad too, but what I have in mind isn't critical at 
> all.

I did a presentation/workshop for the German hacking community two
weeks ago:

http://mrmcd1001b.metarheinmain.de/schedule/76/event/4008.en.html

I plugged three Arduinos to my laptop running FreeBSD. There was
a special workshop-jail (virtual instance) of the system configured
with two users "box1" and "box2". You could log in to one of them
and you immediately got a shared live terminal session. Both were
displayed on a beamer screen during the workshop (FORTH looks cool
in xterm with 24- or 36-point font).  Third Arduino running boot
software was ready with ICSP cables connected for a quick re-flashing
if needed (proved not to be necessary as I didn't use "marker" :-)

I was typing mostly on one, people hacking the other one, somebody
tried to paste Forth "Hello world!" example from Wikipedia (and
failed, since it was all-uppercase).

Next time I will leave more time for hands-on hacking like this (it
was targeted to a general tech public new to FORTH, 90% people knew
C).

By the way, the main point of the presentation was to demonstrate
certain weaknesses of programming Harvard architecture machines in
C (PROGMEM macro, string copying from flash to RAM to have unified
pointers, linker tricks to fake unified address space, etc.).

It is also not the FORTH favourite environment, but I find i@, e@
and friends a much more elegant solution to the problem.

//Marcin

Re: [Amforth-devel] Marker etc.

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

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

Re: [Amforth-devel] Marker etc.

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

Right, I understand the i@ word constitutes a bootloader of sorts. But I was 
trying to get a way a student with no strange equipment could go back to a 
default state. I guess another way would be to drop a marker at the end of the 
default dictionary and have a config option that basically says "if the 
specified pin is low on boot up, drop back to that marker and erase everything" 
-- of course that could be bad too, but what I have in mind isn't critical at 
all.

Re: [Amforth-devel] Marker etc.

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

On Wed, 15 Sep 2010, Al Williams wrote:

> One of my many hats is that I am a "blogger" for the venerable Dr. Dobb's
> Journal (I used to do columns for their magazines, but blogging is hipper ;)
> ).
>
> I wrote about my experiences with Amforth:
> http://www.drdobbs.com/blog/archives/2010/09/forth_love_if_h.html
>
> I am very impressed with it, although my original purpose might not be
> suitable. I was thinking of having inexpensive development boards for
> students. The problem is once you mess up the flash you have to reprogram. I
> was thinking long term it would be possible to either have a bootloader built
> in that would let you reflash a pristine system. Sort of a rescue mode.
>
> Maybe something I'll try when I ever get enough free time.

Amforth has a kind of bootloader built-in, since it constantly
flashes new words defined.

I am doing so-called in-line serial programming with two Arduinos
(cheap AVR development board with USB - http://www.arduino.cc/)
connected to each other. One runs the flasher (not yet in Forth, but
soon!) and the other one is being flashed. I don't even have a programmer
here.

Actually we have a project with 4 AVRs connected to another one (a
master) via the SPI interface, and we will probably try to test
re-programming them on the fly via SPI (exciting possibility of a
really self-replicating, self-deploying distributed programming).

There is also possibility to flash the Arduino board completely
in-line via the FTDI chip that is on-board there, but one needs to
solder a small 4-pin header to the board and it's kind of slow, but
works great in emergency.

//Marcin

Re: [Amforth-devel] Marker etc.

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

One of my many hats is that I am a "blogger" for the venerable Dr. Dobb's 
Journal (I used to do columns for their magazines, but blogging is hipper ;) 
).

I wrote about my experiences with Amforth: 
http://www.drdobbs.com/blog/archives/2010/09/forth_love_if_h.html

I am very impressed with it, although my original purpose might not be 
suitable. I was thinking of having inexpensive development boards for 
students. The problem is once you mess up the flash you have to reprogram. I 
was thinking long term it would be possible to either have a bootloader built 
in that would let you reflash a pristine system. Sort of a rescue mode.

Maybe something I'll try when I ever get enough free time.

Thanks again for all the replies.

Al W.



On Wednesday, September 15, 2010 17:15:33 pm Marcin Cieslak wrote:
> Al Williams <al....@aw...> wrote:
> > I saw amforth and popped it on an ATMega 8. Works but very little code
> > space. So I dug up an ATmega 16 (you can mark it as working on the
> > matrix -- it does).
> > 
> > However, I want to be able to use Marker. 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.
> 
> I have reproduced this error and dumped 6 images of flash
> and eeprom at the different stages:
> 
> http://saper.info/hg/forth/2010-sep-marker-problem/
> 
> You can fetch all the files using Mercurial (http://mercurial.seleni.com)
> with:
> 
> hg clone http://saper.info/hg/forth/2010-sep-marker-problem/
> 
> There is something strange when portion of flash memory gets erased for
> the new word.
> 
> --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:
> I saw amforth and popped it on an ATMega 8. Works but very little code space. 
> So I dug up an ATmega 16 (you can mark it as working on the matrix -- it 
> does). 
>
> However, I want to be able to use Marker. 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.

I have reproduced this error and dumped 6 images of flash
and eeprom at the different stages:

http://saper.info/hg/forth/2010-sep-marker-problem/

You can fetch all the files using Mercurial (http://mercurial.seleni.com) with:

hg clone http://saper.info/hg/forth/2010-sep-marker-problem/

There is something strange when portion of flash memory gets erased for
the new word.
 
--Marcin

Re: [Amforth-devel] Marker etc.

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

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

Re: [Amforth-devel] Marker etc.

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

Excellent! Reverting to 3.8 did the trick. Thanks for the quick response.


> 
> > The other issue I had was trying to use the 16's internal RC clock. It
> > would work until you wrote to flash (colon definition) and then it would
> > also die with no recourse but to reflash. With a 10MHz resonator (and
> > the right fuses) it works fine. Maybe my OSCCAL was too far off for 8MHz
> > (I didn't load the 8MHz OSCAL but the default 1MHz one was pretty
> > close).
> 
> It could be, that it has nothing to do with the resonator, but with colon
> breaking the dictionary.

Well it all works (except for marker) with a 10MHz resonator. I can create 
colon defintions as much as I want -- I just can't get rid of them. But with 
the internal clock any colon definition and you are done for. I suspect it is 
the timing of the flash write.

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

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

As an example the f/ "__DIV" code has been generated by C compiler
from "c=a/b". So we may that way create any floating point-function
in few seconds. However, it is up to amforth community to agree the
integration standards. When the ___frutine will be hard coded to
certain amforth registers, the Q is what happens when Matthias will
change the regs allocation in future. Therefore I've tried to create
an "interface" with ".def _tempX = Rx". The original ___froutine's
Rx registers will be renamed to _tmpX and renamed by ".def _tmp24 =
R14" as you want. The same as Matthias does with temp0,1,2...

So my point when integrating a ready to use asm code to amforth is
(AN Example):

; ..core\words\f_div.asm
; ( a b --  c ) Function c = a / b
; R( ? -- ? )
VE_FDIV:
.dw $ff02 
.db "f/"
.dw VE_HEAD
.set VE_HEAD = VE_FDIV
XT_FDIV:
.dw PFA_FDIV
PFA_FDIV:
.cseg
; $$$ REGS REDEFINITION $$$$$$$$$$$$$$$$$$$$$
; _tmpX is RX used in the code
.def	_tmp0 = R8
.def	_tmp1 = R9
;	.def	_tmp2 = Rx
.....
;	.def	_tmp15 = Rx
.def	_tmp17 = R13
.def	_tmp18 = R18		;  used as word
.....
.def	_tmp23 = R23
.def	_tmp24 = R16		;24 tosl
.def	_tmp25 = R17		;25 tosh
.def	_tmp26 = R26		;26 X	word used
.def	_tmp27 = R27		;27 X	
.def	_tmp28 = R14		;28 Y	do not use,word used	
.def	_tmp29 = R15		;29 Y	do not use,
.def	_tmp30 = R30		;30 Z  	Word used
.def	_tmp31 = R31		;31 Z
;  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
; save registers if needed
...........
push R30 
push R31 
;######################################################	
;main body
; Floating point B = A / B	
; IEEE 754
;     High        Low
; A = R25 R24 R27 R26  IN
; B = R23 R22 R31 R30  IN / OUT

fdiv:
; &&&&&&&& I/O &&&&&&&&&&&&
; fetch B 
mov _tmp22, tosl
mov _tmp23, tosh	
ld _tmp30, Y+
ld _tmp31, Y+
; fetch A	
ld _tmp24, Y+
ld _tmp25, Y+
ld _tmp26, Y+
ld _tmp27, Y+

CALL __DIV

; store B
st -Y , _tmp31
st -Y , _tmp30
mov tosh, _tmp23
mov tosl, _tmp22
jmp end_fdiv

;########## DO NOT TOUCH >>> THE ASM ROUTINE ###############	
__DIVfrank:
PUSH _tmp21
RCALL __UNxxx
CPI  _tmp23, 0x80
BRNE __DIV889
TST  _tmp1
__DIVjoe:
BRPL __DIV324
RJMP __RNM
...............
ROL  _tmp22
DEC  _tmp23
BRVS __DIV2332
__DIVmary:
RCALL __R443
POP  _tmp21
RET
;######################################################		
end_fdiv:
..........
pop R31
pop R30 
jmp_ DO_NEXT   ; this is the end of the word "f_div"

So the framework..P.

Re: [Amforth-devel] Marker etc.

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

On Wed, 15 Sep 2010, Erich Waelde wrote:

>
> avra is currently being worked on again, so it might work again in the near future.
>

It works if you apply my three patches (and remove unsupported .overlap / .nooverlap 
for now).

Links for patches:

3044547         Error:: ldi can only use a high register (r16 - r31)
                 https://sourceforge.net/tracker/?func=detail&aid=3044547&group_id=55499&atid=477233

3044545         movw y, z causes Error:: No register associated with y and z
                 https://sourceforge.net/tracker/?func=detail&aid=3044545&group_id=55499&atid=477233

3044541         .ifndef does not work (Can't redefine constant, use .SET)
                 https://sourceforge.net/tracker/?func=detail&aid=3044541&group_id=55499&atid=477233


Let me know if you have any trouble (can be on avra list too).

--Marcin