# Lua bootloader replacing forth



## Phishfry (Aug 10, 2018)

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,
So it is an old-timer.

But to technical specifics, Isn't forth an interpreted language, not compiled, similar to Lisp.
Not binary all human readable.

Is Lua a interpreted or compiled language?


----------



## kbw (Oct 25, 2018)

I believe it's interpreted.

In any event, why would you want to rewrite loader? And why Lua?


----------



## SirDice (Oct 25, 2018)

https://wiki.freebsd.org/SummerOfCode2014/LuaLoader
https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068464.html


----------



## garry (Oct 30, 2018)

Phishfry said:


> 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.


----------

