Go to the first, previous, next, last section, table of contents.

System Architecture

Our Forth system consists not only of primitives, but also of definitions written in Forth. Since the Forth compiler itself belongs to those definitions, it is not possible to start the system with the primitives and the Forth source alone. Therefore we provide the Forth code as an image file in nearly executable form. At the start of the system a C routine loads the image file into memory, sets up the memory (stacks etc.) according to information in the image file, and starts executing Forth code.

The image file format is a compromise between the goals of making it easy to generate image files and making them portable. The easiest way to generate an image file is to just generate a memory dump. However, this kind of image file cannot be used on a different machine, or on the next version of the engine on the same machine, it even might not work with the same engine compiled by a different version of the C compiler. We would like to have as few versions of the image file as possible, because we do not want to distribute many versions of the same image file, and to make it easy for the users to use their image files on many machines. We currently need to create a different image file for machines with different cell sizes and different byte order (little- or big-endian)(6).

Forth code that is going to end up in a portable image file has to comply to some restrictions: addresses have to be stored in memory with special words (A!, A,, etc.) in order to make the code relocatable. Cells, floats, etc., have to be stored at the natural alignment boundaries(7), in order to avoid alignment faults on machines with stricter alignment. The image file is produced by a metacompiler (`cross.fs').

So, unlike the image file of Mitch Bradleys cforth, our image file is not directly executable, but has to undergo some manipulations during loading. Address relocation is performed at image load-time, not at run-time. The loader also has to replace tokens standing for primitive calls with the appropriate code-field addresses (or code addresses in the case of direct threading).


Go to the first, previous, next, last section, table of contents.