Looks like I'll be writing a Forth compiler. First pass is exploratory: what will it take to get custom word definitions added in? What is the bare minimum needed to be useful? What's a good mechanism for describing I/O registers? Once this base is in place, I'll start aggressively optimising for embedded use. My hope is to get this trimmed down and low enough on resource usage to be a useful command shell.

What will be useful here is modularity; in the current incarnation, the project is structured like

.
├── forth.c        ; forth interpreter
├── forth.h        ; interpreter API definitions
├── main.c         ; AVR main skeleton
├── stack.c        ; implementation of the stack
├── stack.h        ; stack API definitions
├── util.c         ; I/O utilities
└── util.h         ; I/O API definitions

In the kforth project, I anticipate being able to modularise as many of the components as possible. Maybe having something along the lines of

.
├── dict.c         ; dictionary implementation (for words)
├── dict.h         ; dictionary API definitions
├── forth.c        ; forth interpreter
├── forth.h        ; interpreter API definitions
├── main.c         ; test harness for interpreter
├── stack.c        ; stack implementation
├── stack.h        ; stack API definitions
├── util.c         ; I/O and common code
├── util.h         ; I/O and common API definitions
├── word.c         ; word implementation
└── word.h         ; word API definitions

When porting code over, it'll be easier to swap out the util.[ch] to change IO, and maybe update the forth.[ch] to adjust for changes in ISA. That way, most of the source files can be dropped in place into a new project, and the relevant source files modified as needed.

kforth will have to be written in C and/or assembly to make it viable for use on an embedded platform; it could be C++ so long as it was sane C++ (in essence, C with classes).

The end goal is to derive a Forth command shell that I can use on the AVR and ARM platforms.