Thanks. Perhaps it would be useful to let people know where I'm at with the Forth effort.

Right now the progress is hard to see - to date there isn't anything that is directly runnable on real hardware on an emulator. However I have quite a large part of the system implemented - including 34 of the 168 words in the core and core ext. lists, and many building blocks to support them (e.g branching). Many of these are themselves implemented in Forth as I have a sort of cross-compiler working. This has accelerated things very substantially!

My next step will be to get input and output working, by providing a means of wrapping the SYS functions built in to the Gigatron ROM as Forth words. Part of this is having a means of entering and re-entering Forth from vCPU, while making sure that all of the timings line up correctly.

I also need a means for loading an initial dictionary into RAM on start up, and words for working with the dictionary, and there are a few other things that I don't yet have a ROM-based encoding for yet like variables and strings.

Once I have these things, I should be close to having a working system. I intend to try to use this Forth 2012 test suite to guide me through bringing up the system.

In terms of SPI and SD card development, these things "should" be "just" a matter of programming at that point - the SYS functions are currently used from vCPU can be exposed to Forth, and the block and file word lists built on top of that.

I've been taking a little break from development for a few weeks, but I expect to get back into it soon. If anyone is interested in helping out, I'd be happy to provide some guidance - there's still some words that can be trivially implemented in Forth right now, and many more that will become unlocked once a bit more work is done.

The Forth kernel is first dis-aggregated into two separate processes that can then be reconnected

The first is "preForth" that was mentioned by ECL above. This contains just 13 primitives which allows the virtual machine to be constructed using only the datastack and the return stack structures.

There is no random memory access at this stage (it is added later) - everything is processed on the stacks.

preForth does not permit the use of immediate words - so it relies on Forth source code that has already been compiled into a sequence of 16-bit addresses. (Or I suppose you could enter manually the address of the routine you wanted to execute - a bit like a monitor program) There is no interpreted mode or the need for a dictionary search or dictionary structure - at this low level - this is also added later.

preForth is a minimalistic non-interactive Forth kernel that can bootstrap itself and
can be used as an easy-to-port basis for a full Forth implementation.
preForth feels like Forth - it is mainly a sublanguage of ANS-Forth - but is
significantly reduced in its capabilities.
Features:
minimal control structures, no immediate words, strings on stack, few primitives
just
• stack
• return stack
• only ?EXIT and recursion as control structures
• colon definitions
• optional tail call optimization
• IO via KEY/EMIT
• signed single cell decimal numbers (0-9)+
• character constants via ’c’-notation
• output single cell decimal numbers
and
• no immediate words, i.e.
• no control structures IF ELSE THEN BEGIN WHILE REPEAT UNTIL
• no defining words
• no DOES>
• no memory @ ! CMOVE ALLOT ,
• no pictured numeric output
• no input stream
• no state
• no base
• no dictionary, no EXECUTE, not EVALUATE
• no CATCH and THROW
• no error handling
preForth is based on just 13 primitives: emit key dup swap drop 0< ?exit >r r> - nest
unnest lit which are defined in the host language.

simpleForth is an extension to preForth built using preForth. It is still
non-interactive but adds
• control structures IF ELSE THEN BEGIN WHILE REPEAT UNTIL
• definitions with and without headers in generated code
• memory: @ ! c@ c! allot c, ,
• variable, constants
• [’] execute
• immediate definitions
Enough convenient words to formulate an interactive Forth

As with any Forth implementation it is important to get the inner loop (usually called NEXT) of the VM to execute as efficiently as possible - as this is where Forth gains or loses its speed advantage.

The inner loop picks up the 16-bit start address of the word (function) to be executed and then jumps to that address. At the end of the function, there is a jump back to the start of NEXT.

Sometimes Forth will make use of 8-bit tokens to identify its words, but this introduces an extra stage of look-up to get the code field address.