Next: Fully Relocatable Image Files, Previous: Image Licensing Issues, Up: Image Files   [Contents][Index]

12.2 Image File Background ¶

Gforth consists not only of primitives (in the engine), 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 engine and the Forth source alone. Therefore we provide the Forth code as an image file in nearly executable form: Integers, strings etc. are represented as-is, data addresses in in relocatable form (section index and offset from the start of the section), and tokens (integers) for code addresses of primitives.

When Gforth starts up, a C routine loads the image file into memory, relocates the addresses and generates native code for the primitive invocations and replaces the tokens with code addresses of this native code (or of the code for the primitives in the engine), then sets up the memory (stacks etc.) according to information in the image file, and (finally) starts executing Forth code.

The default image file is gforth.fi (in the GFORTHPATH). You can use a different image by using the -i, --image-file or --appl-image options (see Invoking Gforth), e.g.:

gforth-fast -i myimage.fi

Gforth image files have several limitations:

• Only the sections are in the image; in particular, this means, that an image file cannot represent ALLOCATEd memory chunks (and pointers to them). The contents of the stacks are not represented, either.
• Dynamically generated native code is not stored in the image, but is regenerated from the tokens for the primitives on loading.
• The only kinds of relocation supported are: adding the same offset to all cells that represent data addresses; and replacing primitive tokens with code addresses of code in the engine, or dynamically generated code.

  If any complex computations involving addresses are performed, the results cannot be represented in the image file. Several applications that use such computations come to mind:

  • Hashing addresses (or data structures which contain addresses) for table lookup. If you use Gforth’s tables or wordlists for this purpose, you will have no problem, because the hash tables for them are rebuilt automatically when the system is started. If you use your own hash tables, you will have to do something similar.
  • There’s a cute implementation of doubly-linked lists that uses XORed addresses. You could represent such lists as singly-linked in the image file, and restore the doubly-linked representation on startup.³⁶
  • On many architectures addresses are represented in machine code in some shifted or mangled form. You cannot put CODE words that contain absolute addresses in this form in a relocatable image file. Workarounds are representing the address in some relative form (e.g., relative to the CFA, which is present in some register), or loading the address from a place where it is stored in a non-mangled form.