The HaD effect: people come with use-cases ans ideas, a creative exchange starts, and innovation takes place. In this project, this happened a lot.

Recently @Richard needed a feature that I thought not to be possible with a µC as limited as a Low Density STM8S: the Forth interpreter should be running concurrent to the console!

It turned to be that complicated: now an idle task, similar to the background task (but only running while the console is idle) provides some kind of non-preemptive multitasking with a limited context switch (i.e. the interpreter state is preserved).

Consider the following example:

#require EVALUATE

: test $" 2 7 +" COUNT ;
test EVALUATE . 9 ok

EVALUATE relies on minuscule change in the STM8 eForth core: the address of the Terminal Input Buffer (TIB) is now a pointer, 12 bytes more code. The rest of the feature is optional Forth code.

IDLE was even more simple: only 5 bytes more assembly were needed in KEY to make it work.

Consider the following code running on STM8eForth 2.2.22:

#require 'IDLE
VARIABLE TALLY
: t TALLY @ 1+ DUP TALLY ! $F000 AND 0= OUT! ;
' t 'IDLE !

This flashes about 34 times per minute (unless the console has something better to do). One IDLE loop thus takes about 34s/(60*65536) = 8.65µs.

I think that the 17 bytes in the core were well spent.