PURRR: DTC on native
--------------------

This document describes the direct threaded forth on top of an 8 bit
native forth, aka. PURRR. It serves as a 

for more info see the source in pic18/direct.f and brood/direct.ss


INTRODUCTION
------------

I set out to write a FORTH for the PIC18 architecture. Instead of
following the more traditional path, I split the problem into two parts:

PURRR18	  a target-specific 8 bit forth which compiles to native code
PURRR     a more traditional 16 bit forth with virtual machine

The bottom layer (PURRR18) aims to be fast and small, giving up on the
standard approach and compromising simplicity. The idea is that it
should be nearly as fast as hand written assembler code. It takes the
form of a forth-style macro assembler with partial evaluation.

The top layer (PURRR) aims to be a central, portable layer, which runs
on multiple architectures, and which is more compliant to the forth
standard, whenever it makes sense. (i.e. it does not abstract away the
fact that it's running from flash instead of ram memory).


VIRTUAL MACHINE
---------------

The VM has the following design elements:

- Explicit interpreter loop

- a PRIMITIVE instruction is
  [ EXIT(1) | LITERAL(1) | ADDRESS(14)

- a PROGRAM is the address of an array of primitive instructions

- effective word size is 14 bit for code addresses and data


This gives the following desirable properties:

- native code, ending in 'return' can be used as primitives. this
  allows for better coupling between PURRR and PURRR18.

- an EXIT and LITERAL bit. as a result, all VM instructions are one
  word exactly (there are no exceptions), and the VM can support
  proper tail calls. 




Downsides:

- literals > 14 bit can be implemented using 2 literals followed by a
  combination word. this is inefficient, but the simplicity of the VM
  is probably worth the hassle.

- only 32k addressable code space.

- primitive and native don't use the same return stack.