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