I wouldn't consider Forth a blessing for embedded programming but, then, opinions vary. I'm not sure how to write an RTOS is Forth. Heck, I'm not even sure how to write an interrupt handler.
Times have changed. Forth offered the possibility of running the whole development system in an 8 bit processor with some KB of RAM. Other approaches demanded a separate compiler and debugger, an ICE, etc.
But still Forth has some advantages of its own depending on what you want to do. You program by extending the language instead of just writing functions. Many years ago I saw an awesome example on an issue of Dr Dobbs Journal. By extending the language it was possible for a non-programming engineer to write a program to operate some machinery.
http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/DDJ/1989/8902/8902e/8902e.htmRegarding the RTOS, it was quite easy to write a multitasking kernel in Forth. I wrote one for the HD6303 back in 1991. Again, it worked by extending the language, and I added a new type of function definition: a task.
A task had an "initialization section" and a "task body". When the whole thing was compiled, everything was stored in memory so that it would be copied to an EPROM.
During the boot process, the kernel created the process control blocks in RAM, and executed the "initialization section" of each of the processes, giving control to the "task body" which would be the main program for each task. It was a simple round robin approach, but I could have added priorities and real time constraints.
The Forth system I used, which was a version of fig-Forth running on a TDS9092 board, included support to write interrupt routines in Forth. But of course in a 8 bit processor at 1 MHz it was better to write the interrupt handlers in assembly. I actually wrote small assembly language routines to catch interrupts that needed a timely service, and those handlers registered the event description together with a timestamp in an event queue, to be serviced by the higher level code with lesser time constraints.
Nowadays you could do some of that work in Python running on a Raspberry Pi, with the same advantage of interactive debugging and testing, but back in 1990 that was unthinkable!
And, unlike my friends at the university writing a multitasking kernel for an Intel 8031 in the classical way (assembly), I did not use an in circuit emulator. Just a serial terminal and a bunch of hex dumps after executing code blocks from the command line.
do like about it is the ability to build programs from the bottom up. I think that's about the only way they can be built.
MANY years ago ('80), I was visiting a disk drive manufacturer. They did all their testing in Forth because they could simply add a new test to lower level code already known to work. Literally, it was as simple as typing a single command string to create an entirely new test pattern.
Was it Maxtor? I think I saw them mentioned in a magazine.