6 ms·

An Embedded Forth Interpreter in 66 bytes (1991)

12 points by jwilliams 18y ago

jacquesm 18y ago
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 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 18y ago
  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).
gjm11 18y ago
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 18y ago
  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/10872cb68edcb526?pli=1 http://groups.google.com/group/comp.lang.forth/msg/10872cb68...
- jwilliams 18y ago
  Forth is quite often written in this bootstrapped way. Getting to interactive is the key in Forth (like many repl languages/systems). Edit: Here is another minimal Forth (asm) implementation I was looking at a while back: http://www.annexia.org/_file/jonesforth.s.txt http://www.annexia.org/_file/jonesforth.s.txt

12 points by jwilliams 18y ago

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 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 18y ago
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).

gjm11 18y ago

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 18y ago
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/10872cb68edcb526?pli=1 http://groups.google.com/group/comp.lang.forth/msg/10872cb68...
jwilliams 18y ago
Forth is quite often written in this bootstrapped way. Getting to interactive is the key in Forth (like many repl languages/systems). Edit: Here is another minimal Forth (asm) implementation I was looking at a while back: http://www.annexia.org/_file/jonesforth.s.txt http://www.annexia.org/_file/jonesforth.s.txt