This web-page documents the PForth compiler, which is an ANSI-Forth compiler for the PIC24.
Contact the author at: Hugo Aguilar (click for email)
The PForth compiler is being written in MPASM. It will be a resident compiler, meaning that the compiler and the application share space on the PIC24. The symbol-table (dictionary) however, will be held on the desktop computer. There is a front-end program (called PFide) running on the desktop computer. PFide includes a text-editor for working on the source-code. There is also a command-line window. We have message passing between PForth and PFide. When the user is in the command-line window, he will be able to execute functions on the PIC24 giving them various input parameters in the standard Forth interactive debugging style. It will appear to him as if the PIC24 were a desktop computer complete with keyboard, screen, hard-disk, etc.. In actuality, of course, the PIC24 doesn't have any of these resources itself and PFide is providing them. When compiling a program, PForth will send a message to PFide asking it to look a word up in the dictionary. PFide will do this and send a message back containing the pertinent information (cfa, etc.). Also, PForth will send a message to PFide asking it to provide another 1024-byte block of source-code and PFide will send a message back doing this. In this way, PForth can compile a program despite the limited RAM available on the PIC24
PForth will compile PIC24 machine-code. Functions are called with the CALL instruction. We have registers, TOS, SOS and ROS, that contain the top three values of the stack. Nominally, TOS contains data, but the rest of the stack is in memory, and SOS and ROS are undefined. Each smidgen of code will start with POP instructions to load SOS and ROS as needed. Also, each smidgen of code will end with PUSH instructions of SOS and ROS as needed to return the system to the nominal state (only TOS in register). The PUSH instructions at the end of the previous smidgen of code will be adjacent to the POP instructions at the start of the following smidgen of code. The PUSH and POP instructions can be cancelled out by peephole optimization. The result is that we can generally keep most of our data in registers rather than memory, although the nominal configuration is to have only the TOS loaded. There will be other optimizations done as well, including jump-termination. PForth is oriented toward high execution speed.
If anybody wants to get involved, please contact the author. Primarily I need help on PFide. I don't really have much experience with desktop software, especially GUI software. I want PFide to run on Linux primarily, but also possibly Windows. I may need some help with the PIC24 communications software too. Later on, there will also be work writing various aspects of PForth. Right now however, PFide is what I primarily need help on.