Why, in my day we had to go uphill both ways in the snow to school.

Charles Steinkuehler charles at steinkuehler.net
Tue Dec 9 17:07:13 CST 2003


DCT Jared wrote:
> On Tue, 09 Dec 2003 07:10:22 -0600, Charles Steinkuehler wrote:
>>
>>I really want to build a tiny (probably about 10k) FORTH system for
>>linux that has no reliance on libc (making kernel calls directly,
>>instead) and use it to replace a lot of the shell-scripting and busybox
>>tools typically used in small linux systems (like the LEAF firewalls I
>>play with).  Should be a lot of fun.
> 
> Why Forth? Does FORTH produce tighter executables?

Yes...generally forth produces smaller code than most other systems 
because it's kind of a wierd cross between high-level language, 
interpreter (like shell scripting), and low-level "c" or assembly 
programming.  Forth is at once very interactive and easy to program 
(kind of like the old basic interpreters that ran in rom), while at the 
same time providing enough power to do pretty much anything required, 
from talking to physical hardware to creating software abstractions.

Note that forth (in the form of open-firmware) is used to create 
processor independent bootstrap code for low-level booting (current 
examples include all Sun hardware and Apple's power-macs).

The lack of reliance on a large (or huge) standard library is also a 
plus when working in resouce constrained environments.  While busybox is 
pretty cool, it won't run without a C library, and while there are some 
libraries available quite a bit smaller than the default glibc (which is 
huge), even they are pretty big (typically hundreds of KBytes).

Forth can easily talk directly to hardware, or other software (ie: the 
linux kernel), and could do things like extract packages to build a root 
filesystem image with a very low overhead (probably about 10K for the 
forth interpreter, and maybe 5-20K of forth code).  Compared to the 
current solution used on LEAF (ash at ~90K, busybox at ~125K, glibc at 
~625K, and the actual shell-script that creates the root system image at 
~7K), not only would the bootstrap code shrink drastically, it would be 
glibc independent, allowing extraction of root images based both on the 
normal glibc, as well as alternates like uClibc.

-- 
Charles Steinkuehler
charles at steinkuehler.net




More information about the Kclug mailing list