In my last post I talk about writing my new language fil in uForth via 3 stage metacompilation.
I want to note here that there is an alternate approach I am considering: Tethering.
I don't need to metacompile fil in order to get it running on a small MCU. If I retain the C code that does interpreting/compiling (bootstrap.exe) and write a new stripped down VM that doesn't understand interpreting/compiling (fil.exe), I only have to port the stripped down VM to the MCU. I would do all of my development/compiling on the PC (with bootstrap.exe -- renamed pc-fil.exe). The resulting byte code image (from compilation) would be moved to the MCU and run by the ported fil.exe.
This approach is a subset of what uForth already does. However, uForth also allows for the C based interpreter/compiler to run on the MCU. This is a bit weighty, but essentially gives me the ability to interactively develop directly on the MCU (interacting through a serial interface).
A better approach is tethering, and fil will prefer this approach even if I do re-implement the interpreter/compiler in uForth. In tethering, you do your development on the PC (using fil.exe/bootstrap.exe) and craft a MCU VM that listens on a serial port for special "commands". These commands can be as simple as "store byte-code" and "execute byte-code". You maintain a mirror of the dictionary between the PC and MCU. All the MCU VM needs to do (from an interaction perspective) is write PC compiled byte-code to its dictionary and to be able to execute it. No interpreter is needed.
This is the brilliant method used by various Forths including MyForth, and Riscy Pygness.
If I run into too many walls doing my 3 stages, I may take a break and just go tethered. I do have MCU CFT projects I want to get done!