
An Embedded Forth Interpreter in 66 bytes (1991) - jwilliams
http://pygmy.utoh.org/3ins4th.html
======
gjm11
No, _not_ an embedded Forth interpreter in 66 bytes. (Unsurprisingly.)

What he's proposing is: You're doing embedded software development; you have a
Forth interpreter on your _host_ system (this will be much larger than 66
bytes); you put his 66-byte program on the embedded processor (this is _not_
in any sense a Forth interpreter, whatever he says); the 66-byte program
implements a simple protocol whereby the host can read and write memory on the
embedded processor, and call code there (provided that code doesn't care
what's in the registers when it's called, and leaves the stack the way it
found it).

A perfectly sensible idea, but his description of it as "Forth on the target
board" is pretty unreasonable. You could do exactly the same with any other
language on the host side. That wouldn't mean you had (e.g.) an "embedded
Common Lisp system in 66 bytes".

~~~
jacquesm
You are right, a more sensible title would be a remote program loader in 66
bytes :)

The authors reasoning on why to call it 'a forth implementation':

"Is it fair to call it a Forth even with all three instructions? After all, it
lacks a data stack, headers, either the inner or the outer interpreter (I
vacillate on this). It relies on the host (but, then, which target Forth
boards connected to a PC over a serial line do not rely on their hosts to at
least some extent?). It is extensible and even the main loop can be extended
to test for codes in addition to 01, 02, and 03. So, is it a Forth or not? I
lean toward "yes." It has the Forth attributes of simplicity, economy, and (I
hope) elegance. What, though, about linking together calls to earlier routines
in order to build later routines? The most obvious approach is to build simple
assembly language routines on the host and download them to the target one at
a time and test them. Then download higher level assembly routines that call
those earlier ones. This is the most memory efficient approach. If you do have
extra RAM available on the system then you can use the 3-instruction Forth to
build and test a full Forth, and then use it. Either way, starting with a
3-instruction Forth you get to work in an interactive, Forth-like
environment."

I don't really go for that explanation, it is redefining (pun intended) too
many words.

By his reasoning anything that implements load, store and call is a forth
implementation.

It actually gets mentioned with quotes in this list, indicating some
skepticism of it being a 'forth' implementation:

[http://groups.google.com/group/comp.lang.forth/msg/10872cb68...](http://groups.google.com/group/comp.lang.forth/msg/10872cb68edcb526?pli=1)

------
jacquesm
Now that is a pretty concise language :)

Here is my own forth implementation, it's not quite 66 bytes but perhaps a
little easier to read:

<http://ww.com/forth.c.txt>

Forgive me for the style, I was young and didn't know what I was doing ;)

An interesting holdover to modern times is that Java bytecode is somewhat
related to ucsd pascal p-code, which in turn owes some of its history to
forth. All three are 'stack machines', with Java and p-code having only the
one stack, forth has two.

~~~
jwilliams
Awesome - thanks. I'm working on a Forth-like myself at the moment :)

Also - Stack machines generally end up with more compact code, which I
understand was one of the key the motivation with Java (first, as an embedded
target in the very early days, then as a downloadable target when Java Applets
were the rage).

