In many cases, native Forth environments compile to RAM, and the original STM8S eForth is no exception. In theory it's easy: just write the code into Non Volatile Memory (NVRAM, Flash) instead of RAM, but in practice many µCs either don't have that, or they can't write to the Flash memory area from which code is executed.

Here, the STM8S architecture has an advantage: writing to Flash is very easy. After unlocking the memory areas writing to it with simple LD or LDW instruction just works (the memory write control automatically adds wait-states).

The problem that remains to be solved is that Forth uses two RAM areas just behind the user defined words as temporary storage (the interpreter uses some bytes for looking up words, and the so called PAD area for building output strings). In eForth, compiling words to other memory areas (e.g. NVM) also moves the temporary storage. The idea of writing temporary data to Flash just doesn't sound right, even if it works.

The second problem is concatanating the core dictionary with user defined dictionaries in RAM and NVM. Some design decisions have to be made, e.g. should extending the NVM dictionary be possible, or is re-writing from scratch sufficient?

I now have a nice solution for the first problem, but I'm not satisfied with what I have for the second problem. Stay tuned.

EDIT: Code execution from EEPROM leads to hardware reset. An earlier version of this log wrongly assumed that RAM and EEPROM have the same execution properties!