cLIeNUX Level 2 includes two complete development suites. The main one is the C portions of gcc and the associated utilities. The other is GForth, which is an ANSI Standard Forth implemented in gcc. These are all GNU tools.
C-only gcc is included because cLIeNUX Level 2 is intended to be a minimal complete Linux, and as such, must include the tools necessary to build a kernel. A Forth is included for a number of reasons. Many of the ideas cLIeNUX attempts to implement are manifest in Forth. cLIeNUX itself is an adaptation of ideas that arose while discussing a Forth-based platform over a period of some months with a number of people on the Internet.
More practically, Forth is good to learn if you learn programming if for no other reason than it is so different than other languages of similar power and generality. It's good to keep options in mind.
As C, FORTRAN, ADA, and most other compiled procedural languages are to assemblers, Forth is to a machine language monitor. Forth assumes interactivity at the lowest level. This aspect of Forth matches well with one of the basic assumptions of cLIeNUX; that you have absolute control over the box you are sitting in front of. As C for example can be considered a meta-assembler, with features added to assembly such as operations for non-rudimentary data types, flow control abstractions, functions, namespace scoping, recursion and so on, Forth adds similar additional power to a base of an interactive control program such as MSDos DEBUG or gdb or a Commodore 64-style "monitor" like SuperMON.
I call the class of languages derived from assemblers "monolithic compilers". The compiler in e.g. C is a monolithic binary that is in fact a process run on a C program before the assembler. In a Forth the functions analagous to compilation are within the Forth interactive command set. Programming in Forth is a matter of interactively increasing the interactive command set, including the possibility of extending the compiler. This is open-source by design.
Monolithic compilers, like assemblers, have a rich history on large systems, particularly networked systems. Important compilers were sometimes available only via some kind of electronic communication, some kind of timeshareing scenario. Interactive systems like Forth are historically more typical of smaller, single user systems. Now that the typical cheap single-user system is more than powerful enough to run the most sophisticated operating systems, I believe a powerful synergy may emerge. Forth is included in the core of cLIeNUX to facilitate that synergy.
WHAT
A Forth is the instruction set for a 2-stack machine. There are a number of silicon Forth engines, or Forth may be implemented in software as a programming language for some other CPU. In this case the Forth machine is virtual, but the instructions are the same. A Forth may be the entire software system for a particular CPU chip, or it may be under the control of an operating system, as is the case with GForth in cLIeNUX. The first Forths were the entire system for the machines they ran on, and some Linuces today are booted by a Forth, Open Firmware, that acts as an operating system until told to boot Linux.
The Forth virtual machine has an address space, a return stack and a parameter stack. It has no general purpose registers. The parameter stack is general, and deep enough for sensible use. There's about 100 basic Forth "words" that are the core of a Forth. This core set includes the interpreter, the compiler, very well-chosen versatile integer operators, and rudimentry text terminal IO.
This brings up one of Forth's weaknesses, namespace explosion. Individual Forth words tend to be simple, so there are lots of them. A parameter stack item has no type. Rather, Forth provides un-overloaded operators of various types. GForth has a lot of words. Forth's other great weakness is that UNIX wasn't written in it. Forth and UNIX are approximately contemporary. Forth is also RPN, or post-fix. 2 + 2 is 2 2 + in Forth. This is a bit off-putting, but is NOT a weakness. Tremendous simplicity is preserved this way. The only syntactic construct required for an RPN (Reverse Polish Notation) interpreter is "put numbers on the parameter stack". If the interpreter puts numbers on the stack, then everything can be performed immediately. There is NO syntax parser required at all. Tokens are delimited by spaces, tokens may be words or numbers, when a token is obtained, the number is placed on the stack, or the word/command is performed. That's it.
HOW