amforth-devel — Development discussion and user support

Re: [Amforth] no-wdt

[Enoch <ix...@ho...>]

Rafael Gonzalez <ast...@ya...> writes:

> Hello list
>
> Trying to include dict_mcu.inc, I can't find file  words/no-wdt.asm
> It seems this file is missing from the distribution (amforth-5.0 or amforth-code trunk)

Matthias latest docs say:

"amforth provides wrapper words for the microcontroller instructions
SLEEP and WDR (watch dog reset). To work properly, the MCU needs more
configuration. amforth itself does not call these words."

and there is core/words/wdr.asm

Dealing with the fuses (WDTON) is currently outside Amforth scope.

Regards, Enoch.


>
> Greetings
> Rafael
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
> is your hub for all things parallel software development, from weekly thought 
> leadership blogs to news, videos, case studies, tutorials, tech docs, 
> whitepapers, evaluation guides, and opinion stories. Check out the most 
> recent posts - join the conversation now. http://goparallel.sourceforge.net/

[Amforth] no-wdt

[Rafael G. <ast...@ya...>]

Hello list

Trying to include dict_mcu.inc, I can't find file  words/no-wdt.asm
It seems this file is missing from the distribution (amforth-5.0 or amforth-code trunk)

Greetings
Rafael

Re: [Amforth] int_restore, etc.

[Enoch <ix...@ho...>]

Enoch <ix...@ho...> writes:

> Hello Matthias and all,
>
> "-int" (int-off.asm) counterpart is "int_restore" (int-restore.asm). So,
> why is this "int_restore" header commented out, i.e., not available to
> the high level?
>
> Candidly, as "+int" (int-on.asm) is a simple SEI instruction (Set Global
> Interrupt Flag) one would expect "-int" to be a simple CLI (Clear Global
> Interrupt Flag) but this is not the case...
>
> May I suggest:
>
> +int → SEI
> -int → CLI
> int_suspend → ( -- SREG ) CLI
> int_restore → ( SREG -- )
>
> Thanks, Enoch.
>

Here's my svn diff vis-a-vis r1366 for your consideration:

http://pastebin.com/0dhM599q

Thanks, Enoch.

>
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
> is your hub for all things parallel software development, from weekly thought 
> leadership blogs to news, videos, case studies, tutorials, tech docs, 
> whitepapers, evaluation guides, and opinion stories. Check out the most 
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] int_restore, etc.

[Enoch <ix...@ho...>]

Hello Matthias and all,

"-int" (int-off.asm) counterpart is "int_restore" (int-restore.asm). So,
why is this "int_restore" header commented out, i.e., not available to
the high level?

Candidly, as "+int" (int-on.asm) is a simple SEI instruction (Set Global
Interrupt Flag) one would expect "-int" to be a simple CLI (Clear Global
Interrupt Flag) but this is not the case...

May I suggest:

+int → SEI
-int → CLI
int_suspend → ( -- SREG ) CLI
int_restore → ( SREG -- )

Thanks, Enoch.

Re: [Amforth] Useful?

[Enoch <ix...@ho...>]

Enoch <ix...@ho...> writes:

> Matthias Trute <mt...@we...> writes:
>
> Hello Matthias,
>
>> Hi Enoch,
>>
>>>> Enochs code is a macro, assembling one single instruction SBI into
>>>> dictionary and naming it.
>>>> Calling that word will execute the SBI instruction.
>>>>
>>>> Michael
>>> 
>>> I confirm, the code works.
>>
>> Well. I think its definitly worth some documentation. It is
>> not obvious how to use it.
>
> Easy:
>
> Suppose we have a relay connected to PORTA.0
>
> PORTA 0 port:hi! relay_on
> PORTA 0 port:lo! relay_off
>
> We can do the same of-course via bitnames.frt but the above is
> accomplished through a single instruction.
>
> BTW, bitnames.frt, IMO, needs to be simplifed in two respects:
> 1. It is extremely rare for a port to be of bidirectional use.
> 2. Port address can be limited to 0..255.
>
> My own version follows:
>
> ----------------------------------------------------------------------
>
> \ define a port: 0 ≤ portadr ≤ $FF, 0 ≤ bitno ≤ 7.
> : port: create  ( portadr bitno -- )
>     1 swap lshift			\ make it a bitmask
>     >< or ,				\ mask at high byte
>   does>  ( -- portmask portadr )	
>     @i dup >< $ff and swap $ff and
> ;
>
> : hi?  ( portmask portadr -- f )
>     c@ and 0>
> ;
>
> : lo?  ( portmask portadr -- f )
>     c@ and 0=
> ;
>
> synonym port@ hi?
>
> : hi!  ( portmask portadr -- )
>     dup >r c@ or r> c!
> ;
>
> : lo!  ( portmask portadr -- )
>     dup >r c@ swap invert and r> c!
> ;
>
> : port!  ( portmask portadr f -- )
>     if hi! else lo! then
> ;
>
> : toggle  ( portmask portadr -- )
>     over over lo? port!
> ;
>
> \ PORTx.y is output
> : out!  ( portmask portadr -- )
>     1- hi!
> ;
>
> \ PINx.y is input
> : in!  ( portmask portadr -- )
>     1+ lo!
> ;
>
> ----------------------------------------------------------------------
>
>>> I suggest that these simple macros would become standard library
>>> offerings.
>>
>> I'll think about it. see above ;)
>>
>>>  Without these atomic bit set/clear one needs to wrap code by
>>> -int/+int if register bits are shared by different interrupt
>>> routines.
>>
>> Any given and active forth ISR is never interrupted itself by
>> another interrupt. The communication between ISR and the
>> main program is close but different (IMHO).
>
> That's no good. Interrupt routines MUST BE interruptible or otherwise
> they would introduce unacceptable latency. For example, suppose we are
> doing some signal processing and we need to take A/D samples at regular
> intervals... By the way, let the programmer worry about avoiding re-entrancy.

Sorry, correction: Re-enabling the interrupt system inside the interrupt
routine is the programmer's responsibility (after clearing the
appropriate interrupt flag, of-course).

Thanks, Enoch.

> The docs gave me the impression that this is the case... i.e., until the
> T flag is set the interrupt system is off but later we invoke the
> interrupt service word just as usual... 
> I'll have to visit your asm code :-(
>
> If the above is corrected the importance of those atomic
> (uninterruptible) SBI/CBI instructions becomes clear.
>
> Thanks, Enoch.
>
>> Matthias
>>
>>
>> ------------------------------------------------------------------------------
>> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
>> is your hub for all things parallel software development, from weekly thought 
>> leadership blogs to news, videos, case studies, tutorials, tech docs, 
>> whitepapers, evaluation guides, and opinion stories. Check out the most 
>> recent posts - join the conversation now. http://goparallel.sourceforge.net/
>
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
> is your hub for all things parallel software development, from weekly thought 
> leadership blogs to news, videos, case studies, tutorials, tech docs, 
> whitepapers, evaluation guides, and opinion stories. Check out the most 
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Useful?

[Enoch <ix...@ho...>]

Matthias Trute <mt...@we...> writes:

Hello Matthias,

> Hi Enoch,
>
>>> Enochs code is a macro, assembling one single instruction SBI into
>>> dictionary and naming it.
>>> Calling that word will execute the SBI instruction.
>>>
>>> Michael
>> 
>> I confirm, the code works.
>
> Well. I think its definitly worth some documentation. It is
> not obvious how to use it.

Easy:

Suppose we have a relay connected to PORTA.0

PORTA 0 port:hi! relay_on
PORTA 0 port:lo! relay_off

We can do the same of-course via bitnames.frt but the above is
accomplished through a single instruction.

BTW, bitnames.frt, IMO, needs to be simplifed in two respects:
1. It is extremely rare for a port to be of bidirectional use.
2. Port address can be limited to 0..255.

My own version follows:

----------------------------------------------------------------------

\ define a port: 0 ≤ portadr ≤ $FF, 0 ≤ bitno ≤ 7.
: port: create  ( portadr bitno -- )
    1 swap lshift			\ make it a bitmask
    >< or ,				\ mask at high byte
  does>  ( -- portmask portadr )	
    @i dup >< $ff and swap $ff and
;

: hi?  ( portmask portadr -- f )
    c@ and 0>
;

: lo?  ( portmask portadr -- f )
    c@ and 0=
;

synonym port@ hi?

: hi!  ( portmask portadr -- )
    dup >r c@ or r> c!
;

: lo!  ( portmask portadr -- )
    dup >r c@ swap invert and r> c!
;

: port!  ( portmask portadr f -- )
    if hi! else lo! then
;

: toggle  ( portmask portadr -- )
    over over lo? port!
;

\ PORTx.y is output
: out!  ( portmask portadr -- )
    1- hi!
;

\ PINx.y is input
: in!  ( portmask portadr -- )
    1+ lo!
;

----------------------------------------------------------------------

>> I suggest that these simple macros would become standard library
>> offerings.
>
> I'll think about it. see above ;)
>
>>  Without these atomic bit set/clear one needs to wrap code by
>> -int/+int if register bits are shared by different interrupt
>> routines.
>
> Any given and active forth ISR is never interrupted itself by
> another interrupt. The communication between ISR and the
> main program is close but different (IMHO).

That's no good. Interrupt routines MUST BE interruptible or otherwise
they would introduce unacceptable latency. For example, suppose we are
doing some signal processing and we need to take A/D samples at regular
intervals... By the way, let the programmer worry about avoiding re-entrancy.

The docs gave me the impression that this is the case... i.e., until the
T flag is set the interrupt system is off but later we invoke the
interrupt service word just as usual... 
I'll have to visit your asm code :-(

If the above is corrected the importance of those atomic
(uninterruptible) SBI/CBI instructions becomes clear.

Thanks, Enoch.

> Matthias
>
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
> is your hub for all things parallel software development, from weekly thought 
> leadership blogs to news, videos, case studies, tutorials, tech docs, 
> whitepapers, evaluation guides, and opinion stories. Check out the most 
> recent posts - join the conversation now. http://goparallel.sourceforge.net/

Re: [Amforth] Useful?

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

Hi Enoch,

>> Enochs code is a macro, assembling one single instruction SBI into
>> dictionary and naming it.
>> Calling that word will execute the SBI instruction.
>>
>> Michael
> 
> I confirm, the code works.

Well. I think its definitly worth some documentation. It is
not obvious how to use it.

> I suggest that these simple macros would become standard library
> offerings.

I'll think about it. see above ;)

>  Without these atomic bit set/clear one needs to wrap code by
> -int/+int if register bits are shared by different interrupt
> routines.

Any given and active forth ISR is never interrupted itself by
another interrupt. The communication between ISR and the
main program is close but different (IMHO).

Matthias

Re: [Amforth] file / word name

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

Hi Wis,

> Forth word "inituser" is found in the file "user_init.asm".  This
> makes it difficult to follow the startup execution flow.
> 
> Is it possible to change one or the other to make it consistent with
> the rest of the Forth words?

It was an artefact, I simply forgot to change the filenames. Thanks

Matthias

[Amforth] file / word name

[Macomson, W. <wis...@in...>]

Forth word "inituser" is found in the file "user_init.asm".  This makes it difficult to follow the startup execution flow.

Is it possible to change one or the other to make it consistent with the rest of the Forth words?

Regards,

-wis 

Re: [Amforth] Useful?

[Enoch <ix...@ho...>]

"Michael Kalus" <mi-...@t-...>
writes:

> Hi Matthias.
>
> ...
>> There is currently no
>> way to switch between forth and machine code (that would
>> be ;CODE btw)
>
>
> You may go from low to high level and back:
>
> code <name>
> (some code)
> ; -- jump to high level:
>     ldi  XL,low(pfa_forthISR)
>     ldi  XH,high(pfa_forthISR)
>     jmp  DO_NEXT
> pfa_forthISR:
>     .dw  XT_MAINWORD
> ; -- back to low level:
>     .dw  PC+1  ; next IP
>     .dw  PC+1  ; next cfa
> (more code )
> end-code
>
> But be shure to save all registers you use if you do so.
>
> ---
>
> Enochs code is a macro, assembling one single instruction SBI into  
> dictionary and naming it.
> Calling that word will execute the SBI instruction.
>
> Michael

I confirm, the code works. I was not aware we have ;code as in other
implementations. The idea came when examining lib/assembler-test.frt

I suggest that these simple macros would become standard library
offerings.  Without these atomic bit set/clear one needs to wrap code by
-int/+int if register bits are shared by different interrupt
routines. In my current project (at90can128 based) the AVR also has a
recommended general purpose register, GPIOR0 [0x1E (0x3E)], for this
very purpose.

Thank you, Enoch.

----------------------------------------------------------------------

: _bitio
    dup $1F U> if &-9 throw then
    over $7 U> if &-9 throw then
;

: port:hi!  ( portadr bitno -- )	    \ SBI
    swap $20 - _bitio
    3 lshift or $9A00 or
    code , end-code
;

: port:lo!  ( portadr bitno -- )	    \ CBI
    swap $20 - _bitio
    3 lshift or $9800 or
    code , end-code
;

----------------------------------------------------------------------


>
>
>
>
> Am 14.02.2013 um 20:14 schrieb Matthias Trute:
>
>> hi Enoch,
>>
>>
>>> I'd like to see this forum also offering code snippets, so here's my
>>> first humble attempt of harnessing the atomic bit manipulation
>>> instructions.
>>>
>>> : port:hi ( portadr bitno -- )	    \ SBI
>>>     swap $20 - 3 lshift or $9A00 or code , end-code
>>
>> Did you actually test this code? CODE is a parsing word
>> that starts a new dictionary entry. There is currently no
>> way to switch between forth and machine code (that would
>> be ;CODE btw)
>>
>> Puzzled
>> Matthias
>>
>>
>> ---------------------------------------------------------------------- 
>> --------
>> Free Next-Gen Firewall Hardware Offer
>> Buy your Sophos next-gen firewall before the end March 2013
>> and get the hardware for free! Learn more.
>> http://p.sf.net/sfu/sophos-d2d-feb
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013 
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb

Re: [Amforth] Useful?

[Michael K. <mi-...@t-...>]

Hi Matthias.

...
> There is currently no
> way to switch between forth and machine code (that would
> be ;CODE btw)


You may go from low to high level and back:

code <name>
(some code)
; -- jump to high level:
    ldi  XL,low(pfa_forthISR)
    ldi  XH,high(pfa_forthISR)
    jmp  DO_NEXT
pfa_forthISR:
    .dw  XT_MAINWORD
; -- back to low level:
    .dw  PC+1  ; next IP
    .dw  PC+1  ; next cfa
(more code )
end-code

But be shure to save all registers you use if you do so.

---

Enochs code is a macro, assembling one single instruction SBI into  
dictionary and naming it.
Calling that word will execute the SBI instruction.

Michael




Am 14.02.2013 um 20:14 schrieb Matthias Trute:

> hi Enoch,
>
>
>> I'd like to see this forum also offering code snippets, so here's my
>> first humble attempt of harnessing the atomic bit manipulation
>> instructions.
>>
>> : port:hi ( portadr bitno -- )	    \ SBI
>>     swap $20 - 3 lshift or $9A00 or code , end-code
>
> Did you actually test this code? CODE is a parsing word
> that starts a new dictionary entry. There is currently no
> way to switch between forth and machine code (that would
> be ;CODE btw)
>
> Puzzled
> Matthias
>
>
> ---------------------------------------------------------------------- 
> --------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Useful?

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

hi Enoch,


> I'd like to see this forum also offering code snippets, so here's my
> first humble attempt of harnessing the atomic bit manipulation
> instructions.
> 
> : port:hi ( portadr bitno -- )	    \ SBI
>     swap $20 - 3 lshift or $9A00 or code , end-code

Did you actually test this code? CODE is a parsing word
that starts a new dictionary entry. There is currently no
way to switch between forth and machine code (that would
be ;CODE btw)

Puzzled
Matthias

Re: [Amforth] Useful?

[Enoch <ix...@ho...>]

I guess that to make it into Matthias recipe book I have to add input
testing and perhaps more...

: _bitio
    dup $1F U> if &-9 throw then
    over $7 U> if &-9 throw then
;

: port:hi ( portadr bitno -- )	    \ SBI
    swap $20 - _bitio
    3 lshift or $9A00 or
    code , end-code
;

: port:lo ( portadr bitno -- )	    \ CBI
    swap $20 - _bitio
    3 lshift or $9800 or
    code , end-code
;


Enoch <ix...@ho...> writes:

> Hello Matthias and all,
>
> I'd like to see this forum also offering code snippets, so here's my
> first humble attempt of harnessing the atomic bit manipulation
> instructions.
>
> : port:hi ( portadr bitno -- )	    \ SBI
>     swap $20 - 3 lshift or $9A00 or code , end-code
> ;
>
> : port:lo ( portadr bitno -- )	    \ CBI
>     swap $20 - 3 lshift or $9800 or code , end-code
> ; 
>
> example:
>
> PORTB 7 port:hi green.hi
> PORTB 7 port:lo green.lo
>
> Thanks, Enoch.
>
>
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013 
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb

[Amforth] Useful?

[Enoch <ix...@ho...>]

Hello Matthias and all,

I'd like to see this forum also offering code snippets, so here's my
first humble attempt of harnessing the atomic bit manipulation
instructions.

: port:hi ( portadr bitno -- )	    \ SBI
    swap $20 - 3 lshift or $9A00 or code , end-code
;

: port:lo ( portadr bitno -- )	    \ CBI
    swap $20 - 3 lshift or $9800 or code , end-code
; 

example:

PORTB 7 port:hi green.hi
PORTB 7 port:lo green.lo

Thanks, Enoch.

Re: [Amforth] Assembing Ardunio files

[Rafael G. <ast...@ya...>]

OK, I found this is a known issue in the build.xml file

I'm resending my Makefile.  I forgot to include source files dependencies.
Cheers
Rafael




----- Mensaje original -----
De: Rafael Gonzalez <ast...@ya...>
Para: "amf...@li..." <amf...@li...>
CC: 
Enviado: Sábado 9 de febrero de 2013 12:17
Asunto: Assembing Ardunio files

Hi all

I have joined the list for this exciting Forth. 
I'm waiting for my AVR ISP MKII programmer from OLIMEX to arrive and tinker with my brand new Arduino which I have just bought for the purpose.

Since I like to develop in Linux, I have been tinkerting the default template makefile to produce a custom makefile for the Arduinos that you may find useful (attached). It succesfully assembles all files except for the diceimila.

Re: [Amforth] inner interpreter operation.

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

Hi Enoch,

> Which doc output do you consider complete.

I'm still experimenting. The build process has
some quirks as well. In the meantime, just
enjoy the results on the webpage (some things
do not work locally)..

Matthias

Re: [Amforth] inner interpreter operation.

[Enoch <ix...@ho...>]

Helo Matthias,

Which doc output do you consider complete. The two most popular ones
fail:

make html
~~~~~~~~~

Theme error:
no theme named 'amforth' found (missing theme.conf?)

make latexpdf
~~~~~~~~~~~~~

l.1026 \includegraphics{flash-structure.*}

Regards, Enoch.

P/S above refers to r1355


Matthias Trute <mt...@we...> writes:

> Hi Wis,
>
>> I've been doing hardware and I'm finishing an ATXMEGAxx4U board 
>
> Keep in mind that the atXmegas are different from the atmegas
> (without X). amforth currently cannot write to flash, so all
> stuff that requires it does not work (e.g. the compiler). A
> simple text interpreter works (somehow)
>
>> so
>> I'm getting back into the software.  Since I'll need a couple of
>> assembly language Forth words for external I/O, I'm looking into the
>> Forth guts to see how to do it.
>
> You may study the drivers/1wire.asm file. It is a good example. Small
> but does useful things. Most of the code is in forth, not assembly.
> As it should be.
>
>> 
>> For background, I'll be looking harder at the DOES> word - I'm glad
>> to see that it isn't the easiest to learn. I've been studying it;
>> perhaps now it will click with the info you and Michael shared.
>
> I've created the section for does>, and it got significantly
> shorter than I announced ;) But it is still not trivial. Let
> me know, what you miss.
>
>> 
>> BTW: the link to the "Mailing List Archive" in the FAQ
>> (http://amforth.sourceforge.net/faq.html) Gives "ERROR Forum not
>> found".  Also, is the mailing list closed? I don't see how to join
>> it.
>
> Fixed. Thanks for telling
>
> Matthias
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013 
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb

Re: [Amforth] inner interpreter operation.

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

Hi Wis,

> I've been doing hardware and I'm finishing an ATXMEGAxx4U board 

Keep in mind that the atXmegas are different from the atmegas
(without X). amforth currently cannot write to flash, so all
stuff that requires it does not work (e.g. the compiler). A
simple text interpreter works (somehow)

> so
> I'm getting back into the software.  Since I'll need a couple of
> assembly language Forth words for external I/O, I'm looking into the
> Forth guts to see how to do it.

You may study the drivers/1wire.asm file. It is a good example. Small
but does useful things. Most of the code is in forth, not assembly.
As it should be.

> 
> For background, I'll be looking harder at the DOES> word - I'm glad
> to see that it isn't the easiest to learn. I've been studying it;
> perhaps now it will click with the info you and Michael shared.

I've created the section for does>, and it got significantly
shorter than I announced ;) But it is still not trivial. Let
me know, what you miss.

> 
> BTW: the link to the "Mailing List Archive" in the FAQ
> (http://amforth.sourceforge.net/faq.html) Gives "ERROR Forum not
> found".  Also, is the mailing list closed? I don't see how to join
> it.

Fixed. Thanks for telling

Matthias

[Amforth] (no subject)

[D W. <dou...@ya...>]

   http://www.colegiosanvicente.cl/npjnt/bke68nqzyxtom54h3gmi2983nzur?zhniwhzyr98l5so4lp2hn37140fjz9yrg   












   D WilliamsTIME%   
http://mail.yahoo.com
   %.p0an9yd07j3w2vzpa7mvcaqk8sw8t8nc643

Re: [Amforth] inner interpreter operation.

[Macomson, W. <wis...@in...>]

Matthias,

Thank you for taking time to respond. It is an unexpected pleasure. Between you and Michael, I think I understand the inner interpreter well now - I've been looking at the technical document intermittently for a while.

I've been doing hardware and I'm finishing an ATXMEGAxx4U board so I'm getting back into the software.  Since I'll need a couple of assembly language Forth words for external I/O, I'm looking into the Forth guts to see how to do it.

For background, I'll be looking harder at the DOES> word - I'm glad to see that it isn't the easiest to learn. I've been studying it; perhaps now it will click with the info you and Michael shared.

BTW: the link to the "Mailing List Archive" in the FAQ (http://amforth.sourceforge.net/faq.html)
Gives "ERROR Forum not found".  Also, is the mailing list closed? I don't see how to join it.

Regards,

-wis


-----Original Message-----
From: Matthias Trute [mailto:mt...@we...] 
Sent: Wednesday, February 06, 2013 11:46 AM
To: Everything around amforth
Subject: Re: [Amforth] inner interpreter operation.

Hi Wis,

I've got some time to work on the docs. The webpage got a small update as well. To answer your questions (Michael did answer most of them, but he seemed to be unsure himself ;) I'll try to do it myself.

First you may want to read the
http://www.bradrodriguez.com/papers/moving1.htm page and there the section about the ITC technique.
Esp the picture tells almost everything.

Most of the inner interpreter code is in the file core/amforth-interpreter.asm.

The Forth VM (inner interpreter) consists of a few registers, that do all the work: W, IP, X and stack pointers for data and return stacks. These names are not related to similiar named atmega registers!

> (p. 9)	EXECUTE
> 
> Q: When is EXECUTE, um, executed? I'm not clear on what this is used 
> for.

Execute has two aspects: One is part of the inner interpreter (starting at the DO_EXECUTE label until the ijmp instruction) and the other one is the forth word EXECUTE (in words/execute.asm). The latter simply fetches the Top-Of-Stack element into the W register and calls the former.

The inner interpreter execute reads the content of the address, the W register points to. That number is itself an address, this time of real machine code and the final JMP [X] branches to that code. It is expected that this code sooner or later jumps back to the inner interpreter (to DO_NEXT) _and_ keeping the W and IP registers intact.

> (p. 9)	NEXT [ . . . ] This last step finally jumps to the machine
> code pointed to by the X scratch pad register.

NEXT _is_ the inner interpreter (label DO_NEXT in amforth-interpreter.asm). It reads the flash cell, IP points to, stores that number in W and increases IP by 1 (for the next round).
Finally the above execute is done.

In addition to the generic ITC model, the amforth inner interpreter checks for machine interrupts and handles tham if any occured. This is another story, however.

> 
> Q: To be clear, the machine code jumps to NEXT when it has completed.
> Correct?

Yes. See above. Every assembly word in the words/ directory has the phrase jmp_ DO_NEXT at least once. There is no RET instruction to get back (jmp_ is a macro to optimize between jmp and rjmp, another story).

> 
> (p. 9)	EXIT The code for EXIT (aka UNNEST) is the forth word EXIT in
> the dictionary. It reads the IP from the return stack and jumps to 
> NEXT. The return stack pointer is incremented by 2 (1 flash cell).
> 
> Q: I think EXIT pops the top of the return stack into the IP.  That 
> way, the second step of NEXT gets the correct value. Correct?

Yes. See code in words/exit.asm.

> 
> (p. 9)	DO_DOES This code is the runtime part of the forth word DOES>
> . It pushes the current address of the MCU IP register onto the 
> returnstack and jumps to DO_DOES. DO_DOES gets that address back, 
> saves the current IP and sets the forth IP to the address it got from 
> the stack. Finally it continues with NEXT.
> 
> Q.  Is this effectively a subroutine call?

DOES> is a rather difficult topic. It is easy to use, but
hard to explain and the implementation in amforth is not the most obvious one. DOES> itself is not really a subroutine call its more like a partial redefinition of a colon word, which is a subroutine call. In the docs I've just removed the section for now (it was simply garbage after all). I'll rewrite it from scratch. Expect one page text per assembly code line ;)

I think for the beginning you can savely ignore both does> and interrupts.

HTH
Matthias

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/ Amf...@li...
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] inner interpreter operation.

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

Hi Wis,

I've got some time to work on the docs. The webpage got
a small update as well. To answer your questions (Michael
did answer most of them, but he seemed to be unsure
himself ;) I'll try to do it myself.

First you may want to read the
http://www.bradrodriguez.com/papers/moving1.htm page and there the
section about the ITC technique.
Esp the picture tells almost everything.

Most of the inner interpreter code is in the file
core/amforth-interpreter.asm.

The Forth VM (inner interpreter) consists of a few registers, that
do all the work: W, IP, X and stack pointers for
data and return stacks. These names are not related to similiar
named atmega registers!

> (p. 9)	EXECUTE
> 
> Q: When is EXECUTE, um, executed? I'm not clear on what this is used
> for.

Execute has two aspects: One is part of the inner interpreter (starting
at the DO_EXECUTE label until the ijmp instruction) and the other one
is the forth word EXECUTE (in words/execute.asm). The latter simply
fetches the Top-Of-Stack element into the W register and calls the
former.

The inner interpreter execute reads the content of the address,
the W register points to. That number is itself an address, this
time of real machine code and the final JMP [X] branches to that
code. It is expected that this code sooner or later jumps back
to the inner interpreter (to DO_NEXT) _and_ keeping the W and IP
registers intact.

> (p. 9)	NEXT [ . . . ] This last step finally jumps to the machine
> code pointed to by the X scratch pad register.

NEXT _is_ the inner interpreter (label DO_NEXT in
amforth-interpreter.asm). It reads the flash cell, IP points to,
stores that number in W and increases IP by 1 (for the next round).
Finally the above execute is done.

In addition to the generic ITC model, the amforth inner interpreter
checks for machine interrupts and handles tham if any occured. This
is another story, however.

> 
> Q: To be clear, the machine code jumps to NEXT when it has completed.
> Correct?

Yes. See above. Every assembly word in the words/ directory has
the phrase jmp_ DO_NEXT at least once. There is no RET instruction
to get back (jmp_ is a macro to optimize between jmp and rjmp,
another story).

> 
> (p. 9)	EXIT The code for EXIT (aka UNNEST) is the forth word EXIT in
> the dictionary. It reads the IP from the return stack and jumps to
> NEXT. The return stack pointer is incremented by 2 (1 flash cell).
> 
> Q: I think EXIT pops the top of the return stack into the IP.  That
> way, the second step of NEXT gets the correct value. Correct?

Yes. See code in words/exit.asm.

> 
> (p. 9)	DO_DOES This code is the runtime part of the forth word DOES>
> . It pushes the current address of the MCU IP register onto the
> returnstack and jumps to DO_DOES. DO_DOES gets that address back,
> saves the current IP and sets the forth IP to the address it got from
> the stack. Finally it continues with NEXT.
> 
> Q.  Is this effectively a subroutine call?

DOES> is a rather difficult topic. It is easy to use, but
hard to explain and the implementation in amforth is not
the most obvious one. DOES> itself is not really
a subroutine call its more like a partial redefinition of a
colon word, which is a subroutine call. In the docs I've just removed
the section for now (it was simply garbage after all). I'll rewrite it
from scratch. Expect one page text per assembly code line ;)

I think for the beginning you can savely ignore both does> and
interrupts.

HTH
Matthias

Re: [Amforth] inner interpreter operation.

[Macomson, W. <wis...@in...>]

Thanks, Michael.  This helps a lot.

Also thank Matthias for me when you get a chance. I don't want to clog up his email any further.

Regards,

-wis

-----Original Message-----
From: Michael Kalus [mailto:mi-...@t-...] 
Sent: Saturday, February 02, 2013 2:54 AM
To: Everything around amforth
Subject: Re: [Amforth] inner interpreter operation.

Hi Wis.

Since Matthias is bussy, maybe I can help out.

Am 31.01.2013 um 21:37 schrieb Macomson, Wis:

> I'm new to this and I'm trying to understand the amForth inner 
> interpreter. There are a couple of clarifications in the "amforth 
> Documentation, Release 5.1-wip,January 26, 2013" that would help a 
> lot.
>
> To wit:
>
> (p. 9)	EXECUTE
>
> Q: When is EXECUTE, um, executed? I'm not clear on what this is used 
> for.

( xt -- ) EXECUTE

If you put an execution token xt on the stack, you may EXECUTE that.

It is used in the interpreter: Parse input stream for a forth word (word means "string of ascii characters delimited by blanks", find that word in dictionary, get its xt on stack and then execute it.

Investigate ACCEPT and INTERPRET in the source code.



> (p. 9)	NEXT
> [ . . . ]
> This last step finally jumps to the machine code pointed to by the X 
> scratch pad register.
>
> Q: To be clear, the machine code jumps to NEXT when it has completed.  
> Correct?

That is correct.

'Low level' forth machine code continues execution of forth on 'high level' that way.



> (p. 9)	EXIT
> The code for EXIT (aka UNNEST) is the forth word EXIT in the 
> dictionary. It reads the IP from the return stack and jumps to NEXT. 
> The return stack pointer is incremented by 2 (1 flash cell).
>
> Q: I think EXIT pops the top of the return stack into the IP.  That 
> way, the second step of NEXT gets the correct value. Correct?

So it is.

If stack grows 'down' an increment by 2 drops one item - on a 8Bit machine with a 16Bit virtual forth machine on it.


>
> (p. 9)	DO_DOES
> This code is the runtime part of the forth word DOES> . It pushes the 
> current address of the MCU IP register onto the returnstack and jumps 
> to DO_DOES. DO_DOES gets that address back, saves the current IP and 
> sets the forth IP to the address it got from the stack.
> Finally it continues with NEXT.
>
> Q.  Is this effectively a subroutine call?

Yes. (I think so.)

It is used to define words, that create words of the same class.

For exeample VARIABLE is such a word. You may create variables that all work the same.

VARIABLE Y0
VARIABLE X12
VARIABLE MOON

Such words are also called "defining words".

VARIABLE defines a new forth word, that has one cell of ram to hold an item. When this word is executed, it puts the address of its ram cell on stack - that is the 'subroutine' part of it.

Michael

>
> Thanks for any light you can shed.
>
> ----------------------------------------------------------------------
> --------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics Download AppDynamics Lite 
> for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/ 
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/ Amf...@li...
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] inner interpreter operation.

[Michael K. <mi-...@t-...>]

Hi Wis.

Since Matthias is bussy, maybe I can help out.

Am 31.01.2013 um 21:37 schrieb Macomson, Wis:

> I'm new to this and I'm trying to understand the amForth inner  
> interpreter. There are a couple of clarifications in the "amforth  
> Documentation, Release 5.1-wip,January 26, 2013" that would help a  
> lot.
>
> To wit:
>
> (p. 9)	EXECUTE
>
> Q: When is EXECUTE, um, executed? I'm not clear on what this is  
> used for.

( xt -- ) EXECUTE

If you put an execution token xt on the stack, you may EXECUTE that.

It is used in the interpreter: Parse input stream for a forth word  
(word means "string of ascii characters delimited by blanks", find  
that word in dictionary, get its xt on stack and then execute it.

Investigate ACCEPT and INTERPRET in the source code.



> (p. 9)	NEXT
> [ . . . ]
> This last step finally jumps to the machine code pointed to by the  
> X scratch pad register.
>
> Q: To be clear, the machine code jumps to NEXT when it has  
> completed.  Correct?

That is correct.

'Low level' forth machine code continues execution of forth on 'high  
level' that way.



> (p. 9)	EXIT
> The code for EXIT (aka UNNEST) is the forth word EXIT in the  
> dictionary. It reads the IP from the return stack and jumps to  
> NEXT. The return stack pointer is incremented by 2 (1 flash cell).
>
> Q: I think EXIT pops the top of the return stack into the IP.  That  
> way, the second step of NEXT gets the correct value. Correct?

So it is.

If stack grows 'down' an increment by 2 drops one item - on a 8Bit  
machine with a 16Bit virtual forth machine on it.


>
> (p. 9)	DO_DOES
> This code is the runtime part of the forth word DOES> . It pushes  
> the current address of the MCU IP register onto the returnstack and  
> jumps to DO_DOES. DO_DOES gets that address back, saves the current  
> IP and sets the forth IP to the address it got from the stack.  
> Finally it continues with NEXT.
>
> Q.  Is this effectively a subroutine call?

Yes. (I think so.)

It is used to define words, that create words of the same class.

For exeample VARIABLE is such a word. You may create variables that  
all work the same.

VARIABLE Y0
VARIABLE X12
VARIABLE MOON

Such words are also called "defining words".

VARIABLE defines a new forth word, that has one cell of ram to hold  
an item. When this word is executed, it puts the address of its ram  
cell on stack - that is the 'subroutine' part of it.

Michael

>
> Thanks for any light you can shed.
>
> ---------------------------------------------------------------------- 
> --------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] inner interpreter operation.

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

Hi Wis,

> I'm new to this and I'm trying to understand the amForth inner
> interpreter. There are a couple of clarifications in the "amforth
> Documentation, Release 5.1-wip,January 26, 2013" that would help a
> lot.

Unfortunately I'm currently busy with other things, so please
dont hold your breath for answers. I'll come back to your questions
later. Sorry

Matthias

[Amforth] inner interpreter operation.

[Macomson, W. <wis...@in...>]

I'm new to this and I'm trying to understand the amForth inner interpreter. There are a couple of clarifications in the "amforth Documentation, Release 5.1-wip,January 26, 2013" that would help a lot.

To wit:

(p. 9)	EXECUTE

Q: When is EXECUTE, um, executed? I'm not clear on what this is used for.

(p. 9)	NEXT
[ . . . ]
This last step finally jumps to the machine code pointed to by the X scratch pad register.

Q: To be clear, the machine code jumps to NEXT when it has completed.  Correct?

(p. 9)	EXIT
The code for EXIT (aka UNNEST) is the forth word EXIT in the dictionary. It reads the IP from the return stack and jumps to NEXT. The return stack pointer is incremented by 2 (1 flash cell).

Q: I think EXIT pops the top of the return stack into the IP.  That way, the second step of NEXT gets the correct value. Correct?

(p. 9)	DO_DOES
This code is the runtime part of the forth word DOES> . It pushes the current address of the MCU IP register onto the returnstack and jumps to DO_DOES. DO_DOES gets that address back, saves the current IP and sets the forth IP to the address it got from the stack. Finally it continues with NEXT.

Q.  Is this effectively a subroutine call?

Thanks for any light you can shed.