[PD] Re: [PD-dev] small gizmos

[Tom Schouten]

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).