In a nearby thread about the minimal facilities needed in a machine monitor to support bootstrapping:



I, too, was reminded of the transputer. I'm not quite sure what it is about Frank Sargeant's 66-byte monitor which makes it a Forth. But I did wonder, why all three instructions? A poke would be enough to extend the language, so peek isn't needed. And a five-byte-poke-executed-as-code would be a sufficiently useful primitive to do both the loading of bytes and the calling of subroutines - that's just one instruction, which we might call DOTHIS or RUNIT (it places five bytes somewhere, followed by an RTS, and then does a JSR. Or it could even place the bytes inline and just run into them. I think five bytes is enough to allow for write-this-here primitive which can then build up any other program. Perhaps fewer would also be possible.)

But then, is a bootstrap already a single-instruction monitor, or is it even a zero-instruction monitor?

(I linked to some previous and related threads a little further on.)

At a quick glance, nothing makes this a Forth. Stand alone, it's not a Forth. In fact, it's not anything beyond simple remote services.

What it does do, however, is let you extend your CURRENT Forth to where you're very quickly using your first class Forth concepts that are native in your Forth, but leveraging the embedded system.

The simple example I mentioned of extending an assembler.

A Forth assembler is basically just this ][ much above "poking" values in to RAM. Changing just a few words turns a Forth assembler in to a cross assembler storing values in to the embedded system. If you leverage the DEFER capability in Forth (which lets you change the implementation of a word, without changing its name), then you don't have to change the assembler at all.

Franks example of driving I/O (blinking LEDs) is particularly apropos because with this 3 instruction driver, you can easily use high level Forth to play with the I/O capabilities of your embedded system. (Obviously, if your system didn't support memory mapped I/O, you'd need X-IN and X-OUT to drive the CPUs I/O ports). For example, on my Forth, on my simulator, the I/O is in high level Forth (since it's just reading and writing memory, heck Forth can do that).

What this driver does is essentially extend your current Forth to work on the embedded machine, without having to port a Forth to it straight away.

Consider the thread about writing a loader in less than 256 bytes. Well, here ya go. Now you can create an checksum enabled, high level loader, in high level Forth with whatever capabilities you like - as you're no longer hamstrung by just 256 bytes, and you have an entire Forth to work with.

Since it's an extension of the native Forth, it's nice to have R/W capability rather than consider the embedded system as WOM (Write Only Memory)

Thanks, that does help my understanding!