[PicForth] pre-announcing Forth for PIC18F chips

David P Harris dpharris at telus.net
Sun Jan 16 19:35:06 CET 2005


David-
This sounds excellent!  Sign me up! 
PIC18Forth is descriptive if mundane. 
The extensibility sounds very good. 
I don't know Python, but know enough languages that it shouldn't be too 
big a hurdle. 
Good work....
David

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



More information about the PicForth mailing list