Well not to cause aflame war but what are everyone's thoughts? Forth versus Lua.
I am researching an old 1984 Byte magazine and I notice whole article about forth...Isn't forth an interpreted language, not compiled...
Not binary all human readable.
That Byte issue is available
here. Forth is
threaded -- that is not the same as being interpreted. There may or may not be an
inner interpreter; if so it may consist of 3 to 5 opcodes of overhead for every function call, about the same overhead as imposed by the several opcodes required in a C system to set up and take down a stack frame. Maybe the best way to understand the notion of threading is to realize that a Forth program consists of a series of functions that directly pass parameters to one another on the special-purpose parameter stack, somewhat like commands in a unix pipeline.
There is indeed an interpreter in Forth that interprets human-readable code, often called the
outer interpreter, that reads source code and compiles it into that threaded binary code. The binary may be purely machine code (subroutine-threaded), a list of addresses of machine code (direct-threaded), or a list of pointers to machine code (indirect-threaded). The outer interpreter may, or may not, filter the generated binary code through an optimizer. Keyhole optimization of subroutine threaded code was my favorite way of doing Forth. Overall a multi-tasking Forth system can be extraordinarily fast because of its efficient two-stack architecture and cooperative multi-tasking.
A reason for using forth in embedded systems, like a BIOS or boot loader, is that the threaded code is very dense. I could fit a multi-tasking special-purpose operating system with device drivers for disk, network, timers, motors, etc., and a window manager (built directly on top of the graphics hardware) in a 32 Kbyte eprom. You use forth when you are minimizing every byte and every cpu cycle.
