-13 throw (Undefined word)
-19 throw (Word name too long)
スタックやコード・スペースやヘッダー・スペースはアクセス可能です。 マシン・コード空間は通常、読み取り可能です。 他のアドレスにアクセスすると、
オペレーティング・システムに応じた結果が得られます。 まともなシステムの場合: -9 throw (Invalid memory
address)
これは通常はキャッチされません。 一部のワード(制御フロー・ワードなど)はチェックを実行し、 ABORT" または -12
THROW (Argument type mismatch) となります。
実行トークンは、 ワードのインタープリター機能(interpretation semantics)を表します。 Gforth
はすべてのワードのインタープリター機能を定義します。 標準でインタプリタ機能が定義されていないが、 実行機能(execution
semantics)が定義されているワード(LEAVE を除く)については、 インタープリター機能が実行機能を実行します。
標準でインタープリター機能が定義されていないが、 コンパイル機能(compilation semantics)(および
LEAVE)が定義されているワードの場合、 インタプリタ機能はコンパイル機能を実行します。
一部の単語はコンパイル専用(compile-only)としてマークされており、 ' はこれらのワードに対して警告を出します。
一部のプラットフォームでは、 これにより -10 throw (Division by zero) が生成されます。 他のシステムでは、
通常、 これにより -55 throw (Floating-point unidentified fault) が生成されます。
オペレーティング・システムやインストール時の設定や Gforth の起動時の設定に応じて、 これはメモリー管理ハードウェアによって、
チェックされたり、チェックされなかったり。 これがチェックされている場合、 通常はオーバーフローが発生するするやいなや、
(プラットフォームとオーバーフローを達成した方法によって異なりますが、) -3 throw (Stack overflow) または
-5 throw (Return stack overflow) または -9 throw (Invalid memory
address) を受け取ります。 これがチェックされていない場合、 オーバーフローは通常、 原因不明の不正なメモリー・アクセスを引き起こし、
-9 throw (Invalid memory address) または -23 throw (Address
alignment exception) を生成します。 また、ALLOCATE とそのファミリーの内部データ構造も破壊し、
これらのワードにさまざまなエラーが発生する可能性があります。
他のリターン・スタック・オーバーフローと同様。
ディクショナリーで利用可能なメモリーを超えるメモリーを(allot で直接、 または , や create
などで間接的に)割り当てようとすると、 -8 throw (Dictionary overflow) が発生します。
ディクショナリーの末尾を超えてメモリにアクセスしようとすると、 結果はスタック・オーバーフローと同様になります。
Gforth は全てのワードのインタープリター機能(interpretation semantics)を定義します。 標準で実行機能(execution
semantics)が定義されているワード(LEAVE を除く)については、 インタープリター機能が実行機能を実行します。
標準ではインタプリタ機能が定義されていないが、 コンパイル機能(compilation semantics)(および
LEAVE)が定義されているワードの場合、 インタープリター機能はコンパイル機能。
一部のワードはコンパイル専用(compile-only)としてマークされており、
テキスト解釈(text-interpreting)すると警告が表示されます。
これらは書き込み可能なメモリーに配置されており、 変更することができます。
-17 throw (Pictured numeric ouput string overflow)
PARSE はオーバーフロー不可能です。 WORD はオーバーフローをチェックしません。
2 の補数マシンでは、 1倍長演算の場合は 2**bits-per-cell 、2倍長演算の場合は 4**bits-per-cell
を法(modulo)として演算が実行されます(符号付き型は適切なマッピングを使用)。 ゼロ除算は通常、-10 throw (divide
by zero) または -55 throw (floating point unidentified fault) を引き起こします。
除算のオーバーフローにより、 -10 throw (divide by zero) または -55 throw
(floating point unidentified fault) が発生したり、 -11 throw (result out of
range) が発生したりする可能性があります。 Gforth-fast エンジン(訳注: OSコマンドラインから
Gforth-fast で起動)では、 除算のオーバーフローまたはゼロによる除算の際に、 暗黙的に偽の結果を生成する可能性があります。
Convert と >number は現在、 何も警告を出さずにオーバーフローします。
データ・スタックは、 各ワード execute 後、 外部インタープリター(別名 テキスト・インタプリタ)によってチェックされます。
アンダーフローした場合は、 -4 throw (Stack underflow) が発出されます。 それとは別に、
オペレーティング・システムやインストール時の設定や(OSからの gforth)起動時の設定に応じて、 スタックがチェックされるかどうかが異なります。
チェックで検出された場合、 通常は、プラットフォームや、 どのスタックがどの程度アンダーフローしたかに応じて、 通常は -4 throw
(Stack underflow) または -6 throw (Return stack underflow) または -9
throw (Invalid memory address) が発生します。 注意: システムが(MMU を介した)チェックを使用している場合でも、
リアクションをトリガーするには、 プログラムがかなりの数のスタック項目をアンダーフローする必要がある場合があることに注意してください(その理由は、
MMU 絡みチェックがページ・サイズの粒度で動作するためです)。
チェックが行われない場合、アンダーフローによる症状はオーバーフローによる症状と似ています。 アンバランスなリターン スタック エラーは
-9 throw (Invalid memory address) や不正な命令(通常は -260
throw)など、さまざまな症状を引き起こす可能性があります。
Create とその子孫は -16 throw (Attempt to use zero-length string as
a name;長さ 0 の文字列を名前として使用しようとします)を発出します。 '
のようなワードは検索しても見つからない可能性があります。 注意: nextname
を使用して長さゼロの名前を作成できることに注意してください(ホントにそうすべきかどうかをよく確認してください)。
>IN が指し示す値が入力バッファの長さより大きい: ¶次にパース・ワードを呼び出すと、 長さ 0 の文字列が返されます。
RECURSE が DOES> の後に現れた: ¶DOES> の後のコードへの再帰呼び出しをコンパイルします。
RESTORE-INPUT の引数の入力ソースが現在の入力ソースと異なります: ¶-12 THROW 注意: 入力ファイルが閉じられると(たとえば、 ファイルの終わりに達したため、 その source-id
は再利用される可能性があることに注意してください。 したがって、 閉じられたファイルを参照する入力ソース仕様(input source
specification)を復元(restore)すると、 -12 THROW ではなく、 予期しない結果が発生する可能性があります。
将来的には、 Gforth は現在の入力ソース以外から入力ソースの仕様を復元(input source specifications)できるようになる可能性があります。
allot による割り当て解除はチェックされません。 これにより、通常、 メモリ・アクセス・フォールト(memory access
faults)や不正な命令の実行(execution of illegal instructions)が発生します。
プロセッサに依存します。 通常、 -23 throw (Address alignment exception) が発生します。
アライメントがオンになっている 486 以降のプロセッサ上の Linux-Intel では、 アライメントが正しくないと -9 throw
(Invalid memory address) が発生します。 報告によると、
アライメント制限があるのに違反を報告しない一部のプロセッサがあるとのことです。
,, C,: ¶他のアライメント・エラーと同様。
PICK および ROLL を実行:他のスタック・アンダーフローと同様。
チェックされていません。 カウンタ付きループのワード群は、 リターン・スタック項目の先頭がループ制御パラメーターであると単純に想定し、 それに応じて動作します。
IMMEDIATE): ¶abort" last word was headerless".
TO で使用される VALUE で名前が定義されていません: ¶-32 throw (Invalid name argument) (名前がローカル変数であるか、 CONSTANT
によって定義されている場合を除きます。 後者の場合は、 定数が変更されるだけです)。
', POSTPONE, ['], [COMPILE]): ¶-13 throw (Undefined word)
DO, ?DO, WITHIN): ¶Gforth は、 それらが同じタイプであるかのように振る舞います。 つまり、 あなたは、 すべてのパラメーターを符号付きなどとして解釈することで、振る舞いを予測できます。
POSTPONE または [COMPILE] が TO に適用されました: ¶: X POSTPONE TO ; IMMEDIATE と仮定します。 X は TO
のコンパイル機能(compilation semantics)を実行します。
WORD によって返されるカウンタ付き文字列よりも長い文字列: ¶チェックされていません。 文字列は問題ありませんが、 当然ながら、 そのカウントにはその長さの最下位ビット達のみが含まれます。
LSHIFT、RSHIFT): ¶プロセッサに依存します。 一般的な振る舞いは、 0 を返し、 シフト・カウントの下位ビット達のみを使用することです。
CREATE によって定義されたワードではない: ¶>BODY は、 ワードの定義方法に関係なく、 ワードの PFA を生成します。
DOES> は、 定義方法に関係なく、 最後に定義されたワードの実行機能(execution semantics)を変更します。
たとえば、 CONSTANT DOES> は CREATE , DOES> と同等です。
<# 〜 #> の外で不適切に使用されているワード:チェックされていません。 いつものように、 メモリー障害が発生することが予想されます。