[PicForth] pre-announcing Forth for PIC18F chips

[J.C. Wren]

    Are the von Neuman memory map limits fixed?  The PIC18F8621, for 
example, has 3K of RAM, and 64K of FLASH.  I'd like to be able to use 
all the RAM, and 61K of the FLASH.

    The '8621 also has a 31 entry hardware stack, with stack underflow 
and overflow detection.  If it's not too unreasonable, it might be nice 
to be able to use that instead of a software stack.  For large programs, 
it's obviously inadequate, but for a lot of projects it's more than enough.

    --jc

David McNab wrote:

> Hi gnupic and picforth people,
>
> This is a pre-announcement of a coming Forth compiler for the 
> PIC18Fxxx chips. I've tentatively called it 'PIC18forth', but am open 
> to suggestions for a better name.
>
> PIC18forth is radically different from the PIC16Fxxx-only PicForth 
> compiler. Almost nothing in common, since I've written PIC18forth from 
> scratch.
>
> Quick summary of features - love them and loathe them:
>
>  * signed/unsigned 16-bit data cells and operators
>  * software return stack
>  * data stack grows up (increasing addresses), while
>    return stack grows down (decreasing addresses)
>  * total allocated size of data+return stacks can
>    be set to anything between 16 and 1024 bytes
>  * compiler is written in Python, and is very approachable
>    and extensible, even for people new to the code
>  * integrated into gputils
>  * forth sources get compiled to relocatable assembly (.asm)
>    sources, ready for gpasm and gplink
>  * the generated code embeds a 16-bit forth vm (token threaded
>    execution model) which executes bytecodes
>  * the generated code is self-contained, and once assembled
>    and linked, can be downloaded/flashed as a standalone program
>  * FSR0 is usually used for data stack ptr, FSR1 usually
>    used as return stack ptr, FSR2 used as general purpose
>    pointer
>  * full support for locals (John Hopkins syntax, data
>    gets transferred from data stack to a frame on return stack
>  * vm design favours code density over execution speed
>  * contents of 'code .. end-code' definitions are included
>    verbatim in generated assembly source (with '\' comments
>    changed to ';')
>  * the defining-words 'primitive .. end-primitive' can be
>    used in place of 'code .. end-code', to define a word
>    in assembler which will be available as a single-byte
>    vm instruction - easy to add/remove primitives at will
>  * maps to von Neumann memory model, with addresses <8000H
>    treated as RAM addresses, and addresses>=8000H treated
>    as program ROM addresses
>
> If you're currently hacking with PIC18Fxxx chips, and are interested 
> in trying out PIC18forth, please mail me and I'll put you on a list 
> for pre-alpha-testers.
>