[dreamcompiler]

There seems to be a common conception that Forth is always interpreted by some kind of virtual machine. But it's quite possible to compile Forth all the way down to native machine instructions with no loss of interactivity and without losing the rapid bootstrap capability the author describes. Such a Forth runs almost as fast as C (almost because modern out-of-order and other processor optimizations probably don't work well on compiled Forth code).

I used this approach when I bootstrapped a Forth compiler on the TI 34010 graphics chip in a similar fashion as the author. It even had local variables so you didn't drive yourself mad thinking about the stack all the time.

My favorite commercial example of such a Forth was Mach 2 Forth on the early (pre-OSX) Macs. I don't know if any modern Forths do down-to-the-metal compiling or local variables, but I'd be interested to find out.

[ehaliewicz2]

> local variables

I believe most modern forths will have these, gnuforth does for example.

> down-to-the-metal compiling

I think there are some that do this, but back in the day, the opinion of lots of forth programmers was that threaded code was good for the 90% of the program where performance didn't matter, and added an inline assembler for areas where it did.

[Someone]

And of course, you can always add support for local variables yourself. For an example, see http://turboforth.net/resources/locals.html, which takes 808 bytes to implement. That’s hefty, for some systems where one would use Forth, but, FTA, “Placing key values in locals will actually both increase peformance, and make your code smaller”, so you can earn that back if you use the facility enough)