Next: Non-Relocatable Image Files, Previous: Image Licensing Issues, Up: Image Files [Contents][Index]
Gforth は、 (エンジン内の) リミティブだけでなく、 Forth で書かれた定義でも構成されます。 Forth コンパイラ自体もこれらの定義に含まれているため、 エンジンと Forth ソースだけでシステムを起動することはできません。したがって、 Forth コードをほぼ実行可能な形式のイメージ・ファイルとして提供します。 Gforth が起動すると、 C言語のルーチンがイメージ・ファイルをメモリにロードし、 オプションでアドレスを再配置し、 イメージ・ファイル内の情報に従ってメモリ(スタックなど)を設定し、 (最終的に) Forth コードの実行を開始します。
デフォルトのイメージ・ファイルは gforth.fi (GFORTHPATH 上の何処か)です。 -i
または --image-file または --appl-image オプションを使用すると、
別のイメージを使用できます(see Invoking Gforth)。 例:
gforth-fast -i myimage.fi
イメージ・ファイルにはさまざまなバリエーションがあり、 イメージ・ファイルの生成を容易にするという目標と、 イメージ・ファイルを移植できるようにするという目標の間のさまざまな妥協点を表しています。
Win32Forth 3.4 と、 Mitch Bradley の cforth は実行時に再配置を使用します。 これにより、
以下で説明する複雑な問題の多くが回避されます(イメージ・ファイルは、 特に手間をかけることなくデータを再配置できます)が、 しかし、
パフォーマンスが低下し(メモリ・アクセスごとに 1 回の追加)、 そして、 Forth
とライブラリ呼び出しまたは他のプログラムの間でアドレスを渡すことが困難になります。
対照的に、 Gforth ローダーはイメージのロード時に再配置を実行します。 また、 ローダーは、 プリミティブ呼び出しを表すトークンを適切なコード・フィールド・アドレス(直接スレッドの場合はコード・アドレス)に置き換える必要があります。
イメージ・ファイルには、 再配置の程度が異なる 3 種類があります。 つまり、 再配置不可能なイメージ・ファイルと、 データ再配置可能なイメージ・ファイルと、 完全に再配置可能なイメージ・ファイルです。
これらのイメージ・ファイルのバリエーションには、 いくつかの共通の制限があります。 それらは、 イメージ・ファイル・ローダーの設計によって引き起こされます:
ALLOCATE
されたメモリ・チャンク(およびそれらへのポインタ)を表すことができないことを意味します。 スタックの内容も表現されません。
アドレスを含む複雑な計算が実行される場合、 結果はイメージ・ファイルで表現できません。 このような計算を使用するアプリケーションがいくつか思い浮かびます:
table または
wordlist を使用する場合、 システムの起動時にハッシュ・テーブルが自動的に再計算されるため、問題はありません。
あなた独自のハッシュ・テーブルを使用する場合は、 同様のことをあなた自身で行う必要があります。
XOR されたアドレスを使用する二重リンク・リストの小さい実装があります。
このようなリストをイメージ・ファイル内で単一リンクとして表現し、 起動時に二重リンク表現を復元することもできます36。
docol: のようなランタイム・ルーチンのコード・アドレスは、
イメージ・ファイルでは表現できません(直接スレッド実装ではトークンがマシン・コードに置き換えられるため)。 回避策として、 実行時に
>code-address
を使用して適切なワードの実行トークンからこれらのアドレスを計算します(kernel/getdoers.fs の docol:
とそのファミリーの定義を参照してください)。
CODE ワードを再配置可能イメージ・ファイルに含めることはできません。
回避策は、アドレスを何らかの相対形式(たとえば、 レジスタに存在する CFA を基準とした相対形式)で表現するか、
アドレスが切り刻んでない(mangle)形式で格納されている場所からロードすることです。