oh, and another one. i found out that what i'm suggesting with forth and microcontrollers actually has a name: 'a tethered forth'
http://www.ultratechnology.com/4thlego.htm
this site is a great information resource for forth.
i can really recommend the following streaming videos, especially those featuring Charles Moore himself explaining his idea of forth, and the road to ColorForth.
http://www.ultratechnology.com/rmvideo.htm
some (most) of these are transcribed to html pages on the same site.
i just stumbled on the (or part of) the solution for the pic bootstrap interpreter here:
http://pygmy.otuh.org/3ins4th.html
in fact this illustrates that the idea is not exactly new.
On Thu, Sep 09, 2004 at 08:54:25AM +0200, Tom Schouten wrote:
i just stumbled on the (or part of) the solution for the pic bootstrap interpreter here:
in fact this illustrates that the idea is not exactly new.
sorry, url was this: http://pygmy.utoh.org/3ins4th.html
also check this: http://www.forthfreak.net/wiki/index.cgi?ForthScripts
btw, pygmy forth itself (for DOS and also some ARM dev board) is a nice example of a self-contained forth written in forth with a built in block editor.
i'm not a big fan of block editors, except for the one in ColorForth, but it's a nice piece of forth history.
cheers tom
I'm not sure the PIC is the best choice here, because it has separate data and program memory: you can't execute code that resides in RAM. The only way it will work is as a byte-by byte interpreter I'm starting to think the ST7 would be better here: http://www.st.com/stonline/products/support/micro/st7/st7lite.htm It has a very similar architecture and instruction set to the 65XX series, it's even cheaper than most PICs. I'm only starting to read the docs but it seems that you could download small blocks of code and have them execute in RAM using a bootstrap loader (at least I haven't found where it says that you can't do so). Using a PIC you would need to preprogram all possible routines and use selector bytes to call them as needed, as in a BASIC interpreter. Martin
Tom Schouten wrote:
On Thu, Sep 09, 2004 at 08:54:25AM +0200, Tom Schouten wrote:
i just stumbled on the (or part of) the solution for the pic bootstrap interpreter here:
in fact this illustrates that the idea is not exactly new.
sorry, url was this: http://pygmy.utoh.org/3ins4th.html
also check this: http://www.forthfreak.net/wiki/index.cgi?ForthScripts
btw, pygmy forth itself (for DOS and also some ARM dev board) is a nice example of a self-contained forth written in forth with a built in block editor.
i'm not a big fan of block editors, except for the one in ColorForth, but it's a nice piece of forth history.
cheers tom
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Fri, Sep 10, 2004 at 01:32:22PM -0400, Martin Peach wrote:
I'm not sure the PIC is the best choice here, because it has separate data and program memory: you can't execute code that resides in RAM.
yes. it's a strange chip. but you can execute threaded forth from ram as long as you have some 'JMP <REG>' instruction. the 18f has a self-programmable eeprom, so blocks of native code can be uploaded.
The only way it will work is as a byte-by byte interpreter I'm starting to think the ST7 would be better here: http://www.st.com/stonline/products/support/micro/st7/st7lite.htm It has a very similar architecture and instruction set to the 65XX series, it's even cheaper than most PICs. I'm only starting to read the docs but it seems that you could download small blocks of code and have them execute in RAM using a bootstrap loader (at least I haven't found where it says that you can't do so). Using a PIC you would need to preprogram all possible routines and use selector bytes to call them as needed, as in a BASIC interpreter.
that's a bit the thing i am trying to avoid by writing this distributed (tethered) forth. as you can read in the link about the 3-instruction forth, this can be taken to the very extreme (a fort of 66 bytes). this enables you to get it to work slow first and gradually upload more target code to speed it up. because forth code is just a list of addresses, it can be stored in ram temporarily before being transferred to eeprom, or compiled to native code.
the st looks nice. but a lot smaller than the 18f.
do you know if it has an auto-increment/decrement addressing mode? that's the nice thing about the pic, it doesn't have this in the instruction set, but faked somewhere else. it makes the forth faster. (stacks & threaded interpreter).
-
Martin Peach -
Tom Schouten