This is a port of badnop (a minimal proof of concept forth compiler for picmicro 18f452) to mole.
The eventual goal is to use mole as the hub for pd<->PIC communication: to have a toolchain that
can program a microcontroller from within pd, in a real-time interactive fashon.

Currently the target architecture is fixed. Later, when everything is working, this could be
made more general. Porting to another architecture boils down to adding/modifying some forth
compiler macros (code generators).


A Forth is ideal to use on a microcontroller for 2 reasons:
* it can be made very small and reasonably fast, which effectively enables it to run in a real
  time environment.
* the structure of forth is at the same time simple enough to write a small compiler (as long as
  the chip's architecture is simple enough) and flexible enough to support most contemporary
  programming paradigms (imperative, functional and object oriented programming)


The design goal (pd <-> PIC) can be split up into 2 parts.
* pd <-> mole communication
* mole <-> PIC communication

Mole is integrated with pd, so the only real problem is to connect mole to the PIC.

To keep the complexity of the target chip's forth interpreter minimal, and the memory
usage low, the symbol part of the forth dictionary is kept off-chip (inside mole). 
Currently, the target compiler compiles to native code (subroutine threaded): there is 
no inner interpreter (next routine) running on the PIC.

So, the flow of control becomes something like:

* send a list of symbolic code to the compiler (running in mole). this will generate
  some native PIC code in a temporary memory buffer in the compiler (this buffer
  is a mirror of the PIC's memory buffer). this works like an ordinary forth: newly
  compiled code is appended to the list, maybe block aligned (because the PIC's flash 
  write is block based). this step can be repeated, i.e. a chunk of code can be loaded
  and compiled to binary PIC code inside the target buffer in the compiler.

* whenever a block of code is done, a message can be send to the PIC to transfer the
  block of code to the PIC's memory space.

* the rest of the protocol is just:
  mole sends data atoms (literals) or function addresses (xt's) to a minimal interpreter
  running on the PIC. this interpreter decodes the message (literals are loaded on the
  stack, xt's are executed). the executed xt might send a message back to notify the
  controller some event has happened. also, messages can be originated from the irq
  handlers running on the PIC.


That's about it.

TODO:
* port the compiler from badnop to mole (see macro.mole and compiler.mole)
* write the small interpreter + support code running on the PIC

When the basic chain is working, the code library (host and target forth code)
can be built incrementally.



Todo details:
* convert the macro hack in badnop to something simpler. maybe an extra compilation
mode that will compile to target instead of host dictionary.