1. Overview of the 4TrOn system
1.1. Short description
4Tron is based on the powerfull interactive language Forth. 4Tron can be viewed as a native Forth engine, but also as a powerfull operating system and working environment. 4Tron is based on earlier attempts to build a small native forth system. The system should enable the possibility to transfer source code (almost) unchanged to many different systems. Ofcourse this is what they say about Java and in a large extend C++, but things really get complicated when communication with the operating system comes into play. There needs to be a general library with routines available across all the platforms. This sounds nice in theory, but practical no. So 4Tron combines the operating system, development system and language in one package.
1.2. Architecture
The system is based on multitasking threaded forth engine. Most forths only support a LIFO way of compiling. What I mean by this, all code is written on top of earlier written code. And removing code fragments from memory can only happen in the reversed order of loading. In a multitasking system applications are loaded and unloaded in random order. Therefore the 'classic' memory management way of Forth is not applicable for 4Tron. To enable random loading and unloading of programs a memory management module is needed. To simplify both the kernel software and hardware requirements the memory management logic is executed in software and not by dedicated hardware. Most modern processor support some form of virtual memory management by using a MMU unit. These differ in supported protection schemes and paging handling. This hardware based virtual memory is strictly speaking not needed by a Forth engine even if used as OS. The only drawback of not using the hardware is the loss of protecting the kernel from bad-behaving-processes.
4Tron uses fixed sized segments, which can contain code, data or both. Some form of reference counting must be present to prevent segments from being unloaded while still in use by other parts of the system. In this respect these code segments act much like dynamic libraries. Each segment contains a vocabulary which can be exported globally. Thus an other process can put this vocabulary in its search-list and use the functions declared in the segment. A code segment can simply be shared by multiple processes.
1.3. The language compiler
Unlike traditional Forth compilers, the 4Tron compiler is state-less. It doesn't have a seperate interpret and compiling mode. All words are at default executed and compilinng must be switched on for each seperate word you want to compile by using the tick character (.') If a tick is typed at the end of a word it is compiled instead of executed. This solves the problem of state-smart words and a lot of complexity in the compiler at the same time. When a word is entered which ends with a tick it is first searched in the dictionary. If it isn't found, the trailing character is stripped and a search is done again. This gives the programmer a chance to define two different behaviours for compiling and interpreting, often used for optimizing compilers. If the own ticked version isn't provided the compiler will use a default routine which compiles a call or jump depending on implementation details.