JPH0762825B2 - コード生成方法及び装置 - Google Patents

Description

【発明の詳細な説明】

発明の背景 本発明はディジタル コンピュータ プログラム用のコ
ンパイラ（翻訳編集装置）に関し、特に複数の異なるコ
ンピュータ言語に対して使用されるのに適しており、複
数の異なる目標又は目的機器（ターゲット マシン）用
のコードを発生するコンパイラ フレームワーク（フレ
ーム構造）に関するものである。 コンパイラは一般に特定の原始言語（ソース ランゲー
ジ）を、特定のオペレーティングシステムを有する特定
の目標機器を動作させるに用いるターゲット コードに
翻訳するように構成する。例えばフォートラン（Fortra
n）コンパイラは、VMSオペレーティングシステムを使用
するVAXアーキテクチュア（構造）を有するコンピュー
タ用コードの発生に利用でき、あるいはMS/DOSを実行す
る80386コンピュータ用のＣコンパイラとして利用でき
る。これらのランゲージ・アンド・ターゲット・スペシ
フィック・コンパイラの中間部分は、大部分の構造及び
機能が共通にされる。このため、新規なコンパイラ構造
は、既存のコンパイラの構成要素のいくつかを使用し、
他のものを変形することによって構成できる。それにも
係わらず、ソース ランゲージ及びターゲット マシン
の各組合せ用に新しいコンパイラを構成するのが従来の
プラクティスであり、新規な高性能コンピュータ アー
キテクチュア（構造）を設計するとき、一般に使用され
るソース ランゲージ（原始言語）のそれぞれに対しコ
ンパイラを書換えるのが主要のタスクとなる。 コンピュータ エイデッド ソフトウェア エンジニヤ
（CASE）の分野は、コンパイラ技術に大きく依存してい
る。CASEツール及びプログラミング環境は、コア コン
パイラによって構成される。これに加えてコンピュータ
ハードウェアのパーフォーマンス仕様は、多くの場
合、コンパイラ技術と全体的に関連する。プロセッサの
速度は、一般に高レベルのランゲージ ベンチマークに
よって測定され、従ってコンパイラの最適化が、新規な
コンピュータ機器の価格のパーフォーマンス係数に影響
する。 種々の異なる高レベル ランゲージ及び異なるコンピュ
ータ アーキテクチュアに対し、コンパイラの機能を適
合させるためには、コンパイラ フレームワークのコア
構成素子の共通性を高めることが望ましい。コンパイラ
のフロント エンドはソースのコード モジュールに直
接アクセスするので、必然的に各ソースランゲージごと
に特定のものとなり（このことをソーススペシフィック
という）、パスカル（Pascal）を翻訳するように構成さ
れたコンパイラのフロント エンドはＣ方式を翻訳する
ことはできない。同様にコンパイラのバック エンド内
のコード発生器は、ターゲット コンピュータ アーキ
テクチュアのインストラクション セットを使用する必
要があるので、各ターゲットコンピュータごとに特定の
ものとなる（このことをターゲットスペシフィックとい
う）。従ってより汎用構成とし得るのは、コンパイラの
中間構成素子である。コンパイラのフロント エンド
は、第１にソース コードを中間ランゲージに翻訳する
のが一般である。従って高レベル ソース ランゲージ
により書かれたソースプログラムは、コンパイラの内部
操作用のより要素的なランゲージとして現れる。このフ
ロント エンドは、プログラムまたはルーチンを、中間
ランゲージで、シンボル テーブルと共にいわゆるグラ
フの形に表現するのが普通である。これら２つのデータ
構造、すなわち中間ランゲージ グラフ及びシンボル
テーブルがコンパイラによって内部的に使用されるプロ
グラムを表わす。このような、ユニバーサルまたは汎用
性の中間ランゲージ及びシンボル テーブル構造を形成
すると、フロント エンドに後続する構成素子を一層汎
用的に構成できる。 コンパイラのフロント エンドが中間ランゲージ グラ
フ及びシンボル テーブルを形成した後、種々の最適化
技術が一般に実行される。フロー グラフを再配置す
る。すなわちプログラムの書直しを行い、ターゲット
マシンの実行速度を最適化する。これらの最適化のいく
つかは、ターゲットに応じた特定のもの（ターゲットス
ペシフィック）であるが、多くは汎用的又は一般的（ジ
ェネリック）なものである。共通的に使用される最適化
（optimization）は、コード モーション、強度減少等
である。コンパイラの次の内部構造は、レジスタ及びメ
モリ割当てである。この特点迄は、データレファレンス
は、何れの場所に記憶されているかに関係なく、ネー
ム、またはアブストラクト内の変数及び定数であった。
しかしその後は、データレファレンスはもっと具体的な
位置、例えば特定のレジスタ及びメモリ ディスプレー
スメント（未だメモリ アドレスではない）のような具
体的位置に指定される。この時点において、レジスタ割
当ての形態で、レジスタ内のデータをより少ないレジス
タ レファレンスで維持する一層の最適化が可能であ
る。このためプログラムを再度再配置し、レジスタの利
用性を最適化させることができる。レジスタの割当ても
ある程度はターゲットのマシンにより定まり、このため
コンパイラの汎用性は：ターゲットCPUのレジスタ セ
ットの数、サイズ、特殊割当てを指定する必要がある。
レジスタ及びメモリ割当ての次にコンパイラは、コード
発生フェースを行い、これにおいて、オブジェクト（目
的）コード イメージを形成する。これらのコードはタ
ーゲット マシンのランゲージまたはインストラクショ
ン セット内に存在するものであること当然であり、す
なわちマシーンスペシフィックである。次で目的コード
イメージを連係させて実行可能なパッケージを形成
し、各種ラン・タイム モジュール等を付加する（これ
らすべてはマシンスペシフィックである）。 典型的なコンパイラ構造では、中間ランゲージ グラフ
の構造、及びレジスタ及びメモリの割当ての最適化は、
汎用化をもっとも行い易いものである。しかし乍ら現在
もっとも一般的に使用されている高レベル ランゲージ
の大幅な相違、及びターゲット マシン構造（アーキテ
クチュア）の相違が一般的なコンパイラ コア構造の実
現を妨げる障害となっている。 発明の概要 本発明の１実施例においては、コンパイラ フレームワ
ークにジェネリック（汎用）“シェル”または制御及び
シーケンシング メカニズムを設け、さらにジェネリッ
ク（汎用）バック エンドを設ける（ここでコード発生
器はターゲット・スペシフィックとすること当然であ
る）。ジェネリック バック エンドはオプティマイゼ
ーション、レジスタ及びメモリ割当て：ならびにコード
発生の機能を有する。シェルは種々のホスト コンピュ
ータで実行することができ、バック エンドのコード発
生機能は多数のコンピュータ アーキテクチュアの任意
の一つに適合させることができる。フロント エンドは
それぞれの異なるソース ランゲージ、例えばCobol,Fo
rtran,Pascal,C,C＋＋,Ada等に適合される。フロント
エンドはソース コード モジュールを走査し、解析を
行い、ソースコードモジュールからソース コードで表
わされたプログラムの中間ランゲージ表現を発生する。
この中間ランゲージは、任意のソース コード ランゲ
ージを一般的に表わすように構成されているため、フロ
ント エンドとバック エンド間のインタフェイスは標
準フーマットとなり各ランゲージに特定のフロント エ
ンドに対し書直しを必要としない。 フロント エンドによって形成された中間ランゲージ表
現は、基本ユニットとしてタプル（tuple---組）を基礎
としている。ここでは各タプルは、例えばロード、スト
ア、加算、ラベル、ブランチ等の実行すべき単一演算を
表わす。各タプルに対しフロント エンドにより、種々
の必要情報のフィールドを有するデータ構造が形成され
る。タプルの順序系列に沿って、フロント エンドは、
普通のプラクティスにより変数、ルーチン、ラベル等の
すべてを参照するシンボル テーブル（記号表）を生成
する。タプルはブロック内に順番付けられたシーケンス
（順番）に並んでおり、ブロックは、ルーチンまたはラ
ベルで開始され、ブランチで終わるコードの一部であ
り、例えばブロックの出発点と終了点の間に入口または
出口が存在してはならない。各ブロックはさらにデータ
構造またはノードでもあり、その後位及び前位のブロッ
クへのポインタを有している（これらはシンボル表内の
シンボルである）。互いにリンクされたブロックによ
り、中間ランゲージ グラフと称されるフロー グラフ
が形成され、これはバック エンドにおいて、最適化、
レジスタ及びメモリ割当て、等を行なうのに使用される
プログラムの表現である。 本発明の特徴の１つは、フロント エンドとバック エ
ンド間のインタフェイス内のエフェクト（効果 effec
t）及び従属性（dependencies）を表わすメカニズムで
ある。タプルはメモリに書込むときはエフェクトを有
し、何れか他のノードが書込みを行なった位置より読出
しを行なったときはディペンデンシイ（従属性）を有す
る。種々の高レベル ランゲージは演算の表示に異なっ
た方法を有し、１つのランゲージでは同じシーケンスが
結果又は従属性（ディペンデンシイ）を許するが、他の
ランゲージではこれを許さない。従って、ソース ラン
ゲージと独立にあるいは無関係に、プログラム実行の効
果を記述するメカニズムを設ける。このメカニズムは、
コンパイラ フロント エンドに、詳細なランゲージ特
定情報を発生しこれをコンパイラ バック エンド内の
マルチ・ランゲージ オプティマイザ（最適化装置）に
送る手段を与える。グローバル オプティマイザがこの
メカニズムを用いて、共通のサブエクスプレッション
（副表示）認識及びコード モーションを含む適切且つ
有効な最適化を決定する。タプルの中間ランゲージ及び
機構は、バック エンド（オプティマイザ）がフロント
エンドに質問（中間ランゲージ グラフより情報を得
る）しうるような情報を有しており、これによってバッ
ク エンドはターゲット マシンに対して１つのタプル
に対し発生されたコードの実行が、他のタプルに対する
コードによって計算された値に悪影響を及ぼすかどうか
を決定することができる。この点に関し、バック エン
ドとフロント エンド間のインタフェイスはランゲージ
独立性を有する。バック エンドはどのランゲージをコ
ンパイルしているか知る必要がない。この利点は、異な
るバック エンド（及びシェル）を各ソース ランゲー
ジごとに書込む必要がなくなり、その代り、フロントエ
ンドを各ソースランゲージに対し適合させるだけで最適
化コンパイラを各ソース ランゲージごとに発生させる
ことができる点にある。 本発明の１実施例の他の特徴は、コンパイラの最適化部
分内でインダクション変数（variable）を解析する方法
を使用することである。変数がループを通じ毎時１回づ
つインクレメントまたはデクレメントされ、毎回ループ
を通じ最大で１回遂行されるときはこれをインダクショ
ン変数と称する。最適化にはこのインダクション変数の
検出に加えて、インダクティブ エクスプレッション
（expression---式，表示）を検出する。これはインダ
クション変数の直線関数として計算しうる式である。一
般にいってこの最適化の目的は、倍算を加算で置換する
ことであり、これはより安くかつ高速であり、（ほとん
どの機構で）強度減少として知られているものである。
インダクション変数の検出には、ポテンシャル インダ
クション変数の“セット（組）”を用いる必要があり、
各ループに対しこれをダイナミック（動的）に行なうの
は高価かつ複雑となるので、IDEFセットの構成に用いら
れるサイド エフェクト セットを用いることにより改
良を行なっている。 本発明の１実施例の付加的特徴は、最適化の１つに“フ
ォールディング常数（folding constant）”（Ｋ倍まは
KFOLDルーチンと称される）を行なう機構である。この
機構は、式をある一定数に減少させ、ルーチン中のより
多く時間を必要とする計算を行なう代わりに、コンパイ
ル（翻訳編集）時間に計算しうるようにするものであ
る。重要な特徴は、ユーザにより符号化または計算を行
なう代わりに、コンパイラのフレームワーク自体によっ
てKFOLDコードを形成することである。KFOLDビルダはフ
ロント エンドの如く機能し、丁度他のランゲージ・ス
ペシフィック フロント エンドの如く機能するが、ソ
ース コード入力は無く、その代わり入力は中間ランゲ
ージ内であり、オペレータのすべてのリストとデータ
タイプのすべてのリストよりなるのみである。その利点
は、より多くKFOLDパッケージ通過が形成され、これは
より安価に行いうることである。 さらに他の実施例の特徴は、TDモジュールと称されるタ
イプ（型）定義（type definition）機構にある。この
モジュールは、フロント エンド及びバックエンドに使
用され、プログラムタイプ情報を生成し、これをオブジ
ェクトモジュールに組み込み、リンカーまたはデバッガ
ーに使用させるメカニズムを与える。“タイプ情報”の
生成は、シンボル テーブル生成に関連して実行され、
フロント エンドがバック エンドに、プログラム タ
イプ情報を抽象（アブストラクト）表現で指定すること
ができる。TDモジュールは、フロント エンドに基本タ
イプ及びアブストラクト タイプを記述させるサービス
ルーチンを与える。 これに加えて、さらにある実施例は、コード テンプレ
ート（型板）を用いて、複式パス方式でコードの形成を
行なう方法を特徴とする。コンパイル（翻訳編集）工程
中、コード テンプレートの選択及び適用は４つの異な
る時に生ずる。 （１）パターン選択またはPATSELECTフェーズはCONTEXT
内のパターン マッチを行い、最良のコード テンプレ
ートの選択にパスする。 （２）TNASSIGN及びTNLIFEはCONTEXTの任務を行い、選
択したタンプレートのコンテクスト（文脈）アクション
の使用を用い、式の順序の評価を解析し、テンポラリー
ネーム（TNs）をノンローカルなライフタイムをもっ
てコード テンプレートに割当てる。 （３）TNBINDは選択したテンプレートのバインディング
アクションの使用をパスし、コード テンプレートに
ローカルなライフタイムを有するTNsを割当てる。 （４）最後にCODEは選択されたテンプレートのユース
コード発生アクションをパスし、オブジェクト コード
の発生に導く。 図面の説明 本発明の新規と信じられる特徴は添付の請求の範囲に記
載されている。しかし本発明の他の特徴及び利点は、添
付図面と共に、以下の特定の実施例の記載を参照すれば
より良く理解されよう。 第１図は、本発明の特徴を用いたコンパイラの概略図； 第２図は、本発明の各種特徴の方法が実行されるホスト
コンピュータのブロック図による電気回路図； 第３図は、第１図のコンパイラによって、ソース コー
ド フォーム、中間ランゲージ フォーム、トリー フ
ォーム及びアッセンブリ ランゲージ フォームに翻訳
編集（コンパイル）されるべきコードを示す図； 第４図は、第１図のコンパイラで使用されるタプル（tu
ple）のデータ構造を示す図； 第５図は、第１図のシェルの演算の論理的フロー チャ
ート； 第６図は、常数を含む符号の例のリスト； 第７図は、本発明の１つの特徴によるタイプ（型式）の
規定を説明するためのデータ フィールドと関係（ポイ
ンタ）の図である。 実施例の詳細説明 第１図において、本発明の１実施例によるコンパイラ
フレームワーク10は、ポータブルな、再ターゲット可能
なコンパイラ用のランゲージに無関係なフレームワーク
である。このコンパイラ フレームワーク10は、シェル
11と称されるポータブル動作システム インタフェイス
11と、再ターゲット可能なオプティマイザ（最適化装
置）並びにコード発生器（バック エンド）12よりな
る。シェル11はポータブル（機械語のプログラム生成デ
バイスの普遍性）であり、すなわち数個演算システム、
例えばVAX/VMS,V_nix等ホスト コンピュータで実行する
任意のものに適合できる。このシェルは第２図に示す如
く、ホスト コンピューティング（計算）システムで演
算を行なうホスト演算システム13によって動作し、この
システムは主として、システム バス16によって主メモ
リ15に結合され、かつI/Oコントローラ18によってディ
スク メモリ17に結合されたCPU14を含んでいる。シェ
ル11及びコンパイラ12はフロント エンド20と組合わさ
れて、特定のソース ランゲージに対するポータブル
は、再ターゲット可能なコンパイラを創出する。従って
本発明のフレームワーク10に基づくコンパイラは３つの
基本部分より成る。 これらはシェル11、特定のホスト演算システム14にテー
ラーされている。これはコンパイラのホスト エンバイ
ロメント（システム環境）を決定する； 特定のソース ランゲージ（C,C＋＋，パスカル，フォ
ルトラン,Ada,obol,等）に対するフロント エンド20,-
--これはコンパイラのソース ランゲージを決定する； 特定のターゲット マシン（VAX,RISC等の特定の構造）
に対するバック エンド12,---これはコンパイラのター
ゲット マシンを決定する。 シェル11、フロント エンド20及びバック エンド12間
の各インタフェイスは固定されているので、本発明によ
るコンパイラの各個別構成素子は自由に交換することが
できる。すなわちフロント エンド20を複数の交換可能
なフロント エンド、例えば１つがFortram用、１つがC
obol用、１つがPascal用、１つがＣ用等で構成すること
ができる。同様にVAXコンピュータのVMSで動作するよう
に作製されたシェル11を、RISCワークステーションのU
_nixのオペレーティング システムで動作するシェル11
で置換することができ、この間フロント エンド20とバ
ック エンド12は何等変更を加えないようにすることが
できる。 シェル11は、ホスト オペレーティング システム13と
その他のコンパイラ間の固定インタフェイスとなる。本
発明のシェルはいくつかの利点を有する。第１にシェル
11は、演算システム13の基本的特徴に対するポータブル
なインタフェイスを提供する。例えば、フロント エン
ド20は、ホスト演算システム13のファイル システム、
コマンド パーシング、あるいはテープ記憶配置等の詳
細を知る必要がない。これはこれらすべてのサービス
は、シェル ルーチンによりアクセスされ、シェルは使
用する演算システム13に合うように形成（テーラー）さ
れているからである。第２にシェル11は、いくつかのコ
ンパイラ素子、例えばコマンド ライン パーシング
（構文解析）、ファイル組み込みプロセシング、ダイア
グノスティク（診断）ファイル形成素子を単一で行う素
子を設けるような重複設備を排除しうる。第３に、これ
らの共通の素子を使用することによって、フレームワー
ク10を用いて創設されたコンパイラ間に一貫性あるいは
両立性（consistensy）が保証されることである。この
フレームワーク10を用いるよう形成されたすべてのコン
パイラは、同じフォルマットでリスト ファイルに書き
込みを行い、コマンド ライン クオリファイヤに同じ
処理を行い、同形のエラー メッセージを発行する等を
行う。第４に、シェル11内に共通のシェル装置を持つこ
とによりコンパイラの内部積分が改良される。これは、
フロント エンド20とバック エンド12が同じシェル機
能を有するからである。例えばシェル ロケータ パッ
ケージの使用は、ソース ファイル位置がソース リス
ティング、フロント エンド発生ダイアゴノスティク、
バック エンド発生ダイアゴノスティク、オブジェクト
リスティイング、デバッガー情報に両立性が得られる
からである。 フロント エンド20はフレームワーク10によって構成さ
れるコンパイラの構成素子中、翻訳すべきソース ラン
ゲージを理解する唯一の素子である。このソース ラン
ゲージは、コンパイラの入力を規定するソース コード
ファイル（モジュール）21のテキストを創出するのに
用いられるソース ランゲージである。フロント エン
ド20は第１にシェル11を呼出し、コマンド ライン情報
を得て、ソース ファイル21よりテキスト ラインを得
る。第２に、フロント エンド20はシェル11を呼出し、
ファイルのリスティング、ダイアゴノスティック メッ
セージの書込み、並びに場合によって特殊ランゲージ用
の他のファイルへの書込みを行う。第３にフロント エ
ンド20は、語彙、構文、意味の解析を行い、ファイル20
内のソース テキストを、フロント エンド20とバック
エンド12間のインタフェイス22によって使用されるラ
ンゲージに無関係なインターナル レプレゼンテーショ
ン（内部表現）に翻訳する。第４に、フロント エンド
20は、バック エンド12を呼出し、インターナル レプ
レゼンテーション内の情報よりターゲット システム
オブジェクト コード23を形成する。第５にフロント
エンド20は、ルーチンを行い、これによってバック エ
ンド12はコール パス24を介して、バック エンド処理
中、バック エンドはランゲージ特定情報を呼出す。第
１図のコンパイラ フレームワークには含まれていない
が、遂行可能でターゲット マシーン25を駆動するイメ
ージを形成するオブジェクト モジュールまたはイメー
ジ23をリンクさせるリンカーを含んでいる。 コンパイラのバック エンド12がコードを創造するター
ゲット マシン25はある特殊構造のコンピュータであ
る。すなわち例えば、これはある特定の番号のセットと
データ幅を有するレジスタであって、そのロジックは特
定のインストラクションは特殊のインストラクション
セットを遂行し、特殊なアドレス モードが得られる等
である。これらの例は、（１）既述のVAXアーキテクチ
ュアであり、（２）はMIPS Inc.より得られる部品番号R
2000またはR3000の32ビットRISCチップに基づくRISC型
のアーキテキチュアで、プリンティス ホール（Printi
ce Hall）1987に、“MIPS R2000 RISCアーキテクチュ
ア”として記述されたものであり、（３）は1990年６月
29日出願の係属中出願番号第547589号に記載された64ビ
ット レジスタによるアドバンストRISCアーキテクチュ
アである。その他種々のアーキテクチュアも同様に収容
することができる。 一般にいって、フロント エンド20は、ソース コード
をインタフェイス22の内部表現に翻訳する際、オブジェ
クト コード25が実行されるターゲット マシンのアー
キテクチュアを考慮する必要がない。これは、この中間
表現はターゲット マシン25のアーキテクチュアより独
立しているからである。フロント エンド20の特徴のい
くつかはターゲット システムに適合するように特別仕
様とする必要な場合がある。しかし、データ表現の一部
の特徴、例えば割当て（アロケーション）及び整合（ア
ライメント）は、ターゲット マシン25のアーキテクチ
ュアに適するように特別仕様とする方が好都合であり、
またルーチン呼出しの仮数メカニズムは、ターゲット
システムの呼出標準により定まり、さらにルーチン ラ
イブラリ インタフェイスは、各ターゲット システム
それぞれに対しおそらく異なったものとなる。 バック エンド12は、フロント エンド20によって形成
された内部表現22を、ターゲット システムのオブジェ
クト コード23に翻訳するように機能する。バック エ
ンド12は、最適化26、コード発生27、蓄積およびレジス
タ割当て28、およびオブジェクト ファイル排出29の基
本機能を遂行する。最適化機能は、コードが内部表現の
とき、このコードに対し遂行される。バック エンド20
はさらにユーティリティ ルーチンを含んでおり、これ
らはフロント エンド20より呼出されて、シンボル テ
ーブル30および中間ランゲージ データ構造を創出す
る。 ユーザ（すなわち第２図のコンピュータ システムのユ
ーザで、コンピュータ システムは演算システム13を遂
行している）が第１図のコンパイラを呼出す（呼出し可
能なインタフェイスを通ずるか、あるいは他の機構を通
じて）と、シェル11はその制御を受ける。シェル11はフ
ロント エンド20を呼出し、ソース ファイル15よりの
入力ストリームをオブジェクト ファイル23に翻訳す
る。フロント エンド20はバック エンド12を呼出し、
オブジェクト ファイル23内に各オブジェクト モジュ
ールを生成する。フロント エンド20は、オブジェクト
モジュール23内の各個別ルーチンに対するコードの創
出のためバック エンド12を呼出すこともあり、またこ
れは全モジュールに対し一度にコードを形成するバック
エンド ドライバーを呼出すこともある。 フロント エンド20はソース コード21のオペランド解
析（parse）を行い、ソース コードで表わされたプロ
グラムの中間ランゲージ版を形成する。タプルはソース
ランゲージが１つの演算を行った表現（式）である。
例えば第３図を参照するとき、ソース ランゲージで表
わされた式、 Ｉ＝Ｊ＋１ は、中間ランゲージで表わされた４つの式に分解され、
これらは＄1,＄2,＄３および＄４である。IL（中間ラン
ゲージ）によるこのようなコードの表現方法は、フェッ
チ（取出し）オブジェクトを表わすシンボルＪを付した
アイテム31で表わされる第１タプル＄１を含む。次のタ
プルはリテラル、アイテム32であり、シンボル１で参照
される。次のタプルはアド（ADD）、アイテム33であ
り、これはタプル＄１および＄２の結果を参照する。最
後のタプルはストア、アイテム34であり、タプル＄３の
結果を参照し、この結果をシンボル テーブル内にテン
ボルＩで記入する。この表現は第３図の論理ツリーによ
っても表わされ、タプルは同じ参照番号で識別表示され
る。これと同じソース コードのラインはRISCタイプの
ターゲット マシンにおいて、第３図に見られるような
一般形でレジスタ ファイル内にREG4の如きレジスタを
用いて３つのインストラクション、LOAD:ADD整数、およ
びSTOREの集合で表わすことができる。あるいはCISCマ
シンで、導出されるコードは、図示の如くの単なるイン
ストラクションADD、＃１、Ｊ、Ｉでもありうる。 この場合タプルはコンピュータ プログラムの基本的語
句であり、本発明において使用される形態では、データ
構造35であって、これは少なくとも第４図に示される要
素を含む。これらは （１）オペレータ（演算子）およびタイプ フィールド
36で、例えばフェッチ、ストア、アド（Fetch,Store,Ad
d）等、 （２）ロケータ37、ソース モジュール21内の何処にこ
のタプルに対するソース等価が位置するかを規定、 （３）他のタプル、リテラル ノードまたはシンボル
ノードに対するオペランド ポインタ38、 例えば第３図のＩおよび＃１に対するポインタ、タプル
＄１および＃２等である。さらにタプルはアトリビュー
ト（属性）フィールド39を有し、これらは、例えばラベ
ル（Label）、条件ブランチ（Conditional Branch）、
アーギュメント（Argument）（コールに対する）、また
はSym Ref（シンボル テーブル内のシンボル）を含
む。このタプルは、このタプルのブロック内の順番を表
わす番号フィールド40を有している。 フロント エンド20はソース コードを解析してタプル
を識別し、次いでコードの基本ブロックを識別する。コ
ードのブロックは一連のタプルとして規定され、第１タ
プルと最終タプルの間に入口または出口は存しない。一
般に１つのブロックはラベルまたはルーチン エントリ
ーによって初まり、他のラベルへのブランチにより終わ
る。フロント エンド20の任務は、ソース コード21を
解析し、タプルおよびブロックを識別することであり、
これはフロント エンドはそのランゲージに対し特定
（スペシフィック）であることが要求される。このため
タプルは、フィールド41を有し、これは当該タプルがブ
ロックの初めであるか、ブロックの終わりであるか否か
を教える。 以下に詳細に説明するように、本発明の特徴の１つは、
エフェクトの表現方法にある。タプルは、メモリ位置
（ILレベルにおいて、シンボルで表わされる。）に記憶
または書込みを行ったとき、または他のタプルがある位
置に書込みを行ったことに従属することによりエフェク
トを有する。従って第３図の例で、タプル＄４はエフェ
クト（Ｉのストア）を有し、＄１は、従属性（内容Ｊ）
を有する。このため第４図に示されるデータ構造は、こ
のタプルのこれらのエフェクトおよび従属性を記憶する
フィールド42および43を有する。 第１図のコンパイラの単一エクゼキューションは、第５
図のフロー チャートに示されるようにしてシェル11に
よって行われる。オペレーティング システム13を介し
てユーザにより、第１図のコンパイラが呼出されるとシ
ェル11は第５図のアイテム（項目）45で示されるような
制御を受ける。コマンド ライン内のユーザは、動作さ
せるべきモジュール21内のリストまたは“プラス リス
ト”を特定する。次のステップは、シェル11によるフロ
ント・エンド ルーチンGEM＄XX_INTの呼出しであり、
これはアイテム46で示すようにフロント エンドのすべ
ての必要な初期化を行う。このフロント エンド ルー
チンGEM＄XX_INTは付属書に説明されている。次いでシ
ェル11はグローバル（大域）コマンド クオリファイヤ
（修飾子）を解析し、アイテム47に示されるようにフロ
ント エンド ルーチンGEM＄XX_PROCESS_GLOBALSを呼
出す。次にこのコンパイラを含むオペレーティング シ
ステム13のレベルで使用されているコマンド ランイ内
の各“プラス・リスト”に対し、シェルは一連の動作を
遂行する。これはプラス・リストをチェックする決定点
（デシジョン ポイント）48を用いるループによって実
行される。プラス・リスト内にアイテムが残っている限
り、アイテム49-52に示される動作が行われる。これら
の動作は、アイテム49で示される如く、コマンド ライ
ンによって特定されるソース ファイル21の評価および
これらに対する入力ストリームの形成と、これに次いで
アイテム50で示される如く、このローカル クオリファ
イヤ（このプラス・リストに特定の）を解析し、GEM＄X
X_PROCESS_LOCALSを呼出し、すべてのフロント エンド
決定プロセスを行い、これらのクオリファイヤにより規
定された出力ファイルを開く。このループの動作は、さ
らにアイテム51に示される如く、フロント エンド ル
ーチンGEM＄XX_COMPILEを呼出し、入力ストリームを翻
訳し、次いでアイテム52で出力ファイルをクローズす
る。ループが完結すると、プラス・リストで示されたす
べてのプロセスが行われたことを表示し、次いでアイテ
ム53でフロント エンド ルーチンGEM＄XX_FINIを呼出
しフロント エンド クリーンアップのすべての動作を
行う。次いで実行が終了し、アイテム54でのインボーカ
制御に戻る。 シェル11はGEM＄XX_COMPILEを呼出し、単一入力ストリ
ームを翻訳する。入力ストリームは、コンパイラ コマ
ンド ライン内の単一の“プラス リスト”で規定され
るモジュール21またはソース ファイルおよびこれに含
まれるすべてのファイルまたはライブラリ テキストの
連鎖を表わす。コンパイラはフロント エンド20が入力
ストリームの翻訳中、複数のオブジェクト ファイル23
を特定することを許さないが、誤動作によって、単一入
力ストリームの翻訳より単に１つのオブジェクト ファ
イル23が形成されることがある。 GEM＄XX_COMPILEを呼出す前に、シェル11は入力ストリ
ームを創造し、ローカル クオリファイヤを解析し、出
力ファイルを開く。GEM＄XX_COMPILEの呼出後、シェル1
1はすべての入力および出力ファイルをクローズする。 （GEM＄XX_COMPILEおよびこれにより呼出されるフロン
ト エンド ルーチン）フロント エンド20は、入力ス
トリームよりソース レコード21を読出し、これらをイ
ンタフェイス22（タプル、ブロック等の中間ランゲージ
グラフおよびシンボル テーブルを含む）の中間レプ
レゼンテーションに翻訳し、バック エンド12を呼出
し、この中間レプレゼンテーションをオブジェクト フ
ァイル23内のオブジェクト コードに翻訳する。 オブジェクト ファイル23は任意の数のオブジェクト
モジュールを具えて良い。パスカル（PASCAL）は全入力
ストリームに対し１つのオブジェクト モジュール（MO
DULEまたはPROGRAM）を創り出す。（１例として）ORTRA
Nは入力ストリーム内の各ENDステートメントに対し別個
のオブジェクト モジュールを創造する。BLISSは各MOD
ULEに対し１つのオブジェクト モジュールを創造す
る。 オブジェクト モジュール23を創造するため、フロント
エンドは入力ストリームおよびいくつかの後続ストリ
ーム（ソース モジュール21と呼び得る）をインタフェ
イス22の内部レプレゼンテーションに翻訳する。この内
部レプレゼンテーションは、モジュールに対するシンボ
ル テーブル30と各ルーチンに対する中間ランゲージ
グラフ55よりなる。次いでフロント エンド20はバック
エンド ルーチンを呼出し、オブジェクト モジュー
ル23を初期化し、メモリ（ストレージ）アロケーション
28を介してシンボル テーブル30内のシンボルに対しメ
モリの割当てを行い、このメモリを初期化し、エミッタ
29を介しルーチン用のコードを形成し、オブジェクト
モジュール23を完成させる。 コンパイラはパッケージの集合によって構成され、これ
らパッケージのおのおのは、翻訳プロセスのいくつかの
アスペクトに関するルーチンまたはデータ構造の集合を
規定する。各パッケージは、一般にパッケージ機能の略
記号である２文字コードで識別される。パッケージへの
インタフェイスはスペシフィケーション（仕様書）ファ
イルで規定される。パッケージがZZの名前を付されてい
るときは、スペシフィケーション ファイルはGEM＄ZZ,
SDLとなる。 パッケージのスペシフィケーション ファイルに付され
ているすべてのシンボルは、このパッケージより輸出
（エクスポート）されたと称される。一般にいってパッ
ケージZZより輸出された特定のプレフィックス記号は、
GEM＄ZZで始まる名称を有する。グローバルおよびエク
スポーテッド（輸出）ネームに対する特定の前置記号
（プレフィックス）の変換は表１に示してある。 シェル11は共通のコンパイラ機能を支持するルーチンの
集合である。これらのシェルの各成分は互いに相関して
いるので、何れかのシェル成分を使用するプログラムは
全シェルに到達する。しかし、プログラムがシェル11を
使用し、バック エンド12を使用しないようにすること
もできる。これは利用度の少ないプログラムを生産性上
の特徴（入力ファイル連鎖および包含、すなわちコマン
ド ライン解析、診断ファィル形成、品物リスト ファ
イル、等）をもって書込むのに便利な方法である。シェ
ル11はこれを使用する何れものプログラムにとっての実
際上の“主プログラム”であり、アプリケーションの本
体は以下に述べる条約によってシェル11より呼出される
ものであることに留意され度い。BLISSプログラムよ
り、シェル パッケージZZを使用するには、ユーザはLI
BRARY GEM＄ZZを行う。他のランゲージよりシェルを使
用するには、ユーザはまず第１にシェル スペシフィケ
ーション ファイルを実行ランゲージに翻訳するを要す
る。 シェル パッケージは次の記述に要約できる。すなわち
これらは附属書（アッペンディクス）内の仕様書ファイ
ルに文書化されている。多くのシェル ルーチン アー
ギュメント（例えば、整数、ストリング等）は表２に述
べるカテゴリーの１つに属する。 シェル11よりフロント エンド20に至る間のインタフェ
イスにはいくつかの要求が加えられる。第１図のコンパ
イラが呼出されると、シェル11は制御を受けるので、フ
ロント エンド20はエントリ ポイントを宣言し、シェ
ル11がこれを呼出しうるようにし、かつグローバル変数
を宣言しフロント エンド スペシフィケーションをシ
ェル11に通過させる。フロント エンド20は１例として
表３に記載されたグローバル ルーチンを行う。これら
のルーチンはパラメータを持っておらず、結果なし（no
result）に戻る。 バーチュアル メモリ パッケージ（Virtual Memory P
ackage）（GEM＄VM）： このバーチュアル メモリ パッケージは、仮想（バー
チュアル）メモリの割当てを行う標準インタフェイスを
提供する。これはVMS LIB＄VN機能のゾーン化したメモ
リ概念を支持する。実際上VSM,GEM＄VMの下には、LIB＄
VM上にほとんど透明な層が存する。しかしGEM＄VMイン
タフェイスは如何なるホスト システム上でも変化なく
支持されることが保証されている。 ロケータ パッケージ（GEM＄LO）： ロケータ パッケージは、ソース テキスト21のレンジ
長を記述する。（レンジ長は：スタートおよびエンド
ファイル、行および列番号）。テキスト入力パッケージ
はロケータを読出すべきソース行（ライン）に戻す。ロ
ケータは、シンボル テーブル30および中間ランゲージ
ノード43にも用いられ、メッセージおよびデバガー
テーブル形成を行い、かつリスト ファィルの何れの個
所に遂行すべきリスティング パッケージが存するかを
規定する。ロケータは長ワードにより表わされる。ロケ
ータ パッケージはロケータ データベースを維持し、
ロケータを創成し通訳するためのルーチンを作成する。
さらにユーザ作成ロケータも設けられており、これはフ
ロント エンドをして、自身のロケータを作成し、非標
準ソースより到来するプログラム エレメント（例えば
BLISSマクロまたはAda一般例‐‐“インスタンティゼー
ション”）を記述する。 テキスト入力パッケージ（GEM＄TI）： テキスト入力パッケージは、ソース ファイル21、ネス
テッド（インクルーデッド）ソース ファイル21及び障
害及び関連ファイル スペシフィケーションの連続をな
し、一方でフロント エンド20を下側の演算システム13
のI/O機構より絶縁する。ソース ファイルのテキスト
は同時に１ラインを読出される。テキスト入力パッケー
ジGEM＄TIは、ロケータ パッケージGEM＄LOと協動し、
読出す各ソース ラインを記述するロケータを形成す
る。 テキスト出力パッケージ（GEM＄TX）： テキスト出力パッケージは、任意の数の出力ファイル44
への出力を同時に形成する。テキスト入力パッケージと
同様に、その呼出側を演算システム13より絶縁する。参
照記号または記述子（デスクリプタ）によって通過する
ストリングに書込みを行なう。自動ライン ラッピング
およびインデンテーション（行末の字揃え）、ページ
ラッピングを行い、ユーザにより設定されたページ開始
ルーチンを呼戻す。 リスティング パッケージ（GEM＄LS）： リスティング パッケージは、ソース ファイル21（テ
キスト入力パッケージGEM＄TIにより読出された）のコ
ピーを有する標準型式のリスト ファイルを書き、これ
にロケータによって特定される位置にフロント エンド
11により設けられた注釈を付す。リスト ファイルはGE
M＄TX出力ファイル44として創造され、これにはフロン
ト エンド20は、GEM＄TX出力ルーチンを用いて直接書
込みを行なう。 内部表現（インターナル レプレゼンテーション） モジュール21のインターナル レプレゼンテーション
は、ソース モジュール21の各ルーチンに対し、コンパ
クト中間ランゲージ グラフ55またはCILGおよびモジュ
ールに対するシンボル テーブル30を有する。これら両
者は、ノードにより構成されているポインター リンク
ト データ構造である。 第１図のフレームワークによりノードを説明する。フロ
ント エンド20とバック エンド12間で用いられるほと
んどすべてのデータ構造（並びにバック エンド12によ
ってプライベートに使用されるデータ構造）はノードで
ある。本明細書でいうノードなる語は、メモリの自己識
別ブロックであり、一般にヒープ（リスト）によりGEM
＄VM_GETを割当てられる。すべてのノードは、フィール
ドGEM＄NOD_KINDおよびGEM＄NOD_SUBKINDを有するGEM＄
NODEの集合形を有する。カインド（Kind）は、ノードの
一般形を識別するGEM＄NODE_KINDSの列挙より得られる
値である。サブカインドは、カンドによって特定される
ノードの一般的クラス内の特定の種類のイードを識別す
るGEM＄NODE_SUBKINDSの列挙型よりの値である。すべて
の特殊ノードは、そのカインド フィールドによって決
定される集合型式を有する。例えば、カインドがGEM＄N
ODE_K_ SYMBOLであれば、ノードはGEM＄SYMBOL_NODEを
有する。ノードに付随する型式（タイプ）は上述の命名
規約に従う必要がないことを記憶されたい。インタフェ
イスのノード型式およびこれらに付随する列挙型式常数
は表４のファイル内に記載されている。 第１図のコンパイラ フレームワークは簡単なツリー構
造シンボル テーブル30をもっており、この内で各シン
ボル ノードは、ブロック ノードより離れたチェイン
内で互いにリンクされており、これらがツリー状に配置
されている。コンパイラによって使用されるべきすべて
のシンボル情報は、このシンボル テーブル30に含まれ
なければならない。さらに翻訳されたプログラムのリテ
ラル値を表わすリテラル ノード；変数を割当てるメモ
リ エリア（PSECTおよびスタック フレーム）を表わ
すフレーム ノード；およびルーチン エントリー ポ
イントのパラメータ リスト内のエレメントを表わすパ
ラメータ ノードも設けられている。シンボル テーブ
ル構造およびシンボル テーブル ノードの内容につい
て以下に説明する。 中間ランゲージは、すべてのソース コード21の内部表
現に対して用いられるランゲージである。フロント エ
ンド20は、コンパクト中間ランゲージ グラフ55または
CILGとして翻訳されるべきルーチンのコードを記述す
る。これは、単に第４図のCILタプル ノード（単にタ
プル ノード、あるいは略してタプルとも称される）の
リンクしたリストであり、これらのおのおのは、演算を
代表し、オペランドを表わすタプル ノードへのポイン
タ38を有している。ノードはシンボル テーブル ノー
ドへのポインタ38をも有しうる。中間ランゲージの詳細
については以下に述べる。 フロント エンド20は、モジュール21の中間レプレゼン
テーション22を同時１ノードで形成する必要があり、ま
たノードを互いにリンクさせてシンボル テーブル30と
ILデータ構造55とするを要する。このルーチンおよび表
５のマクロについても付属書に記載してあり、これらは
内部レプレゼンテーション22のデータ構造の形成および
実行に用いられる。 バック エンド12は、フロント エンド20がブロックお
よびシンボル ネームをどのようにして表わすかについ
ての推定を行なわない。その代り、フロント エンド20
は、バック エンド12がこれらのネームを得るために用
いうる標準コール バック インタフェイスを形成する
を要する。 各シンボル ノードは、フラッグGEM＄SYM_HAS_NAMEを
有し、各ブロック ノードはフラッグGEM＄BLK_HAS_NAM
Eを有する。フロット エンド20がシンボルまたはブロ
ック ノードを初期化するとき、そのネーム フラッグ
をセットして、これに対しネーム ストリングが存する
か否かを表示する必要がある。（シンボルおよびブロッ
クのいくつか、例えばグローバルおよび外部シンボルお
よびトップ レベル モジュール ブロックはネームを
有するを要する。） これはSTパッケージ内のグローバル変数GEM＄ST_G_GET_
NAMEである。フロント エンドはバック エンドの呼出
し前にこの変数をセットして、表５の記載に適合するコ
ールバック ルーチンをアドレスしうるようにするを要
する。 GEM＄CO_COMPILE_MODULEインタフェイスを用いてソース
モジュールを呼出すため、フロント エンド（すなわ
ち、ルーチンGEM＄XX_COMPILE）は次節に述べる各操作
を（順次）行なう。 1.内部レプレゼンテーションの創設 フロント エンド20の第１の任務は、ソース モジュー
ルの内部レプレゼンテーション22を創設することにあ
る。次いで、これはGEM＄TI パッケージを用いて、入
力ストリームよりソース モジュール21を読出し、ソー
ス モジュール21の字句、構文、意味上の解析を行い；
付属書に記載するGEM＄STおよびGEM＄ILルーチンを用い
て、上述のモジュールに対するシンボル テーブル30お
よび中間ランゲージ グラフ55を作成する。 これに加えて、モジュールのソース リストは、GEM＄L
Sシェル パッケージへの呼出しをもって注釈され、モ
ジュール内のエラーはGEM＄MSパッケージへの呼で報告
される。 ソース モジュール21がコードを形成し得ない程度の重
大なエラーを含んでいるときは、フロント エンド20は
GEM＄LS_WRITE_SOURCEを呼出してリスト ファイルを書
き、かつGEM＄ST_FINIを呼出して中間レプレゼンテーシ
ョン22に対し割当てられたすべてのスペースを釈放する
を要する。さもないと、これは次のステップに進んでし
まう。 2.コールバッグ ルーチンの特定 フロント エンド20は、バック エンド12を呼出してモ
ジュール21を翻訳する前に、ルーチンのアドレスを有す
る次の如きグローバル変数で、バック エンド12より呼
出される変数を初期化するを要する。 （１）GEM＄ST_G_GET_NAME:上述の如くシンボル テー
ブル30内でシンボル名およびブロック ノード名を付さ
れるルーチンをアドレスするため初期化するを要する。 （２）GEM＄SE_Gグローバル変数は、以下に説明する如
く：ソース ランゲージで規定されるサイド（側）効果
解析を行なうルーチンのアドレスのため初期化するを要
する。コンパイラは、前もって定められているサイド効
果ルーチンで、GEM＄SE_DEFAULT_IMPLEMENTATION を呼
出すことによって選択され、フロント エンド20の初期
の発達中に用いるに適したルーチンの所定の収集を行な
う。 （３）GEM＄ER_G_REPORT_ROUTINEは、バック エンド12
の検出エラーを報知するフロント エンド20のアドレス
を有しており、これについては以下に説明する。 3.翻訳（コンパイレーション）の実行 内部レプレゼンテーションが完全な場合には、フロント
エンド20はGEM＄CO_COMPILE_MODULE（後述）を呼出す
ことができ、これをターゲット マシン オブジェクト
レプレゼンテーション23に翻訳する。次いで、フロン
ト エンドはGEM＄LS_WRITE_SOURCEを呼出す必要があ
り、これによって入力ストリームをリスト ファイル内
に表記する。さらにこれは、GEM＄ML_LIST_MACHINE_COD
Eを呼出し、翻訳したモジュールのアッセンブリ コー
ド リストを作成する。 通常GEM＄LS_WRITE_SOURCEはGEM＄_COMPILE_MODULEの後
に呼出されるようにするを要し、これによってソース
リスト21は、バック エンドの処理中に生ずるすべての
エラー メッセージに注釈付けをすることができるよう
にする。しかし、フロント エンド20に、デバッギング
スイッチを設け、これによってGEM＄LS_WRITE_SOURCE
が第１に呼出されるのが好都合である。かくすることに
よって、バグ（プログラムの誤り）がコンパイラをして
バック エンド処理中にアボート（流産）をさせてもソ
ース リストに到達しうるようにすることができる。 4.クリーン アップ 翻訳が終了すると、フロント エンドは、GEM＄CO_COMP
LETE_MODULEを呼出してバック エンド プロセスに使
用されていたスペースを釈放し、次いでGEM＄ST_FINIを
呼出して内部レプレゼンテーションに使用されたスペー
スを釈放しなければならない。 バック エンド12は、例えば初期化されない変数、到着
しない符号、あるいはスタティック メモリ初期化のコ
ンフリクトの如き、ユーザに告知しなければならないソ
ース プログラム内の状態を表わすと思われる条件を翻
訳中に検出することができる。しかし特定のフロント
エンド20は、これらの条件のうちの何れを報告するか、
または発行されるべき詳細なメッセージについて、顧客
仕様とするを要する。 これを可能とするため、バック エンド12は、アドレス
がグローバルな変数であり、以下に説明するようなアー
ギュメントの並び（リスト）をもつGEM＄34_G_REPORT_R
OUTINEを呼出し、検出したすべての異例な状態を報告す
るようにする。 付属書中に、GEM＄_REPORT_ROUTINEという名で、フロン
ト エンドがその内に自分自身のルーチン報告アドレス
を記憶していない限り、そのアドレスはGEM＄ER_G_REPO
RT_ROUTINEである欠陥エラー報告ルーチンがある。この
欠陥ルーチンは次の３つの用途がある。 （１）欠陥ルーチンは適正妥当なメッセージを生ずるの
で、フロント エンドの開発者は、特別に顧客要求で設
ける必要がなければ、フロント エンドにそれ自体のル
ーチンを設けることを考えなくて良い。 （２）フロント エンドの開発者が、報告ルーチンを作
成する道を選んだ場合、この欠陥ルーチンを見本（モデ
ル）とすることができる。 （３）フロント エンド ルーチンはフィルタ作用をも
って構成でき、これは特定のエラーのみをプロセス（あ
るいは無視）し、他のすべてに対し先の欠陥ルーチンを
呼出す。 エフェクトを表わすインタフェイス 共通のサブエクスプレッション（CSEs）、不変数エクス
プレッション（式）、並びにコード モーションの機会
を検出する重要なステップとして、バック エンド12内
のオプティマイザ（最適化装置）26は、２つのエクスプ
レッション タプルが同じ値を計算することを保証され
ているとき、これを決定しうるを要する。この基本的判
定基準は、次の場合に、エクスプレッションＢがエクス
プレッションＡと同じ値を計算することである。 1.AおよびＢは同じ値のリテラル（直定数または数字定
数）に対し、リテラル参照を行い、CSEは同じCSEを参照
し、またはシンボルは同じシンボルを参照する場合、ま
たは、 2.a,Bへのルーチンの開始時より、各制御フロー パス
毎にＡを評価し、かつ b.AおよびＢは同じ演算とデータ タイプを有し、かつ c.Bのオペランドが対応のＡのオペランドと同じ値の計
算を行い（明らかに再帰的定義である）、かつ d.Aの評価よりＢの評価に至る何れもの通路に生ずるタ
プルが、Ｂの計算値に影響を及ぼさないこと。 第１図のオプティマイザ26はそれ自身で基準（criteri
a）1,2a,2bおよび2cを評価できる。しかし基準2dは、翻
訳すべき言語（ランゲージ）の意味によって定まる。す
なわち、ソース コード モジュール21のランゲージに
よって定まる。しかしバック エンド内のコンパイラ12
はランゲージ独立性である必要があるため、フロント
エンド20に必要な情報を伝達する一般的インタフェイス
を設ける。１つのタプルの実行が、他のタプルによって
計算された値に何時影響するか？インタフェイス22は、
オプティマイザ26をしてこの質問を発せしめ、フロント
エンド20のコンパイラはこれに答えなければならな
い。 このインタフェイス22の下側のモデルはいくつかのタプ
ルがエフェクトを持っており、他のタプルはデペンデン
シイ（従属性）を有するものである。タプルはその１つ
又は１つ以上のメモリ位置の内容を変化するときエフェ
クトを有する。タプルはこのタプルにより計算された値
がメモリ位置の内容に従属して定まる時はこれをメモリ
位置についての従属性を有する。従って１つのタプルの
実行は、他のタプルが従属しているメモリ位置をも変更
するエフェクトを有しているとき他のタプルによって計
算された値に影響を及ぼす。 アドレス アリスメティックが分岐をしている場合およ
び間接アドレスの場合には、一般にタプルによって評価
した特定のメモリ位置を決定するたとが不可能である。
従って評価し得る可能性のあるメモリ位置のセットに対
してはヒューリスティック（発展的）近似によってこれ
を行なわなければならない。 実際のインタフェイス22はフロント エンドに対し２つ
の機構を形成し、これによってオプティマイザー26に従
属性情報を通信する。これらは直線的従属性インタフェ
イスおよびエフェクト クラス インタフェイスであ
る。 直線従属性インタフェイスにおいて直線コードの従属性
を決定するためオプティマイザー26はフロント エンド
20に次を質問する、（１）タプルをエフェクト スタッ
ク上に押上げこれを再び押し下げる。（２）実行がおそ
らく特定のタプルによって計算された値に影響を及ぼす
であろうエフェクト スタック上の一番上のタプルを発
見する。 オプティマイザー26が任意のフロー パスのリセットを
通じてプログラム流の結果生じたエフェクトを計算する
を要する場合、上述の直線機構は適当でない。このよう
な状態では、フロント エンド20は特定の番号（初期に
は128）のエフェクト クラスで各々がメモリ位置のい
くつかのセット（おそらく決定的ではない）の表わす特
定番号を決定する。エフェクト クラスのセットはビッ
ト ベクトルによって代表される。例えばあるエフェク
ト クラスは特定の変数の名前を付され、手続コールに
よって変更されるメモリ位置、又は間接に参照番号（ポ
インタ デリファレンス）によって評価されるメモリ位
置のセットによってエフェクト クラスは代表される。 エフェクト クラス インタフェイスに対し、オプティ
マイザーはフロント エンドに次を質問する。（１）特
定のタプルによって変更され得るメモリ位置を有してい
るエフェクト クラスのセットを計算する。（２）特定
のタプルが従属していると思われるメモリ位置を有する
エフェクト クラスのセットを計算する。 このエフェクト クラス インタフェイスを用いてオプ
ティマイザーは各基本ブロックに対しこの基本ブロック
内の何れかのタプルによって変更され得るメモリ位置を
有しているエフェクト クラスのセットを代表するビッ
ト ベクトル（LDEFセットと称する）を計算することが
できる。 オプティマイザーはさらにフロント エンドに対し次を
質問する。（３）特定の可変シンボルをもったものに付
随しているメモリ位置と思われるエフェクト クラスの
セットを計算する。 この情報は分割されている最適化フェース（以下参照）
によって使用され、分割された対象（キャンディデー
ト）のライフタイムを計算する。 オプティマイザー26はこれらの情報を次の如くして使用
する。これらのインタフェイスの存在理由は、バック
エンド12内のオプティマイザーをして“Ａの評価よりＢ
の評価までの何れのパスにもＢによって計算された値に
影響を及ぼすタプルが発生しなくなる”時を決定させる
ためである。ＡおよびＢが同じ基本ブロック内に発生し
た場合には、これは丁度“A,B間にＢによって計算され
た値を変化させ得るタプルが存しない状態”を意味す
る。これは直線従属インタフェイスを用いることによっ
て容易に決定することができる。 Ａを包含する基本ブロックが、Ｂを包含する基本ブロッ
クより優勢である場合（Ｂを有する基本ブロックへのル
ーチン エントリー濃度よりの各フロー パスはＡを有
する基本ブロックを通過する。）オプティマイザーは基
本ブロックX1,X2,---Xnを発見し、ここにおいてX1はＡ
を含んでいる基本ブロックであり、Ｂを含んでいる基本
ブロックであり、又各Xiは直近のＸ（ｉ＋１）よりも優
勢である。この場合テストは２つの部分を有する。 1.Aと基本ブロックX1の間にタプルは存してはならない
か、又は基本ブロックXnの始めとＢの間に、これが存し
てはならないか、或いは基本ブロックX2,X3,---X（ｎ−
１）の何れにもこれが存してはならない。なお、これら
はＢによって計算した値を変化させうるものである。こ
れは直線従属インタフェイスを使用することにより容易
に決定することができる。 2.2つの基本ブロックXiとＸ（ｉ＋１）の間にはＢによ
って計算された値を変化させうるタプルを含むフロー
パスが存在してはならない。オプティマイザーはこのこ
とをエフェクト クラス メカニズムによりXiよりXi＋
１までのすべてのフロー パスについて生ずる全部の基
本ブロックのセットにつきLDEFの統合を計算することに
より試験し、これによってこのセットの交差がＢが従属
するであろうメモリ位置を含むエフェクト クラスのセ
ットとの交差を計算し、これによりこの交差が空である
か否かを試験する。 以下にはこのインタフェイスの構造について説明する。
インタフェイス ルーチンはバック エンド12によって
呼出される。フロント エンド20はこれがバック エン
ド12を呼出す前に利用可能なインタフェイスの具体化を
行なう必要がある。フロント エンド20は標準グローバ
ル変数のインタフェイス ルーチン エントリー ポイ
ントのアドレスを示すことによりこれを行なう。この場
合オプティマイザー26はこれらのルーチンの１つよりこ
れらのルーチンの１つを呼出した場合適当なグローバル
変数よりルーチン アドレスをロードする。以下におい
てインタフェイス ルーチンはGEM_SE_xxxで始まる名前
を付けて表される。フロント エンドは各対応のインク
レメンテーション ルーチンのエントリー アドレスを
グローバルな変数でGEM_SE_G_xxxの名前を記されたもの
として記憶しなければならない。 エフェクトおよび従属性を有しているタプルがこのイン
タフェイスに関係する。ILタプルのうち極く僅かなもの
がこのようなエフェクトおよび従属性を用いる。（大雑
把に言ってメモリーを行なうタプルがエフェクトをもつ
ことができる。エフェッチをタプルが従属性を持つこと
ができ、ルーチンを行なうタプルはこれらの両者をもつ
ことができる。） さらに細かく言うと各タプルは次の如きカテゴリーの１
つの範疇に入る。 1.何等エフェクトを持たず、又何れのエフェクトにも従
属しないタプル（例:ADD）。このクラスに属するタプル
はエフェクト スタック上に押し上げられることはな
い。さらにこのようなタプルはGEM_SE_EFFECTSを通過し
たこともない。 2.エフェクトを有し、しかし従属性を持たないタプル。
（例:STORE）。 3.従属性を有しているが、何等エフェクト（影響）を生
じないタプル（例:FETCH）。 4.エフェクト（アウト エフェクト）および従属性の個
別のセット（イン エフェクト）の両方を有するタプル
（例：プロセデュア コール）。 5.エフェクトおよび従属性の両者を有するタプル。タプ
ルが従属するエフェクトは、タプルが生ずるエフェクト
と同一である。（例:PREINCR）。 特殊なタプルすなわちDEFINESと称されるタプルを設
け、フロント エンド20が何れのタプルとも対応してい
ないエフェクトを特定することができる。DEFINESの１
つの可能な用途はタプルがBLISS CODE COMMENT特徴を行
い、これは最適化が許されない垣根を越えて行なうもの
である。CODE COMMENTの翻訳はDEFINESタプルであり、
これはすべてのエフェクトを有し、従ってすべてのタプ
ルを無効化する。 アーギュメントを通過するタプル（例えばARGVALおよび
ARGADR）はエフェクトおよび従属性を有する。しかし、
パラメータ タプルのエフェクトおよび従属性（ディペ
ンデンシイ）は実際上このパラメータ タプルが属して
いるルーチン コールに属するものと考えられる。例え
ばBLISS ルーチン コールＦ（X,X＋Ｙ）ではパラメー
タＸはＸを変化させるエフェクトを有する。しかしこれ
は前に計算された.X＋.Yの値を無効化させない。これは
Ｆが呼出されるまでエフェクトは実際に生じないからで
ある。 第４図はデータ構造はあるタプルがフロント エンド20
およびバック エンド12の両者よりアクセスされた場合
を示し、この構造のうちのつくつかのフィールドはフロ
ント エンドおよびバック エンドのみのアクセスに制
限されている。 エフェクトあるいはディペンデンシイを用いる各タプル
は１つ以上のロング ワード フィールド42又は43を有
し、この典型的なものはGEM_TPL_xxx_EFFECTS又はGEM_T
PL_xxx_DEPENDENCIESと名付けられる。特殊のタプルに
対し使用されるフィールドの名前は中間ランゲージの章
において説明する。バック エンド内のいずれのコード
もこれらのフィールドを検査し変更することがない。こ
れらはフロント エンドの使用に対しリザーブされてい
る。シンボル テーブル30の各シンボル濃度内に同じよ
うなロング ワード フィールドでGEM_SYM_EFFECTSと
名付けられたものがあり、これらのフロント エンド20
よりの使用に対しリザーブ（予約）されている。 直線従属性インタフェイスに対してのルーチンの説明を
以下に行なう。フロント エンドは次の如くのルーチン
の実行を行なう。 GEM_SE_PUSH_EFFECT（EIL_TUPLE:イン GEM_TUPLE_NOD
E）これはEIL_TUPLEパラメータ内のアドレスを有するDI
Lタプルをエフェクト スタック上に押し上げる。 GEM_SE_PUSH_EFFECT（EIL_TUPLE:イン GEM_TUPLE_NOD
E）はエフェクト スタックより一番上のEILタプルをポ
ップ（打ち抜く）する。これはアドレスがEIL_TUPLEパ
ラメータにあるタプルであるとを保証する。これはこの
パラメータが冗長性をもっていることを意味すること当
然である。しかしながら、フロント エンドがエフェク
ト スタックに対し単一のスタック動作を行なわないポ
ップ手続では記号を簡単化することができる（以下のイ
ンクレメンテーション参照）。 GEM_TUPLE_NODE）＝ GEM_SE_FIND_EFFECT（ EIL_TUPLE:イン GEM_TUPLE_NODE） MIN_EXPR_COUNT:値） そのGEM_TPL_EXPR_COUNTフィールドがMIN_EXPR_COUNTよ
り大であり、その実行がEIL_TUPLEによって形成された
結果を変化する可能性のある最も最近に押されたタプル
に戻る。スタック上の何れのタプルもがEIL_TUPLEに影
響を及ぼさない時は零（０）に戻る。さらにこのパラメ
ータ内で特定された同じタプルに戻ることもあり得る。 GEM_TUPLE_NODE）＝ GEM_SE_FIND_EFFECTS（ VAR_SYM イン GEM_SYMBOL_NODE, MIN_EXPR_COUNT:値） そのGEM_TPL_EXPR_COUNTフィールドがMIN_EXPR_COUNT
（以下に説明）より大であり、かつその実行が変数VAR_
SYMの値を変化させる可能性のある最も最近に押された
タプルに戻る。スタック上のいずれものタプルがEIL_TU
PLEに影響を及ぼさない時は０（零）に戻る。同じパラ
メータで特定された同じタプルに戻ることもありうる。 GEM_SE_PUSH_EFFECTおよびGEM_SE_POP_EFFECTを有する
タプルは、エフェクトを有するタプルによってのみ呼出
すことができる。 呼出しには順番がある。各EILタプルは、GEM_TPL_EXPR_
COUNTと称されるフィールドを持っている。このフィー
ルドは、EILGのウォーク内にタプルのインデックスを有
しており、この内の基本的ブロックは、ドミネータ ツ
リーを深度を第１にした予め定めた順番で訪問される。
バック エンド12がGEM_SE_PUSH_EFFECTをタプルＡによ
って呼出し、これに次いでタプルＢによってGEM_SE_PUS
H_EFFECTまたはGEM_SE_FIND_EFFCTを呼出し、この際そ
の中間にタプルＡによってGEM_SE_POP_EFFECTを呼ばな
いと、同じ基本ブロック内でタプルＡがタプルＢよりも
前にあるか、またはタプルＡをもつ基本ブロックがタプ
ルＢを持つ基本ブロックよりも正しく優位にあることが
保証される。従ってエフェクト スタック上のEXPR_COU
NTタプルの値が、スタック深度の増加に従って減少する
（すなわちより最近に押出されたタプルは、これより以
前に押出されたタプルよりも高いEXPR_COUNTSを有す
る。）。これはFIND_EFFCTルーチンは、EXPR_COUNTがMI
N_EXPR_COUNTより少ないかこれに等しいタプルＴに遭遇
すると同時にエフェクト スタックのサーチをショート
カットしうることを意味する。これはＴより深くスタ
ックされているすべてのタプルはEXPR_COUNTSを有する
ことを保証されているからである。 エフェクト スタックの実現あるいは具体化に実際に用
いられるメカニズムは完全にフロント エンド20によっ
て定まり、１つのタプルの実行が、他のタプルによって
計算された値に影響するかしないかのフロント エンド
の決定には、通例の如くのルール（法則）が用いられ
る。繊細なスタックの実現化も可能である。但しこれは
非能率であることが多い。より具体性のある実現化は、
ハッシュ（寄せ集め）テーブルを囲んで構成することで
あり、これによって多数の小スタック（それぞれが１つ
または僅かの変数のみに関連する）を単一の大スタック
の代わりに用いることができる。 次にエフェクト クラス インタフェイスについて説明
する。すべてのエフェクト セットは、エフェクト ク
ラスのセットを表わすビット ベクトルであり、１つの
エフェクト クラスは、メモリ位置のいくつかの任意の
セットを表わすことを想起されたい。典型的にエフェク
ト クラスは次のものの１つを代表する。 1.単一のネームの変数。有効な最適化（例えば非アグレ
ゲートの）のために、ルーチンにおいて頻繁に用いられ
るローカル変数は、これに専用とされたエフェクト ク
ラスを持たせる。 2.いくつかの共通の特性をもったネームのセット、例え
ば、FORTRANでは、特殊のネームの共通ブロック内のす
べての変数。 3.ルーチンの際迄決定されないが、いくつかの共通特性
を有しているメモリ位置のセット、例えば、当該ルーチ
ンの外側では見られるすべてのメモリ位置、（従ってル
ーチン コールによって変化しうるもの）；あるいはパ
スカル（Pascal）においては、特定のタイプを有し、NE
Wコールにダイナミックに割当てられるすべてのメモリ
位置。 リテラルのGEM_SE_K_MAX_EFFECTSはGEM_SEパッケージに
よってエクスポート（輸出）される。これはフロント
エンド20が規定する明確なクラスの最大数である。初期
具体化（インプレメーション）においては、これは128
となる。GEM_SE_EFFECTS_SETタイプはGEM_SEパッケージ
によってエクスポートされる。 BITVECTOR〔GEM_SE_K_MAX_EFFECTS〕に展開するのはマ
クロである。従って宣言（デクラレーション）X:GEM_SE
_EFFECTS_SETでは次の各構成はすべて自然数となる。
（ただし ０≦Ｎ≦GEM_SE_K_MAX_EFFECTS−１）： Ｘ〔Ｎ〕＝真；セットＸにエフェクト クラスＮを加算
！ Ｘ〔Ｎ〕＝誤り；セットＸにエフェクト クラスＮを除
去！ 仮にＸ〔Ｎ〕であると‐‐‐セットＸ内にクラスＮをエ
フェクト！ エフェクト クラス インタフェイスに対するインタフ
ェイス ルーチンについて以下に説明する。フロント
エンド20は次のルーチンの実行を要する。 GEM_SE_EFFECTS（ EIL_TUPLE :イン GEM_TUPLE_NODE EFFECTS_BV:インアウト GEM_SE_EFFECTS_SET） タプルEIL_TUPLEおよびEFFECTS_BVのエフェクトの結合
を次に書込む EFFECTS_BV GEM_SE_DEPENDENCIES（ EIL_TUPLE :を GEM_TUPLE_NODE 内 EFFECTS_BV:インアウト GEM_SE_EFFECTS_SET） EIL_TUPLEがEFFECTS_BVに従属するエフェクト クラス
のセットを次に書込む。 GEM_SE_VARIABIL_DEPENDENCIES（ SYMBOL ：イン GEM_SYMBOL_NODE EFFECTS_BV:アウト GEM_SE_EFFECTS_SET） EFFECTS_BV内に変数SYMBOLに従属するメモリを含むと思
われるエフェクト クラスのセットを書込む。 GEM_SE_EFFECTSはエフェクトを有するタプルのみにより
呼出される。 コンパイラは上述の如きインタフェイス ルーチンに対
する具体化を行なうを要する。しかしこれらのルーチン
は生産（本番）コンパイラ用のものではない。これらは
効率が悪く、１つのタプルが他のタプルを無効にすると
きのルールは如何なる特殊ランゲージの文意とも正確に
は一致しない。しかしこれらは生ずべき、欠陥の有効な
最適化を可能とし、しかもフロント エンド20の他の素
子を具体化する。 各シンボル ノードのEFFECTSフィールドは、32とGEM_S
E_K_MAX_EFFECTSの間でエフェクト クラス番号として
処理される。フェッチまたはストア タプルのアドレス
式がベース シンボルを有するときは、このシンボルの
EFFECTSフィールドをチェックする。もしこれがゼロで
あると、その場合には32とGEM_SE_K_MAX_EFFECTSの間に
新しい値をセットする。 上述のエフェクト クラス具体化を用いるエフェクト
セットの計算には、フロント エンドはGEM_IL_BUILDを
呼ぶ前に、GEM_SE_INIT_EFFECTS_CLASSを呼出す。 このインプレメンテーション（具体化）は、エフェクト
に対し単一のモデルを規定することによってエフェクト
に関する情報を提供する。 1.多数がオーバーレイされていない。 2.データ アクセス演算が正規様式（CT.006で規定され
た）でなく、（メモリに対し）またはエフェクト０（フ
ェッチに対し）に従属する。 3.コール（呼）がエフェクト32よりGEM_SE_K_MAX_EFFEC
TSを有する。ARGADRパラメータは、呼がそのアドレス
オペランド内に書込みを行なったときのように処理され
る。 GEM_SE_K_MAX_EFFECTSを通じるエフェクト クラス０お
よび32がリザーブされるエフェクト０は参照された変数
が識別できない（ポインタ デレファレンス、パラメー
タ等）ときのメモリを表わす。 正規型式のデータ アクセスを用いて変数が第１に表わ
れるときは、この変数は32よりGEM_SE_K_MAX_EFFECTSま
での範囲において、エフェクト クラス番号ｎを割当て
られる。この番号はシンボル ノードのEFFECTSフール
ド内に記録される。このレファレンスの変数およびこれ
の後続のすべてのレファレンス変数はエフェクトまたは
ディペンデンシイｎを有する。 この具体化は実験、試験（テスト）等に対し、いくつか
のフックを含んでいる。 1.エフェクトまたはディペンデンシイを有するであろう
タプルは、フロント エンドにリザーブされており、こ
のタプルのエフェクトおよびディペンデンシイを記録す
る１つ以上の“エフェクト フィールド”（EFFECTS,DE
PENDENCIES,エフェクト−２等）を有する。コンパイラ
・サプライド エフェクト クラスはエフェクト フィ
ールドをコールバックし、GEM_SE_EFFECTS_SETの第１ワ
ードを表わす長さ32のビット ベクトルとする。すなわ
ち、仮にこのフィールドのビットｎが真であると、ルー
チンはタプルによって計算されたエフェクトにエフェク
ト クラスｎを加算する。 2.フロント エンドは、変数のシンボル ノードのエフ
ェクト フィールド内に１とGEM_SE_K_MAX_EFFECTS間の
エフェクト クラス番号を書込むことによって、この変
数に対するエフェクト クラスを選択することができ
る。EFFECTS フィールドがゼロでない場合には、エフ
ェクト クラス ルーチンはエフェクト クラスを割当
てない。 3.エフェクト クラス１ないし32はフロント エンドの
使用のためにリザーブされる。フロント エンドはこれ
らのエフェクト クラスに任意の解釈を割当てることが
できる。 上述の直線ディペンデンシイ具体化に用いるため、フロ
ント エンドはGEM_DF_DATAFLOWフェーズを呼出す前
に、GEM_SE_INIT_EFFECTS_STACKを呼出す必要がある。
このインプレメンテーション（具体化）は、GEM_SE_EFF
ECTSおよびGEM_SE_DEPENDENCIESにより形成される情報
を使用し、無効の決定のためのコール バックを行な
う。すなわち、GEM_SE_FIND_EFFECTS（Ｘ）はもっとも
最近に押出されたタプルＹにリターンし、GEM_SE_EFFEC
TS（Ｙ）とGEM_SE_DEPENDENCIES（Ｘ）との交差点が非
ゼロである如くする。 誘導変数 本発明の一特徴として、コンパイラの中における誘導変
数の改良した処理方法がある。第一に、誘導変数の定義
及び検出について説明する。 整数の変数Ｖは次のような場合、即ちループＬ内に生ず
るＶの各メモリーが次の条件の場合にループＬの誘導変
数と称する： 1.実行される各時間においてインクレメント（又はディ
クレメント）Ｖが同じ量の場合。 2.ループを通じて各“完全トリップ”内で最大で１回実
行される時、トリップはこれがループのトップにフロー
バックするときに“完全（コンプリート）と称する。 例えば、次のコードは、誘導変数Ｖを表すものである。 ラベルＬ Ｖ＝１ IF Ｖ＞10 GOTO LABEL M ELSE PRINT X END IF コンパイル（翻訳）機能において誘導変数の発見に加え
て我々は、誘導式（エクスプレッション）にも関心をも
っている。誘導エクスプレッションとは、誘導変数の直
線関数として計算できるエクスプレッションを称する。 次のプログラムについて考えてみる。 DOI＝1,100 Ｘ＝I^*8 Ｔ＝Ｉ−４ Ａ〔Ｉ〕＝T^*4 END DO エクスプレッション“Ｉ＊8",“Ｉ−4"“T"及び“Ｔ＊
4"は、いずれもＩの誘導関数として再計算できるので全
てが誘導エクスプレッションである。 誘導変数に基づいて最適化の例として次のごとくの例を
考える。 Ｉ＝1; L: Ｘ＝Ｘ＋（4^*I） Ｉ＝Ｉ＋１ ただし I＜＝100GOTO L これはDOループのそれ自体であり、Ｉはループ制御変数
である。誘導エクスプレッションＩ＊４はループを通ず
る各１回のトリップごとに４だけ増加することに留意さ
れたい。新しい変数I2を導入することにより、倍算を加
算によって置き換えることができ、これはより安価な演
算である。これは、長い間にわたりコンパイラを最適化
するのに用いられた強度減少として知られた最適化であ
る。 Ｉ＝1; I2＝4; L: Ｘ＝Ｘ＋I2 Ｉ＝Ｉ＋１ I2＝I2＋４ ただし I＜＝100GOTO L ここにおいて我々は、２つの変数（Ｉ及びI2）を有して
いるが、このうち１つのみを使用していた。I2の代わり
にＩの使用に再注目することによって、オリジナルのル
ープ制御変数を完全に消去することがきる。 I2＝4; L: Ｘ＝Ｘ＋I2 I2＝I2＋４ ただし I＜＝400GOTO L この最適化は誘導変数消去として知られている。 この最適化（強度減少及び誘導変数消去）は、誘導変数
に直接動作する。これらの最適化に加えて誘導変数検出
は、他の最適化、例えば、自動インク／デック（inc/de
c）、ベクトル化、ループ反ローリング等に対し、情報
を形成する。 第１図のコンパイラに使用されるモデルにおいて誘導変
数は、ループ中に１回以上インクレメントされる。更
に、変化の数は、各繰り返しに対し、異なるようにする
ことさえもできる。実際上も、特種な繰り返しに対して
は変化の数をゼロとするこもできる。ループの不変量の
インクレメント値は、各個別メモリーにより異なること
もあるが、各個別メモリーは、実行されるごとに必ず同
じ量だけ変化をインクレメントする必要がある。 誘導変数にはいくつかの異なるカテゴリーが存し、これ
らは異なった特性をもっており、基本的誘導変数、誘導
エクスプレッション、疑似誘導変数を含んでいる。 基本的誘導変数は、誘導変数の最も簡単な形態である。
これらは、ループ全体を通じて適用される既知の特性を
有している。他の総ての誘導変数及びエクスプレッショ
ンは、基本的誘導変数の直線関数として常に構成され
る。基本的誘導関数は、一般にＩ＝Ｉ＋ｑ又はＩ＝Ｉ−
ｑの形態で変形され、ここにおいて“q"はループ不変量
である。しかしより一般的な要求は、Ｉ＝ｆ（Ｉ）の形
を当てはめることである。ここで、ｆ（Ｉ）は係数Ｉを
もった１の直線関数である。 付属書内に示されたアルゴリズムにおいて特定のループ
の基本的誘導変数は、ループ トップ内のセットして表
されている。このセットに加えてループを通ずる各トリ
ップごとには実行されないこともある条件付メモリであ
る基本的誘導変数をも存在している。これはベクトル化
を禁止し、より“好ましく”強度減少を行い得る。 誘導エクスプレッションとは、誘導変数又は他の誘導エ
クスプレッションの直線関数を意味する。誘導エクスプ
レッションは、次の形態のいずれかである。 −ｆ（Ｉ） ｆ（Ｉ）＋ｇ（Ｉ） ｆ（Ｉ）−ｇ（Ｉ） ｆ（Ｉ）＋Ｅ Ｅ＋ｆ（Ｉ） ｆ（Ｉ）−Ｅ Ｅ−ｆ（Ｉ） ｆ（Ｉ）^*E E^*f（Ｉ） ここでｆ（Ｉ）及びｇ（Ｉ）は、ループＬに関する基本
的誘導変数より導かれ、またＥはループＬ内の不変量で
ある。ｆ（Ｉ）とこれがオペランドであるアリスメティ
ック オペレータ（算術的演算子）の間にメモリがない
場合は、このアリスマティックオペレータはループＬに
関する基本的誘導変数Ｉより導かれる誘導エクスプレッ
ションである。 他のカテゴリーは疑似誘導変数である。ある特定の条件
においては、変数は、ループを通ずる第１トリップ以外
の総てにおいて誘導変数のごとき特徴を呈する。これら
は、ループの第１繰り返しをピール（はがす）すること
により誘導変数（したがって、ベクトル化）に変形でき
る。このような変形を“疑似誘導変数”と称する。これ
は、２つのみのメモリによってループ内でフェッチに到
達し、これら２つのメモリのうちの１つは導出誘導変数
を規定するものであり、他のメモリは、ループ トップ
を通じて値が通過するものであるときに生ずる。追加的
にループ内の総てのメモリーは、トリップ当たりに１回
ずつ実行されることを保証しなければならない。 例えば、 Ｄ＝50 DOI＝1,n Ａ〔Ｉ〕＝Ｄ＋‐‐‐ Ａ＝１＋４ ループを通ずる第１トリップにおいて、ＤはＩに割り当
てた値として50を有する。次のトリップにおいてＤは、
値５、６、７を有する。このループを１回アンロールす
ることにより次のトリップをベクトル化することができ
る。ここにおいて得られるアルゴリズムは疑似誘導変数
である誘導変数を見いだせない。 基本的誘導変数を識別するため、コンパイラはこれに対
する総てのメモリを認識し得る必要がある。“エイリア
ス（別名）メモリを有する”の欠如はこれの保証に貢献
し、したがって、“エイリアスメモリ有り”のない基本
的誘導変数のみを識別すればよい。 基本的誘導変数の検出は、ポテンシャル誘導変数の“セ
ット”の使用を必要とする。各ループに対し、これをダ
イナミック的に行うのは高価でありかつ複雑な演算とな
る。これに代えてIDEFセットの構成に用いられているサ
イド エフェクト セットを使用する。 Ｘのフェッチがこれに応じて定まる総てのエフェクトが
Ｓ内にある場合、変数“X"はIDEFセットＳ“内”と称す
る。即ち、GET_VARIABLE_DEPENDENCIES（ｘ）がＳのサ
ブセットである場合のみ、Ｘは、IDEFセット内である。 基本的誘導セット内におけるＸの存在は、次の場合にの
みあてはまる。 ａ）Ｘが基本的誘導変数である。 ｂ）Ｘがループ不変数であり、基本的誘導変数である少
なくとも１つの変数をもったIDEFビットをシェアすると
き。 付属書内に記載したアルゴリズムの説明は、その説明を
簡単にするため、次のごとく（あるいはこれより多くの
省略を設けた）： （１）直線関数の定数部分の集合はオーバーフローを生
じ得ない。（２）総てのメモリは、変数を完全に再規定
し得ること。 付属書内に説明されているアルゴリズムはループ内で変
形される総ての変数は基本的誘導変数とみなしている。
各ループ トップは基本的誘導変数を有する。基本的誘
導変数に対する要求を満足しないメモリも有り得るの
で、ループ トップの基本的IVセットより変数を消去す
る。 誘導エクスプレッション及び導出された誘導変数は、常
に基本的IVの関数であるため、基本的IV（誘導変数）の
フェッチは誘導エクスプレッションの原子的形態である
といい得る。即ち、誘導特性をもつべきエクスプレッシ
ョンに対しては、これは誘導オペランドであるか或は基
本的誘導変数のフェッチである。前に述べたルールを用
いて、基本的IVに関する推定に基づき、簡単な誘導エク
スプレッションより誘導エクスプレッションを構成す
る。誘導エクスプレッションの基本的IVは、常にこのエ
クスプレッション（式中）に保持されている。従って、
アルゴリズムが経過した後、我々は、エクスプレッショ
ンが実際に誘導的であったか否かをこれを導出した基本
的IVがループの基本的IVセット内に依然として存するか
否かをチェックすることにより真の誘導的であるか否か
を決定できる。 付属書内に述べたFIND_IVアルゴリズムは、DATAFLOWフ
ェーズの一部となりこれは第１ドミネータのスリーウォ
ークの深部となる。 これで行われるタプル プロセスの全体の要約を示す。 TUPLE［OPCODE］ ［FETCH］ ベースシンボルが依然としてIVベース キャンディデー
トの場合 このタプルをインダクティブ（誘導性）としてマークす
る。 ［STORE］ Ｖをメモリのベースシンボルとする。 蓄積される値が誘導性でないか或は、 蓄積される誘導値の基本的IVがＶでないか又は 蓄積値の係数が１でない場合、 ループ トップの基本的IVよりＶを除去 次いで、 ループ トップの基本的IVよりＶを除去、 次いで、 メモリを誘導的とマークする。 ［ADD,SUB,MUL,など］ １つのオペランドがインダクティブであり、他のオペラ
ンドがループ不変性である場合には、このタプルを誘導
的とマークする。 このフィールドをタプルデータ構造に加算し、更に、こ
のフィールドをフロー ノードに加算し、誘導変数検出
をこれによって表6aに述べるごとくして行う。 KFOLD （Ｋ倍）ROUTINEの自動形成 前述のごとく、第１図のプログラミング ランゲージ
コンパイラはソース ランゲージ内に書き込まれている
プログラムをターゲット マシン25のマシン ランゲー
ジに翻訳する。このコンパイラは、フロント エンド20
を有し、これは、ソース ランゲージの知識を翻訳すべ
きモジュール21内に導入し、更にバック エンド12を有
し、これは、ターゲット マシン25のマシン ランゲー
ジの知識を内蔵する。フロント エンドは、ソース ラ
ンゲージのプログラムをILG 55の中間ランゲージに翻訳
し、バック エンドは、中間ランゲージよりのプログラ
ムをターゲット マシン ランゲージのプログラムに翻
訳する。 中間ランゲージは一般にオペレータ（“演算子”例え
ば、add,,shift,compare,fetch,store又はtangent）の
収集を行い、またデータ タイプ（“サイン付き32ビッ
ト整数”、“IEEE S-format floating point"又は“cha
racter string"など）の収集を行い、かつ、これらデー
タ タイプの値のリプレゼンテーション（表示）を行
う。 オプティマイザ（最適化装置）26に含まれる最適化の１
つは評価ルーチンのコンスタントの表示である。コンス
タント表示（エクスプレッション）に関するソース コ
ード リスティング（表）の１例は第６図に示してあ
り、ここにおいてＡ及びＢは定数であり、したがって、
Ａ＋Ｂも定数であり、またＩ及びＪは両方とも同じ定数
に等しい。コンパイラは計算Ａ＋Ｂを行うことができ、
また、ラン タイム（運転時間）においてＡ及びＢのフ
ェッチを個別に制御し、更に、ADD演算のセーブもこれ
と同時に行う。第６図の符号のＩ＝Ａ＋Ｂ及びＪ＝Ａ＋
Ｂの式は、上の理由により両方とも単にSTOR＃９、Ｉ又
はSTORE＃９、Ｊで代表される。これは“コンスタント
ホールディング”として知られており、それは、コン
スタント即ち定数が検出され、翻訳時間中に計算され、
かつ、オブジェクト コード イメージ中に“ホールデ
ィド（折り込み）”されるからである。これを行う機構
は、Ｋホルド ルーチンと称されるオプティマイザ26の
一部である。 第１図のコンパイラは、これらの定数表示を発見するた
め、中間ランゲージのエクスプレッションを評価するＫ
ホルド ルーチンを有している。一般に、中間ランゲー
ジの演算子が与えられ、かつそのオペランド値が与えら
れると、このルーチンは、これらの値に対し、割り当て
られた演算子によって計算される同じ値に対し、劣勢
（弱い値‐‐‐イールド）となる。このような定数式評
価ルーチンは、コンパイラ内で多くの用途を有する。 例えば次のごとくである。 （ａ）プログラムに対し発生されたマシン コードの実
行速度は、プログラムのある式がコンパイラ自体で評価
し得るときは、そのプログラムが実行されるときよりも
改良される。 （ｂ）いくつかのソース ランゲージは、一定値を表す
のに一定のオペランドをもった式を使用することを可能
とする。このようなランゲージの翻訳には、コンパイラ
によりこのような式を評価するを要する。 （ｃ）中間ランゲージ内に設けられた演算のレパートリ
ーがプログラム ランゲージによって設けられた演算の
セットよりもリッチであるか又はコンパイラが使用され
る環境に比してリッチである場合には、このコンパイラ
内で幾つかの計算を遂行する最も便利な途は、これを中
間ランゲージ内で表し、かつこれを定数エクスプレッシ
ョン評価ルーチンに提出することである。 定常エクスプレッション評価ルーティンの実行はかなり
困難な仕事かも知れない。ILには、10以上の演算（例え
ばADD,SUBT,COSINE,等々）があり得ようし、異なるデー
タ タイプを考えるときには（例えばINT32,NINT64,FLO
ATA,等々）、中間言語は数百ないし数千の演算子を持つ
こともあろう。評価器は、コンパイラがその機能を完全
に若しくは正確に実行するのを失敗しないように、各演
算を各データ タイプに正確に適用できるようになって
いなければならない。特に、浮動少数点タイプが係わっ
ているときには、中間言語で表すことのできるすべての
演算がコンパイラの実行するプログラム用言語に直接通
用するとは必ずしも云えないであろう。その結果、定常
エクスプレッション評価ルーチンは、数百に及ぶ異なっ
た場合を含み極端に長くなりがちで、高度に誤り易い傾
向がある。 本発明の１つの実施例の重要な性質に従えば、中間言語
の演算子の正確な意味が常に簡潔且つ正確に特定できる
言語はその中間言語それ自身であるという難点がある。
換言すれば、コンパイラのバック エンドそれ自身が中
間言語の任意の演算子を正確に実行する符号を生成する
能力を持たなければならない。更に別の云い方をすれ
ば、これは、コンパイラのバック エンドが各中間言語
の効果を実現するのに必要な一連の機械語の命令の知識
を既に具現しており、定常エクスプレッション評価ルー
ティン中でこの同じ知識を再び異なる形で符号化しなけ
ればならないのは冗長であろう、というのである。 この概念に基づき本発明に従えば、定常エクスプレッシ
ョン評価ルーティンの機械的な生成は簡明なものとな
る：最初のステップは、正常のコンパイラとして同じバ
ック エンド12を使うが、そのフロント エンド20は下
記の特殊なフロント エンドと置き換える図１の新しい
コンパイラを創生することである。（下記のように演算
するコンパイラ用の特殊モードを具える、と云うのと等
価である。） ２番目には、特殊のフロント エンド20又は特殊の演算
モードは、ソース プログラム21を読み出し且つ翻訳す
ることはしない。その代わりに、それは定常エクスプレ
ッション評価ルーティン用の中間言語を次のように生成
する： （ａ）このルーティンは仮数リスト中で特定される中間
言語演算子に基づき場合を選択する条件付分枝を実行す
る。 （ｂ）各場合は単一演算子用の符号を含む。それは被演
算値をルーティンの仮数リストからフェッチし、演算子
をそれらに適用し、結果を返す。 （ｃ）ルーティンは中間言語中で直接に生成されている
から、各場合用の符号は単に、被演算子を仮数リストか
らフェッチする中間言語演算子と、その次のこの特定の
場合用の中間言語演算子と、さらにその次の結果を返す
ための中間言語演算子とから成る。 ３番目には、この中間言語のグラフがコンパイラのバッ
クエンドに服従し、定常エクスプレッション評価ルーテ
ィンのための機械符号を生成するであろう。 いま述べた特殊のフロント エンドでは、それに対して
場合が生成されなければならず、各場合用に中間言語を
機械的に生成できるすべての演算子のリストを、フロン
ト エンドが含むことができる。 しかし、しばしば生起するように、もしコンパイラのバ
ック エンドが演算子情報のテーブルを含むならば、処
理は更に簡単化することができる。（例えば、そのよう
なテーブルは、フロント エンドにより生成された中間
言語のグラフの正確さをチェックするのに用いることが
できる。）すると、特殊のフロント エンドにとって、
どの場合が生成されるべきかを定めるために既にバック
エンドにより設けられているこのテーブルを使うこと
が可能になる。 タイプの定義 図１のコンパイラはGEM_TDと呼ばれるタイプ定義モジュ
ールを使う。GEM_TDは、リンカー又はデバッガーにより
用いられるオブジェクト モジュールに入っているプロ
グラム タイプ型の情報を構築するのにフロント エン
ド20及びバック エンド12により使用されるメカニズム
を具えている。このタイプ特定化サービスは、プログラ
ム シンボル及びそれに付随するタイプ情報を、ターゲ
ット オブジェクト ファイル要求とは独立のやり方
で、オブジェクト モジュール ビルダー29に記述する
ことをフロント エンド20に許容することが意図されて
いる。このタイプ特定化サービスは、手続き的な「タイ
プの文法」として行動し、それによりコンパイラは抽象
タイプ特定化及びプログラム シンボルに関連させるこ
とができる。タイプ特定化インタフェースが以下に定義
され、GEM_TDサービスの使用の多数の実例が引用され
る。 タイプ情報の創生はシンボル テーブル30との関係で生
じ、フロント エンド20にプログラム タイプ情報の抽
象表現を特定することを許容する。オブジェクト モジ
ュール ビルダー29は後にこの情報をデバッグ シンボ
ル テーブル情報を構築するのに用いるであろう。 GEM_TDモジュールはフロント エンド20に基礎タイプ及
び派生タイプを記述することを許容するサービス ルー
ティンを具える。これらのルーティンは特定化されたタ
イプ情報を記述する内部データ構造を典型的に構築す
る。新しいコンパイラ ノード タイプGEM_TDIは、こ
のタイプ情報を管理するために定義されよう。タイプ
ノード データ構造はコンパイラ12に対して非公開であ
り、フロント エンド20によって変えたり検討したりさ
れることはできない。タイプを定義するときフロント
エンド20はタイプを定義するGEM_TDルーティンによって
「ハンドル」がタイプ ノードに戻される。ハンドルは
フロント エンドにプログラム シンボルを持つタイプ
と連携することを許容するが、データ構造のフィールド
を変えたり検討したりすることは禁止する。 タイプ ノードはスコープにより創生され、管理される
であろう、すなわちタイプ情報を送るときにフロント
エンド20はタイプがその内部で宣言されるべきブロック
ノードを特定するであろう、またシェルは該スコープ
の内部におけるタイプ ノードの管理に対し責任を持つ
であろう。シェルは、その中でタイプが定義されている
ブロック ノードに根ざすリスト中のタイプ ノードを
管理するであろう。ブロック ノード データ構造は、
フィールドTYPE_LIST_HEAD及びTYPE_LIST_TAILを定義す
るために拡張されよう。 フロント エンド20は、タイプ特定サービス ルーティ
ンにオン ザ フライ呼を発することを選択してもよい
し又はタイプ情報を生成するために全シンボル テーブ
ルをパスオーバーすることを選択してもよい。 タイプを定義した後、フロント エンドはこのタイプ情
報をそのタイプのシンボルに連携させなければならな
い。シンボル ノードは、シンボルをそのタイプに連携
させるのに使われた新しいフィールドDST_TYPE_INFOを
持つであろう。シンボルのDST_TYPE_INFOフィールド
は、GEM_TDサービスにより返されたタイプ ノード ハ
ンドルのアドレスを含むであろう。DST_TYPE_INFO値が
０のシンボル ノードは、タイプ情報を持たないシンボ
ルのためのターゲット特定行動様式を持つであろう。 図７を見れば、関数： int toy_procl） ｛ float b,c; : ｝ に対するデータ フィールド及び相互関係が説明されて
いる。 toy-proc用のブロック ノード60は、シンボル テーブ
ル30中の、エントリー63,64及び65を指し示すフィール
ド61及び62（declリスト ポインター）を含む。またそ
れはintとfloat用にタイプ リストのエントリー68及び
69を指し示すタイプ リスト ポインターとして機能す
るフィールド66及び67を含む。エントリー63,64及び65
はまた、それが成り立つ場合はintとfloat用のエントリ
ー68及び69を指し示すポインター70,71及び72をも持っ
ている。 GEM_TDタイプ特定サービスは、フロント エンド20に標
準及び派生タイプを定義することを許容し、これらのタ
イプをプログラム シンボルに連携させるルーティンか
ら成る。コンパイラのバック エンド12はこの結果であ
るタイプの定義とそれらのシンボル ノードとの連携を
用いてターゲットを特定したデバック シンボル テー
ブルを生成する。ブール代数の記法は基礎タイプとは考
えられていないことに注意されたい。パスカル（Pasca
l）のような言語用のコンパイラは真及び偽のエレメン
トを含む列挙としてブール代数の記法を定義しなければ
ならない。 マルチパス符号生成器用の行動言語 バック エンド12中で符号生成器29による符号テンプレ
ートを用いる符号生成を成す方法が以下に記述される。
符号テンプレートの選択及び適用はコンパイラ過程中で
４回生じる。 1.PATSELECT相は最良の符号テンプレートを選択するた
めにCONTEXTパス中にパターン整合をとる。（パターン
整合中にUCOMP及びDELAY最適化タスクがパターン整合過
程の一部として平行して為される。） 2.CONTEXTパス中のTNASSIGN及びTNLIFEタスクは、選択
されたテンプレートのコンテキスト行動（アクション）
を用いてエクスプレッション（式）への評価命令を解析
し、非局所生涯を持つTNを符号テンプレートに割り当て
る。 3.TNBINDパスは、選択されたテンプレートのバインディ
ング行動を用いて局所生涯を持つTNを符号テンプレート
に割り当てる。 4.最後に、CODEパスは、選択されたテンプレートの符号
生成行動を用いてオブジェクト符号語の生成を誘導す
る。 テンプレートはコンパイラ過程中で様々な回数に亙り用
いられる。これは３つの主要なコンポネントから成る： 1.ILGパターン−テンプレートに整合するテンプレート
選択過程を適用可能なILG構造に誘導する。 2.遅延しない行動−整合したILG構造の処理をCONTEXTパ
ス、TNBINDパス及びCODEパス中に決定する。遅延しない
行動はテンプレートが各パス中で最初に処理されるとき
実行される。その結果、各ILGノードに対するテンプレ
ート行動は、各パスで１回宛計３回処理される。行動の
うちのあるものは、１つのパスに対してのみ意味を持
ち、その他のパスでは無視される。その他の行動は１つ
より多いパスで意味を持つが、各パスでで要求される処
理はそれぞれ異なる。 3.遅延する行動−この場合にも整合したILG構造の処理
をCONTEXTパス、TNBINDパス及びCODEパス中に決定す
る。遅延する行動は、テンプレートにより計算された結
果が他のテンプレートの葉（leaf）として最初に処理さ
れるとき各パスを実行する。遅延する行動は、アドレス
モードを持つVAXのようなターゲット機械上では有益
である。RISCのような単純なレジスタ機械は恐らく遅延
する行動を重く用いないであろう。 コード発生テンプレートのILGパターンは次の４つの情
報から成る。 1.テンプレート発生コードにより計算された値の表現を
エンコードする結果値モード（後記の付録に記載した種
々の実施例参照）。 2.このテンプレートにより符号化し得るILGノードの配
列を記述するパターンツリー。パターン ツリーの内部
ノードはILオペレータであり、パターン ツリーの枝葉
は値モードセットか、オペランドを持たないILオペレー
タの何れかである。 3.ブール テストのシーケンス。これらテストの全ては
適用し得るパターンについて順序正しく評価する必要が
ある。 4.このテンプレートで発声されたコードの“コスト”を
表わす整数。 パターン又はPATSELECTフェーズはテンプレートのパタ
ーンを有するILGサブツリーを照合する。２以上のテン
プレートパターンを一つのILGノードで適用し得る場合
は、パターン照合器はどのパターンが最低推定コード
コストになるか知るまで択一的テンプレート間の選択を
遅らせる。 ３つの異なるアクション インタプリータ、即ち、CONT
EXTインタプリータ、TNBINDインタプリータ及びCODEイ
ンタプリータがある。各テンプレータのアクションは適
正なインタプリータによりコンパイラの３つの異なるパ
ス内で実行される。同一のテンプレートがこれら３つの
全パス内で使用されるが、アクションの意味はフェーズ
依存であって各パスで異なることが行われる。多くのア
クションは３つのパスのうちの一つのみに意義があり、
他の２つのパスには関係ない。他のアクションは２つ以
上のパスに意義があるが、一つのパスにおけるアクショ
ンの意味は、しばしば異なるパスにおける同一のアクシ
ョンの意味と著しく相違する。しかし、テンプレート内
に１つのアクション シーケンスを有するだけにすると
種々のパス間の従属性を理解し維持することが極めて容
易になる。 各テンプレートに対するアクション シーケンスは２部
分、即ち非遅延アクション及び遅延アクションから成
る。選択されたILGノードのパターンが最初に処理され
るときは非遅延アクションがインタプリートされる。IL
Gパターンが別のILGパターンの枝葉として後に使用され
るときは遅延アクションがインタプリートされる。 非遅延アクションのインタプリートの開始時に、オペラ
ンド変数のテーブルが生起される。オペランド変数はテ
ンポラリネーム（TN）、リテラル又はターゲット スペ
シフィック アドレス モードを含むことができる。 各テンポラリネームは３つのクラス、即ち（１）永久T
N、（２）遅延TN及び（３）ローカルTNはその寿命（生
涯）及び使用法により決まる。 各TNは割当寿命を有する必要がある。割当寿命は適正な
テンプレート アクションにより開始され、TNの最終使
用に至る全フローパスに沿って及ぶ。永久クラスのTNは
そのTNの生起後の将来において任意多量のコードを終了
させる寿命を有することができる。遅延クラスの寿命
は、そのTNが枝葉として使用されるときその短時間後に
テンプレートの遅延アクションを開始させ終了させる必
要がある。ローカルTNの寿命は決して単一パターンのイ
ンタプリテーションを越えない。 TNのクラスはそれがどのように処理されるかを決定す
る。永久クラスTNはCONTEXTパスにおいて１回生起さ
れ、全３個のパスに亘って同一のTNデータ構造が維持さ
れ、これがTNの複雑な寿命記述をストアするのに使用さ
れる。遅延クラスTN及びローカル クラスTNは極めて制
限された持続時間の寿命を有するため、これらTNはこの
情報を追跡するのに永久データ構造を必要としない。こ
の結果、遅延クラスTN及びローカルクラスTN用のTNデー
タ構造はアクションをインタプリートする際に各パスご
とに構成され、各パスにおけるそれらの最終使用直後に
消去される。各パスにおける同一のアクション シーケ
ンスをインタプリートすることにより、これらクラスの
TNに対し各パスごとに同一のTNデータ構造を構成するこ
とが保証される。 種々のテンプレート アクションの大きなリストがあ
る。これらアクションのいくつかはターゲット マシー
ン従属である。後記の付録には提案の又は一例のテンプ
レート アクションリストを含めてあるので、ユーザは
これらのコード テンプレート例を用いて特定の実施例
に対し必要な事項を決定することができる。 中間言語表現 図１のコンパイラ フレーム ワーク10に使用する内部
表現はシンボル テーブル30及び中間言語グラフ55を具
え、これらはソース モジュール21の構造データ及びコ
ードを表わすために、フロントエンド20により発生され
るデータ構造である。以下に、シンボル テーブル30及
びILグラフ55に使用する中間言語の仕様を含むこれらデ
ータ構造の基本要素であるノードについて説明する。図
１につき説明するコンパイラでは、フロント エンド20
が、ソース モジュール21に含まれるプログラムのブロ
ック、ルーチン、変数リテラル値等を記述するためにシ
ンボル テーブル30を発生すると共に、実行可能コード
を記述するために１以上の中間言語グラフ55を発生す
る。これらの内部データ構造について以下に説明する。 一般に図１のコンパイラ、特にその中間言語及びシンボ
ル テーブルの設計はVAXのような「コンプレックス
インストラクション セット コンピュータ（CISC）」
からPRISM,MIPS（32ビット マシーン）のような「レデ
ュースト インストラクション セット コンピュータ
（RISC）」又はアドバンスト64ビットRISCアーキテクチ
ャまでの種々のアーキテクチャをアドレスするようにす
る。この設計はターゲット マシーン25のアーキテクチ
ャが所定の基本特徴を有するものと仮定する。最初に、
バイト構成及びアドレサビリティを仮定すると共に“リ
トル インディアン”ビット オーダリングを用いる２
の補数２進演算を仮定する。更に“正当”アドレス表
現、即ちレジスタにフィットするアドレスも仮定する。 一般に、フロント エンド20はプログラムの中間表現を
生成する際にターゲット アーキテクチャの詳細につい
て知らなくてよい。中間表現の殆どの構成はターゲット
アーキテクチャ25と無関係の明確な意味を有する。し
かし、フロント エンド20を実現するには解決しなけれ
ばならないいくつかの問題がある。第１に、以下に説明
するように全てのデータ タイプが全てのアーキテクチ
ャに使用できるわけではない。第２に、以下に説明する
ように演算オーバフロー動作及び“小整数”演算の表現
が異なるアーキテクチャごとに変化することがある。第
３にいくつかのオペレータ（例えば演算シフト オペレ
ータ）の動作がオペランド値のサブ レンジに対し決め
られ、これらサブ レンジに対し基本マシーン命令が個
々のアーキテクチャごとに決められている。この指定さ
れたレンジ外のオペランド値に対してはこのようなオペ
レータは任意の特定のマシーンに対し良好に動作する
が、異なるマシーンには異なる動作をすることがある。
最後に呼出し規定がターゲット システム25ごとに異な
り、フロント エンド20が場合により同一のソース言語
構成に対し異なる中間表現を発生することが要求され
る。 ここで、「中間言語」とは実行可能コードを指定するア
ブストラクト（抽象）言語を意味する。「中間言語グラ
フ」（LEG）55はこの言語で記述された特定のプログラ
ムである。 グラフ55内の中間言語は実際はメモリ内のデータ構造の
言語であり、構文構造を与えるポインタを有する。しか
し、デバッグ援助としてコンパイラにより書かれるILダ
ンプに対し使用されるILGのための近似テキスト表現も
ある。 ILの基本コンセプトは図４につき上述したタプルにあ
り、ILG55は実行すべきオペレーションを表わすタプル3
5から成る。これらタプルは種々の関係を表わすポイン
タ（例えばオペランド ポインタ38）により互いに結ば
れる。最も重要な関係はオペレーターオペランド関係
（オペレータからそのオペランドの各々へのポインタ3
8）及びILGの各基本ブロック内の全てのタプルの線形順
序であり、この線形順序は公称実行順序を与える。この
線形順序はブロック内のタプル番号40及びルーチン又は
モジュールの全てのブロックをリンクするポインタによ
り表わされる。 ILG55により定義される計算は次の通りである。 （１）ILGのBEGINタプルにおいてスタートする。 （２）各タプルを線形順序で評価する。即ち、そのオペ
ランドの保管結果をフェッチし、その結果を計算及び保
管し、この結果に対し定義し得る任意の二次アクション
を実行する。（この簡単な評価規則には“フロー ブー
リアン”及び“条件付き選択”オペレータに対し例外が
ある。） （３）分岐タプルの評価後にこの分岐タプルにより選択
されたラベルタプルにおいて評価を続ける。 これらの規則はILGグラフ55の「意味」を定めるものと
理解されたい。コード発生器29はILGにより支持される
アクションを、それらの従属性を保存する限り、次の規
則に従って再配列することが許される。 （１）ILG55がエクスプレッション（式）を含むと共に
ステートメントを含み、その実行がこのエクスプレッシ
ョンを評価することにより計算された値に影響を与える
かもしれない場合には、このエクスプレッションに対す
る発生コード及びこのステートメントに対する発生コー
ドはこのステートメントとエクスプレッションがILGに
発生した順序と同一の順序で実行しなければならない。 （２）ILG55が、２つのステートメントを含み、それら
の実行がある共通のエクスプレッションを評価すること
により計算される値に影響を与えるかもしれない場合に
は、この２つのステートメントに対する発生コードをこ
の２つのステートメントがILGに発生した順序と同一の
順序で実行しなければならない。 ステートメントの実行がエクスプレッションの評価によ
り計算される値に影響を与えるかもしれない場合の問題
は以下に記載するサイド エフェクト ヌカニズムを参
照して解決される。 フロント エンド20により構成されるILG55はバックエ
ンド12により処理されるILGと同一でない。フロント
エンド20はコンパクトILグラフ（CILG）を発生するが、
バック エンド12は拡張ILグラフ（EILG）を処理する。
バック エンド12がルーチン用コードを発生するとき
は、これが最初にすることはこのルーチンのCILGをEILG
に拡張することである。両形態のグラフの間にはいくつ
かの差異がある。第１に、CILは“速記”タプルを提供
し、これらタプルはEILの低レベル タプルのシーケン
スに拡張される。第２に、EILタプルを表わすノードはC
ILタプルを表わすノードより多くのフィールドを有す
る。追加のフィールドは、バック エンド12により使用
される情報を含むが、この情報はCILノード内のフィー
ルドからIL拡張器により計算することができる。第３
に、CILGとEILGとには異なる構造的制約がある。この記
載はコンパクトILに向けられているが、この情報は一般
にCIL及びEILの両方にあてはまる。 シンボル テーブル30の構造はコンパイル中のモジュー
ル21の構造を表わす。テーブル30の中心はブロックを表
わすブロック ノードのツリー、及びモジュール21の語
い範囲であり、ツリー構造はそれらのネスティング関係
を表わす。各ブロック内に宣言されているシンボル ノ
ードのリストは各ブロック ノードと関連する。シンボ
ルノードは変数、ラベル又はエントリ ポイントのよう
なモジュール内のシンボリック エンティティを表わ
す。コンパイル中の定数値はリテラル ノードで表わさ
れる。リテラル ノードはシンボル テーブル30及びIL
G55の双方から参照することができる。タームリテラル
テーブルはコンパイル中に生起した全てのリテラル
ノードの集合体を参照するのにも用いられる。フレーム
ノードはコード及びデータを割当てることができる記
憶区域を表わす。一般に、これらノードはルーチンのス
タック フレーム又はPSECTの何れかである。パラメー
タ ノードはパラメータ リストを作成するのに使用さ
れ、これらリストはエントリ ポイント シンボルと関
連する。各パラメータ ノードはルーチン内のパラメー
タ シンボルをエントリ ポイントのアーキテクチャ内
の位置と関連させる。 データタイプ グラフ55で使用される中間表現はアブストラクト マシ
ーン25に対するプログラムを記述し、このプログラムは
下記のリストに記述する小セットのデータ タイプを有
するのみである。これらデータタイプはフロント エン
ド20にのみ関連するモジュール21のソース言語のデータ
タイプと相違する。各ターゲット マシーン25に対
し、各ソース言語データ タイプを表わすのに使用する
データ タイプを決定するのはフロント エンド20の応
答性である。 データタイプ ヌル リプレゼンテーショナル スカラ アドレス 符号付き整数 無符号整数 不動小数点 複素数 ブール値 ヌルデータ タイプは特殊データ タイプで、値を計算
しないタプルのタイプである。リプレゼンテーショナル
データ タイプは、その値がターゲット マシーン
アーキテクチャに固有の表現を有するタイプである。ス
カラデータ タイプは、少数の固定数のメモリ位置又は
レジスタで表わすことができる値を有するものである。
スカラデータ タイプはアドレス データ タイプ及び
演算データ タイプに細分される。演算タイプは適当数
のビットにフィットし得るもの以外の他の任意の種類の
データを表わすのに使用することもできる点に注意され
たい。特に、ソース言語キャラクタ（文字）及び論理デ
ータタイプは整数データ タイプで表わす必要がある。
単一アドレス データ タイプADDRがある。タイプADDR
の値は32又は64ビットの２進整数として表わされる。 符号付きデータ タイプINT8,INT16,INT32及びINT64が
あり、ここでタイプINT^x-1の値はｘ−１ビットの符号付
き２進整数として表わされ、従ってこの値は‐‐
（2^x-1）‐‐‐‐（2^x-1−１）の範囲になる。タイプIN
T8はIBYTEと称することもできる。タイプINT16はIWORD
と称すこともできる。INT32はILONGと称すこともでき
る。タイプINT64はIQUADと称すこともできる。アドレス
として同数のビットを有する整数タイプはIADDRと称す
こともできる。ターゲット アーキテクチャに対しサポ
ートされる最大符号付き整数タイプ（INT32又はINT64）
はIMAXと称すこともできる。任意の２進スケーリング
（PL/Iにおけるような）をフロント エンドにより提供
する必要があり、スケールド バイナリ データ タイ
プに対するIL規定はない。 無符号整数データ タイプUINT8,UINT16,UINT32及びUIN
T64があり、ここでタイプUINT^x-1の値はｘ−１ビットの
無符号２進整数として表わされ、従ってこの値は0----
（2^x-1）の範囲になる。タイプUINT8はUBYTE又はCHAR8
と称すこともできる。タイプUINT16はUWORD又はCHAR16
と称すこともできる。タイプUINT32はULONGと称すこと
もできる。タイプUINT64はUQUADと称すこともできる。
アドレスとして同数のビットを有する無符号整数タイプ
はUADDRと称すこともできる。ターゲット アーキテク
チャに対しサポートされる最大無符号整数タイプ（UINT
32又はUINT64）はUMAXと称すこともできる。 浮動小数点データ タイプはVAX浮動小数点タイプREAL
F、REALD、REALG及びREALHと、IEEE浮動小数点タイプRE
ALS、REALT、REALQ及びREALEとである。任意の特定のタ
ーゲットアーキテクチャに対しこれらの全てをサポート
する必要があるわけではない。 複素数データ タイプはCMPLXF、CMPLXD、CMPLXG、CMPL
XS及びCMPLXTである。複素値は複素値の実数部及び虚数
部を表わす対応する実数タイプの一対の値として表わさ
れる。サポートされた浮動少数点タイプに対応する複素
数タイプのみが特定のターゲット アーキテクチャにサ
ポートされる。 集合体データ タイプの値は連続要素のシーケンスから
成る。集合体値はその本体、シーケンス内の要素の実際
の順番、長さ及び要素の数により特徴づけられる。集合
体タイプは次のとおりである。 （ａ）タイプCHAR8の要素を有するキャラクタ ストリ
ング、タイプSTR8; （ｂ）タイプCHAR16の要素を有する拡張キャラクタ ス
トリング、タイプSTR16; （ｃ）できるだけ緊密にパックされた単ビットの要素を
有するビット ストリング、タイプBITS; （ｄ）デシマル ディジット（頭に符号ディジットを有
するバイトごとに２ディジットづつパックされた４ビッ
トBCDディジットとして表される）の要素を有するPL/I
及びCOBOLデシマル ストリング、タイプDECIMAL;（DEC
IMAL値はその精度、これが含むディジットの数（先頭の
符号ディジットは数えない）及びそのスケール、10進小
数点後に到来するディジットの数により特徴づけられ
る）。 集合体値の要素は零から出発する番号がつけられる。
（これは多くのフロント エンドに、ソース プログラ
ム ストリング インデックスをILストリング インデ
ックスに変換する際に１を減算することを要求する点に
注意されたい。） ストリング演算において処理し得る要素の数に制限はな
い。将来においてフラグを導入してフロント エンド
が、その長さ65535キャラクタを越えないことを保証さ
れたキャラクタ ストリング エクスプレッションを指
示し、このエクスプレッションをVAXキャラクタ スト
リング命令で効率よく計算することができるよにするこ
とができる。メモリ内の長さが変化するストリングの長
さワードは以前として16ビットのみである。デシマル
ストリングは全てのターゲットマシーンに対し31ディジ
ット（符号ディジットが加わる）に制限される。 種々のタードット マシーンに対するリプレゼンテーシ
ョナル タイプ システムの詳細の一例を後記の表６に
示す。 単一ブール データ タイプBOOLがある。これはプログ
ラムの実行中に計算される論理値のタイプであり、指定
された物理的表現を持たない。例えば、ブール値は２進
整数の値、プロセッサ条件コードの値又はプロセッサ
プログラム カウンタの値で表わされ得る。特に、タイ
プBOOLはソース言語内に存在し得る任意の論理又はブー
ル データ タイプに対応しない。これらはINT又はUIN
T値として表わし、必要に応じ、タイプBOOLへ及びタイ
プBOOLから変換する必要がある。 中間言語内の全てのタプルに共通の一般的特徴及びILG5
5の構造的特徴（中間言語内のリーチン）について説明
する。 ILG55はILタプル ノード（通常単にタプルと言われて
いる）から成る。全てのタプルは表７に示すフィールド
を含んでいる。アトリビュートとして知られる他のフィ
ールドは特定の種類のタプルにのみ生ずる。 フロント エンド20の仕様のために予約された任意の量
のスペースを用いて割当てることができるシンボル テ
ーブル ノードと異なり、CILタプル ノードはここで
指定されたフィールドを含むだけである。EILタプル
ノードはタプル ノード アドレスから負方向にオフセ
ットした位置にある追加のフィールドを含み、これらフ
ィールドはバック エンド12に専用である。 ILGの構造 ILG内の１つのタプルを他のタプルに２つの方法で、オ
ペランドとして又はアトリビュートとして参照させるこ
とができる。オペレータ−オペランド関係のみを考察す
ると、CILGは非周期グラフ（DAG）であるが、EILGはフ
ォレスト（森）（即ちツリーの集合体）である。 アトリビュート ポインタ39はILGの追加の構造を生起
すると共に、ILGからシンボルテーブル30への参照も許
可する。最も重要な構造関係は次のタプル及び前のタプ
ルのアトリビュート ポインタにより決まるILGの線形
順序である。CILG内のタプルの全ては線形順序で決めら
れた単一リスト内に生じる。EILGのタプルは各ブロック
につき１つの円形リストの集合体内に生ずる。 下記の規則をILGの構造に適用する。フロント エンド2
0がこれらの規則に違反するCILGを生成する場合には、
バック エンドが違反を検出しコンパイルを終わらせる
よう試みるが、結果は予測不能になる。 （ａ）その結果タイプがNULLであるタプルはステートメ
ントタプルと称し、その結果がNULLでないタプルをエク
スプレッション タプルと称す。 （ｂ）CILにおいて、 （ｉ）スカラ又はブール エクスプレッション タプル
は１以上の他のタプルのオペランドとすることができ
る。集合体エクスプレッション タプルは正確に１つの
他のタプルのオペランドとして使用しなければならず、
この他のタプルは同一の基本ブロック内にあるものでな
ければならない（下記参照）。 （ii）オペランドはエクスプレッション タプル、シン
ボル ノード又はリテラル ノードとすることができ
る。 （iii）オペランドとして用いるシンボル ノードは常
にタイプADDRを有する。オペランドとして用いるリテラ
ル ノードはリテラルのデータ タイプを有する。 （iv）レジスタに割当てられる変数を表わすシンボルは
通常の意味ではアドレスをもたない。しかし、このよう
なシンボルはメモリから読出す又は書込むタプル（FETC
H又はSTORE）のアドレス オペランドとして使用するこ
とができ、この場合にはこのタプルは指示されたレジス
タをアクセスする。 （ｖ）シンボルがスタック フレーム内の変数を表わす
場合には、このスタック フレームは現ルーチン又はシ
ンボル テーブル ブロック ツリー内のその祖先の一
つと関連していなければならず、さもなければ実行時に
スタック フレームを見つける方法がなくなる。 （ｃ）EILではオペランドはエクスプレッション タプ
ルでなければならず、且つどのエクスプレッション タ
プルも正確に１つの他のタプルのオペランドでなければ
ならない。 （ｄ）ステートメント タプルは任意の他のタプルのオ
ペランドにすることはできない。 （ｅ）別のタプルのオペランドであるタプルはILGの線
形順序内のこのタプルの前に置かなければならない。
（このことはEILGではオペランド及びオペレータを同一
基本ブロック内に生じさせる必要があることを意味す
る。） （ｆ）エクスプレッション タプルはオペランドである
全てのタプルを支配しなければならない。即ち、ルーチ
ンのエントリ ポイントからあるタプルへ途中でこのタ
プルの全てのオペランドに出会うことなくたどりつくこ
とができないようにしなければならない。 このセクションの次のパラグラフは中間言語で使用し得
るオペレーション及びこれを表わすのに使用されるオペ
レータの種類を記載する。個々のオペレータは全て〈RE
FERENCE〉（パート−タプル−ディクショナリ）タプル
辞書と称されるデータ構造内に集められる。辞書内の各
オペレータは構造フォーマットを用いて文書化される。
表８はこのフォーマットにおける主カテゴリ、各カテゴ
リの下で与えられる情報及びこの情報を与えるのに使用
されるフォーマットを示している。 タプルのフォーマット セクションはオペランドの数及
び許容し得るオペレータ、オペランド及び結果タイプを
次の形態の単一行で指定する。 op・type（type-1,----type-n）:result ここで、opはタプル オペレータの名前であり、typeは
許容し得るオペレータ タイプを指定する。“type"が
省略される場合には、オペレータ タイプはNULLにする
必要がある。そうでなければ、typeは次のうちの１つと
する必要がある。 （ａ）固有タイプ名（ADDR,BOOL,BITS,LADDR等）は指定
されたタイプのみが許されることを示す。 （ｂ）INT,UINT,REAL,CMPLX又はSTRは指定されたファミ
リーに属する任意のタイプが正当であることを示す。例
えば、CMPLXはCMPLXF、CMPLXD、CMPLXG、CMPLXS及びCMP
LXTが全て許されることを意味し、STRはSTR8及びSTR16
が許されることを意味する。 （ｃ）ALLはNULL以外の任意の他のタイプが正当である
ことを示す。 （ｄ）文字I,U,R,C,A,S及びＢのストリングはこれら文
字の一つで表されるファミリーに属する任意のタイプが
許されることを示し、次の通りである。 I INT A ADDR U UINT S STR R REAL B BITS C CMPLX “Type-1----Type-n"はタプルのオペランドの許容し得
るタイプを指定する。括弧内のリストがない場合には、
オペレータは何のオペランドも取らない。そうでない場
合にはタプルは括弧内のリストの各タイプごとに１つの
オペランドを有する必要がある。各Type-iは次のうちの
１つとする必要がある。 （ａ）Ｔは、このオペランド タイプがオペレータ タ
イプと同一である必要があることを意味する。 （ｂ）固有タイプ名（ADDR,BOOL,BITS,IADDR等）はオペ
ランドが指定されたタイプを有する必要があることを意
味する。 （ｃ）タイプ コード文字I,U,R,C,A,S及びＢのストリ
ングはタイプ指定子と同一の意味を有する。“任意の整
数”を意味するタイプ指定子IUを有するオペランドは一
般に発生コードのタイプIMAXに変換される点に注意され
たい。これがため、プログラム動作はこのようなオペラ
ンドの実際値をタイプIMAXに変換し得ない場合には定義
されない。 （ｄ）オペレータ及びオペランド タイプ指定子がREAL
及びCMPLX又はSTR及びCHARである場合には、実際のオペ
レータ及びオペランド タイプが一致しなければならな
い。例えば、タイプ指定“CADD.CMPLX（T,REAL）:T"
は、オペレータ タイプがCLPLXFである場合には第２の
オペランドがタイプREALFを、オペレータ タイプがCMP
LXTである場合には第２オペランドがタイプREALSを持た
なければならないことを示す。オペレータ タイプがS
B、即ちキャラクタ ストリング又はビット ストリン
グである場合にはオペランド タイプ指定子はCHARであ
り、オペレータ タイプがSTR8である場合にはCHAR8、
オペレータ タイプがSTR16である場合にはCHAR16、オ
ペレータ タイプがBITSである場合にはIMAXでなければ
ならない。即ち、IMAXはストリング タイプBITSに対応
するキャラクタ タイプとして処理される。 タプルの実際のオペランドは、その結果タイプがオペラ
ンド タイプ リストにより指定されたタイプと一致す
るタプル ノートでなければならない。CILでは、実際
のオペランドはタイプADDRを有するものとして常に処理
されるシンボルノード又はデータ タイプ フィールド
で指定されたタイプを有するものとして処理されるリテ
ラル ノードとすることもできる。 エクスプレッション“RESULT"は許容し得る結果タイプ
を指定する。これがない場合には、オペレータはステー
トメント オペレータであり、タプルの結果タイプはNU
LLでなければならない。そうでない場合には、オペレー
タはオペランド タイプ指定子と同一の方法で正確にイ
ンタプリートされる。 アドレス及びメモリ レファレンス アドレス エクスプレッションは中間言語内のレファレ
ンス（参照）の一つである。アドレス エクスプレッシ
ョンの最小フォームはシンボルである。即ち、タプル
ノードのオペランド フィールドはシンボル ノードの
アドレスを含み、このシンボルと関連するメモリ アド
レス（又はレジスタ）を表わすことができる。アドレス
値はこれをメモリ（“ポインタ変数”）からフェッチす
ることにより、演算値をキャスティングすることによ
り、又はプレインクリメント タプル、ポストインクリ
メントタプル又はつぎのリストのタプルのうちの１つを
評価することにより得ることもできる。アドレス計算オペレータ オペレータ 意味 AMINUS アドレスから整数を減算して新アドレスを 発生せよ。 APLUS アドレスに整数を加えて新アドレスを発生 せよ。 BASEPREF アドレスを評価して新アドレスを発生せよ 。 LITAPDR 指定されたリテラル値を含むリード オン リ メモリ位置のアドレスを発生せよ。 UPLINK 現ルーチン又は現ルーチンを含むルーチン に対するスタック フレームのアドレスを 発生せよ。 データ アクセス タプルは値をメモリから又はメモリ
にロード又は記憶させるタプルである。（ここで、“メ
モリ”なる語はターゲットCPU25のレジスタ セットの
レジスタを含む。CPU25のレジスタとノーマル メモリ
位置との唯一の差異はレジスタの“アドレス”はデータ
アクセス タプルで使用し得るのみである点にあ
る。）データ アクセス オペレータは表９にリスト
アップしてある。 全てのデータ アクセス タプルにおいて、第１オペラ
ンドはアドレス エクスプレッションである。全てのデ
ータ アクセス タプルはロング ワード整数を含むオ
フセット アトリビュートも有する。アドレスすべきメ
モリ位置のアドレスはランタイム アドレス オペラン
ドとコンパイル タイム コンスタント オフセット
アトリビュートとの和である。 全てのデータ アクセス タプルは表10にリスト アッ
プされているアトリビュートのいくつか又は全てを有す
る。エフェクト、エフェクト２及びベースシンボル ア
トリビュートの使用については表現エフェクトのための
セクション インタフェースにおいて後に詳細に論じ
る。 レファレンスの他のタイプはアレー レファレンスであ
る。APLUS及びAMINUSタプルは全てのアドレス計算に対
し充分である。しかし、これらタプルはアドレス計算の
意味について何の情報も与えない。特に、これらタプル
はアレー レファレンス及びソース コードに存在して
いるかもしれないサブスクリプト エクスプレッション
についての情報を何も与えない。この情報はベクトル化
に必要である。これがため、ILはアレー レファレンス
を詳細に記述するタプルを有する。 例えば、local Xとして宣言されたBLISSベクトル:vecro
r:〔20,long〕が与えられると、Ｘ〔Ｉ〕に対するレフ
ァレンスは、 ＄1:FETCH.INT32（Ｉ）； ＄2:SUBSCR.IADDR（＄1,〔４〕，

〔０〕； POSITION＝１）； ＄3:FETCH.INT32（X.＄２） と表わすことができる。 VarYとしてとして宣言されたパスカル アレー;packed
array〔1--10,1--10〕of 0----255,が与えられると、 ascignment Y〔I,J〕＝Ｚは、 ＄1:FETCH.INT32（ｊ）； ＄2:SUBSCR.IADDR（＄1,〔１〕，

〔０〕； POSITION＝１）； ＄3:FETCH.INT32（Ｉ）； ＄4:SUBSCR.IADDR（＄3,〔10〕，＄2; POSITION＝２）； ＄5:FETCH.UINT8（Ｚ）； ＄6:STORE.UINT8（＄4-11,＄５）； と表わすことができる。 基本アレー レファレンス オペレータはAREF及びSUBS
CRである。AREFはアレー内の指定要素のアドレスを発生
する。SUBSCRはアレー要素のオフセットを計算する。 第１オペランド又はAREFタプルはアレーのベース アド
レスを表わすアドレス エクスプレッションであり、そ
の第２オペランドはベース アドレスからアレーの要素
までのバイト オフセットを計算するSUBSCRである。AR
EFタプルはSUBSCRタプルの値をベース アドレスに加え
てインデックスされた要素のアドレスを計算する。実際
には、AREF（オリジン、サブスクリプト）に対するコー
ドはAPLUS（オリジン、サブスクリプト）に対するコー
ドと同一である。 SUBSCRタプルはアレー内の要素の一次元オフセットを計
算する。そのオペランドは、 （ａ）要素インデックス：サブスクリプト エクスプレ
ッション内の個々のインデックスはゼロ オリジンに対
し正規化されない。その代わりに、アレー宣言内の非ゼ
ロ下限を考慮したオリジン オフセットをAREFタプルの
アドレス オペランド又は要素アドレスを用いるタプル
のオフセット フィールドに加える必要がある。 （ｂ）ストライド：これは連続する要素のアドレス間の
一次元の差である。ロング ワードの簡単なベクトルで
はストライドはリテラル４であるが、多次元アレーでは
アレーの高次元行（又は大面積）の“要素”間の差であ
る。 （ｃ）サブスクリプト エクスヘプレョションの残部
（即ち、サブ スクリプト エクスプレッション内の残
りのインデックス）に対するエクスプレッション：これ
は別のSUBSCRエクスプレッションか、整数定数ゼロを表
わすリテラル ノードの何れかである。 SUBSCR（インデックス，スライド，残部）に対するコー
ドはADD（MUL（インデックス，スライド）残部）に対す
るコードと同一である。 SUBSCRタプルはアレー レファレンスのサブスクリプト
リスト内のインデックスの位置を示すポジョン アト
リビュートも有する。ポジション ナンバーにより所定
のアレーに対する全てのレファレンス内の同一のサブ
スクリプト位置を識別する必要がある。最も有効なベク
トル化においては、ポジション１を最も急速に変化する
サブ スクリプトにし、ポジション２を次に速く変化す
るサブ スクリプトにするのが好ましい。 他のどのセクションにも実際に適合しないいくつかのタ
プルオペレータがある。これらの種々のオペレータは次
の通りである。オペレータ 意味 ADIFF ２つのアドレス間の整数差を計算せよ。 DEFINES ILG内のサイド エフェクト又は従属性 を、何のコードも発生させることなくエン コードせよ。 VOID エクスプレッションを評価するがその値を 捨て捨てよ。 演算タプル 演算タプルは“演算値"--整数、実数及び複素数‐‐を
処理するのに使用される。これはフェッチ、記憶及び変
換、並びに加算及び乗算のような伝統的演算を含む。 VAX及びRISCアーキテクチャ内のシフト命令は互いに相
違し、フルアブストラクトILシフト オペレータは一方
及び双方のアーキテクチャに無効なコードを発生する。
他方、ILはシフティングをサポートする必要がある。そ
の理由は多くのソース言語がある種のシフト オペレー
タを有するためである。妥協案として、ILは次のオペレ
ータを与える（これらシフト オペレータのどれも演算
オーバ フロー例外を生じない）。 （ａ）SHL、SHR、及びSHAはそれぞれ左シフト、論理右
シフト、及び演算右シフトを生じさせて、正シフト カ
ウントを必要とする（即ちそれらの動作はシフト カウ
ントが負の場合には不確定である）。これらはＣシフト
オペレータをサポートし、RISCアーキテクチャ シフ
ト命令に直接マップする。 （ｂ）SHはそのオペランドが正である場合に左シフトを
行い、そのオペランドが負の場合に演算右シフトを行
う。これはBLISSシフト オペレータをサポートし、VAX
シフト命令に直接マップする。 （ｃ）ROTは回転オペレータである。これはVAX及びRISC
アーキテクチャにおいて異なる形で記述されるが、何れ
の場合にも実際の動作は左回転とすることができ、その
回転カウント値はカウント オペランドの下位のｎビッ
トて指定され、ここでｎはレジスタ サイズの２を底と
する対数値である。（例えば、VAX及びMIPSでは回転カ
ウントはカウント オペランドの下位５ビットであ
る。） 整数オーバ フローは考察すべき別の事項である。ILで
の整数演算のためのサイズを指定する試みにおいて問題
があるため、全てのターゲット マシーンに対し、ソー
ス言語のセマンティクスを満足するコードを発生すると
共にこれらセマンティクスにより課される制約をできる
だけ効率良く受けるようにする。特に、いくつかのマシ
ーン（例えばVAX）は幸運にもバイト及びワード演算を
行うが、RISCマシーンは代表的にはロング ワード演算
のみを行う。全てのサイズ変換を行うことはVAXにはむ
だであるが、真バイト又はワード演算をエミュレートす
ることはRISCマシーンにはむだである。 コード発生器が全てのターゲット マシーンに対し正当
なコードを充分フレキシブルに発生し得るように次の規
制を適用する（INTタイプについての以下の説明は全てU
INTタイプに等しく適用される）。 （ａ）エクスプレッションの結果タイプがINT^x-1である
場合には、コンパイラは指示された計算をｙビット演算
（ここでｙ≧ｘ）で実際に実行することができる。これ
は、原ｘビット計算がオーバ フローする場合にはｘ桁
ビットより多いビットを有するｙビット結果を生ずるか
もしれないためである。例えば、ADD.INT16を32ビット
加算で実行する。20000＋30000は16ビット加算ではオー
バ フローを生ずるが、32ビット加算では正当な32ビッ
ト数50000が生ずる。 （ｂ）全ての演算オペレータはオーバ フロー抑制フラ
グを有する（このフラグはタプル結果タイプがINT又はU
INTであるときにのみ有意になる）。このフラグがセッ
トである場合、タプルに対し発生されたコードは計算の
結果と無関係にいかなる種類のオーバ フロー状態もレ
ポートする必要がなく、結果内に外部高位ビットが存在
する可能性を無視することができる（結果をXCVTタプル
のオペランドとして使用する場合を除く）。オーバ フ
ロー抑制フラグはオーバ フローが決して起こり得ない
タプル（例えばIANDにおいても定められる点に注意され
たい。これらタプルに対するオーバ フローの抑制は特
に容易である。オーバ フロー抑制フラグは演算がオー
バ フローするのは意味的に正しくない状態に対し予定
される。いくつかのアーキテクチャに対しコードが一層
高コストになり得る。（例えばVAXアーキテクチャに対
してはオーバ フロー抑制検出のために余分のコードが
必要とされる。これがため、演算がオーバ フローする
か否かは重要でない場合、又はフロント エンドが特定
の演算は決してオーバ フローし得ないことを知ってい
る場合にはこのフラグはクリアしてコンパイラが最も有
効なコードを発生し得るようにすべきである。 （ｃ）ルーチン ブロック ノードは検出オーバ フロ
ー フラグを有する。このフラグがクリアされている場
合には、バック エンドは整数演算におけるオーバ フ
ローを検出するコードを発生させる必要はない。しか
し、オーバ フローを検出するフードを発生させること
は、これが一層有効である場合には自由であり、オーバ
フロー検出の強制的抑圧は特定のタプル内にオーバ
フロー抑制フラグをセットするだけで達成することがで
きる。 （ｄ）検出オーバ フローフラグがルーチン ブロック
ノードにセットされている場合には、このとき発生さ
れるコードは各エクスプレッション ツリーに対し、こ
のエクスプレッションに対し計算された結果が妥当であ
ることを保証するか、整数オーバ フロー例外のシグナ
リングを保証しなければならない。これは、オーバ フ
ローをエクスプレッションの全てのサブ エクスプレッ
ションにおいて検出することを要件としない。例えば、
A,B,C及びＸが16ビット変数であり、且つＡが32767、Ｂ
及びＣが１であるものとする。アサイメントＸ＝Ａ＋Ｂ
−Ｃにおいて、発生コードは32ビット演算を用いてＡ＋
Ｂ−Ｃを計算し、次いでストアする前にその結果が16ビ
ット結果であるか否かチェックする。この場合には正し
い答え32769がストアされるが、16ビット演算で計算す
る場合には同一のエクスプレッションでも整数オーバ
フロー エラーが生ずる。他方、アサイメントＸ＝Ａ＋
Ｂは値32768を正しく計算するが、これをＸにストアし
ようとするときオーバ フロー例外を生ずる。オーバ
フローを検出しなければならない場所の集合体は明らか
でないが、ストアの右側及びルーチン コール内のアー
キテクチャを必ず含む。 （ｅ）XCVT変換オペレータはそのオペランドの値をリタ
ーンし、表現の外部高位ビットを実オペランドの符号と
一致させる。例えば、Ｅが32ビット演算を用いて評価さ
れたUINT8エクスプレッションである場合、XCVT・UINT8
（E:INT16）はその高位の８ビットが０である16ビット
整数になる。一般に、ＥがタイプＴのエクスプレッショ
ンである場合には、XCVT・Ｔ（E:T）を用いて値の表現
をその公称サイズと一致させることができる。 （ｆ）あるエクスプレッション内の整数オペランドの表
現がオペランドの公称サイズを越える高位ビットを含む
場合には、発生コードはフル表現値又は公称サイズの値
の何れの使用も自由である。これが受け入れられないと
きは、フロント エンドはXCVTタプルを発生して表現か
ら不所望な高位ビットを切り捨てる必要がある。 ILには浮動小数点（フローティング ポイント）オーバ
フロー例外の検出をディセーブルするメカニズムは何
もない。フローティング ポイント オーバ フローは
常に例外のシグナリングを生ずる。フローティング ポ
イント アンダー フローのシリナリングはルーチン
レベルでのみ制御される。ルーチン ブロック ノード
は検出アンダ フローフラグを有する。このフラグがセ
ットされている場合、コンパイラはこのルーチン内に生
ずるフローティング ポイント アンダー フローを検
出しレポートするコードを発生するよう要求される。さ
もなければ発生コードはフローティング ポイント ア
ンダー フローを無視しなければならない。 変換オペレータは別の演算タイプの値に関連する一つの
演算タイプの値を計算する。実数−整数変換用のROUND
及びTRUNCオペレータ、実数−複素数変換用のCMPLXオペ
レータ、及び複素数−実数変換用のREAL及びIMAGオペレ
ータは全く普通のものである。（ROUND及びTRUNCも実数
結果タイプで定義される）。 CTVは汎用変換オペレータである。これは任意の２つの
演算タイプ間の変換を行う。しかし、直接行われる変換
はUNIT-INT、INT-REAL及びREAL-CMPLX（及び当然のこと
ながらINT16-INT32のようなタイプ内の変換）のみであ
ることを承知していることが重要である。このことは、
例えば、CMPLXG-UINT16変換は実際にはCMPLXG-REALG、R
EALG-INT32、INT32-UINT16の一連の変換として行われる
ことを意味する。これは直接実数‐無符号整数変換を有
するVAXパスカルの動作ではない。 XCVTは整数タイプのみを処理する特別オペレータであ
る。CVTと同様に、このオペレータは算術的にそのオペ
ランドに等しいその結果タイプの値を発生する。しか
し、このオペレータは最初にオペランドの表現の高位ビ
ットを変化させてオペランドの表現が算術的にその値に
等しくなるようにする特別の特徴を有する。 例えば、次のエクスプレッション（式）について考察す
る。 XCVT（ADD.UINT8（〔UINT8＝255〕， 〔UINT＝２〕）:INT16） この式を32ビット演算で計算すると、ADDの結果は％X00
000101（257）を含むレジスタになるかもしれない。こ
の場合、XCVTは高位ビットを捨て、正当な16ビット符号
付き整数である ％X00000001（１）を残存させる。 CASTは実際には変換オペレータではない。その理由は値
ではなくビット パターンを処理するためである。CAST
タプルはそのオペランドとして同一のビット パターン
を有するその結果タイプの値を発生する（必要に応じゼ
ロ ビットを切捨て又は連結する）。 もう１つのタイプは変数変更オペレータである。フォー
ムOPMOD（ここでOPはADD,IAND等）の名を有するこれら
オペレータは全てアドレス オペランド及び値オペラン
ドを有する。これらオペレータは指定されたアドレスか
ら演算値をフェッチし、この演算値と値オペランドとの
間の指示された演算を実行し、その結果を同一のアドレ
スにストアさせる。これらオペレータは計算された値も
発生する。これらのオペレータはＣ言語op（＝オペレー
タ）を実行するのに予定される。例えばコード シーケ
ンス ＄1:AODMOD.REALF（X,〔％F0,1〕）； ＄2:STORE.REALF（Y,＄１）； は次のシーケンス ＄1:FETCH.REALF（Ｘ）； ＄2:ADD.REALF（＄1,〔％F0,1〕）； ＄3:STORE.REALF（X,＄２）； ＄4:STORE.REALF（Y,＄２）； と同一の効果を有する。これらのオペレータはOPMODA及
びOPMODXフォームも有し、これらはパックド アレー要
素又はビット フィールド内の値をフェッチし、更新
し、置換する。 PREINCR、PREINCRA、及びPREINCRXオペレータは、値オ
ペランドの代わりにコンパイル タイム コンスタント
インクリメント値を含むアトリビュート フィールド
を有する点を除いて、ADDMOD、ADDMODA及びADDMODXと本
質的に同一である。これらオペレータはアドレス（ポイ
ンタ変数）並びに演算値に適用することができる。これ
らオペレータはＣ言語プレインクリメント及びプレデク
リメント オペレータを実行するのに予定される。 POSTINCR,POSTINCRA及びPOSTINCRXオペレータは、タプ
ルの値がメモリ位置に戻されて記憶された値となるとい
うよりもむしろ、その値が更新される前にメモリ位置に
保持されていた値となると云うことを除けばPREINCR及
びPREINCRXタプルと同じである。上記オペレータはＣの
ポスト インクリメント及びポスト デクリメント オ
ペレータを実行させるものである。 ストリング： コンパイラのストリング（又は集合体）のタイプは、値
が基本タイプからのシーケンスの値となるタイプであ
り、これらのタイプには次のようなものがある。 STR8、８ビット キャラクタのシーケンス（タイプCHAR
8）。 STR16、16ビット キャラクタのシーケンス（タイプCHA
R16）。 BITS、単一ビットのシーケンス。 DECIMAL、10進ディジット及び関連精度のシーケンス。 キャラクタ、即ちビット ストリングにおけるエレメン
トには０からｎ−１までの番号を付ける。なお、ｎはス
トリング長である。８ビットのキャラクタ ストリング
をメモリにアドレスＡにて表現させる場合、アドレスＡ
のバイトがストリングの第１キャラクタを包含し、アド
レスＡ＋１のバイトがストリングの第２キャラクタを包
含し、以下に同様にアドレスＡ＋ｎ−１のバイトがスト
リングの最終文字を包含する。16ビットのキャラクタ
ストリングをアドレスＡにてメモリに表現させる場合、
アドレスＡにおけるワードがストリングの第１キャラク
タを包含し、アドレスＡ＋２におけるワードがストリン
グの第２キャラクタを包含し、以下同様にしてアドレス
Ａ＋２（ｎ−１）におけるワードがストリングの最終キ
ャラクタを包含する。ビット ストリングをアドレスＡ
にてメモリに表現させる場合、ストリングの最初の８ビ
ットはアドレスＡ＋１等におけるバイトの下位から上位
までのビットである。 一般に集合値はレジスタ内に発生し得るスカラー値とは
別に、又は機械語命令におけるリテラル オペランドと
してメモリのどこかに表現させる必要がある。しかし、
中間言語のセマンティック（意味論）モデルとはストリ
ングをまさにスカラのようにフェッチし、処理して、記
憶させることである。コンパイラは一般的なものを割当
てて、中間ストリング値を保持する責任がある。 なお、ストリング オペレーションように生成するコー
ドは、オペランド間にオーバラップがある場合でも斯か
るモデルと調和させる必要がある。たとえばILステート
メント（命令文）STOREF.STR8（Ａ＋1,〔20〕）,FETCH
F.STR8（A,〔20〕）は20個のキャラクタのストリングを
メモリの１つの位置の上に動かす。そうするだけでアド
レスＡのキャラクタを20回コピーする必要がなくなる。 ストリングはその長さが０である場合にはエンプティ
（empty）（空）であると称する。ストリングのヘッド
（head）はノン エンプティ ストリングの第１エレメ
ント（要素）を戻す機能をし、テイル（tail）はノン
エンプティ ストリングの第１エレメント以外の全ての
エレメントを包含しているストリングを戻す機能をし、
エンプティ ストリングは或るストリングがエンプティ
であり、さもなければ誤りであるかどうかを確かめる機
能をする。この場合に標準の比較オペレータ（EQL,NEQ,
LSS,LEQ,GTR,GEQ）によってテストされるような２つの
ストリングＸとＹとの関係は次のように表される。 empty（Ｘ）∧empty（Ｙ）の場合、Ｘ＝Ｙ。 empty（Ｘ）∧empty（Ｙ）の場合、Ｘ＜Ｙ。 empty（Ｘ）∧empty（Ｙ）の場合、Ｘ＞Ｙ。 empty（Ｘ）∧empty（Ｙ）∧head（Ｘ）＜head
（Ｙ）の場合、Ｘ＜Ｙ。 empty（Ｘ）∧empty（Ｙ）∧head（Ｘ）＞head
（Ｙ）の場合、Ｘ＞Ｙ。 empty（Ｘ）∧empty（Ｙ）∧head（Ｘ）＝head
（Ｙ）の場合、rel（X,Y）＝rel（tail）（Ｘ），（tai
l）（Ｙ）。 パスカルの如き幾つかの言語におけるストリング比較オ
ペレータは、長目のストリングの長さに比べて短め目の
ストリングをパディングすることにより等しい長さのス
トリングとする作用だけをする。従って、ILもパッド
ストリング比較オペレータEQLP,NEQP,LSSP,LEQP,GTRP及
びGEQPを有している。 全てのストリング オペレータを表12にリストしてあ
る。 ブール（Booleans）： 表現データ タイプとは異なり、ブール データ タイ
プはユニークな表現を有していない。プログラムの実行
中のブール値は２進整数の或るビット値により明白に表
すか、又はとられる特性のコード パス（path）によっ
て絶対的に表現することができる。ブール データには
ユニークな表現がないから、ILにブール変数を持つこと
は有り得ない。しかし、殆どのソース言語は表現値を論
理的に解釈し、しかも多くの言語が論理変数又はブール
変数を宣言する。従って、オペレータをブール値と、そ
れらのソース言語の２進表現との間で変えなければなら
ない。 LBSETオペレータは整数をその下位ビットをテストする
ことによりブール値として解釈し、又NONZEROオペレー
タは整数をその整数全体がゼロであるか、否かをテスト
することによりブール値として解釈する。LSBITオペレ
ータはブール値をビット パターンが〈00----00〉か、
又は〈00----01〉の整数として表し、又ALLBITSオペレ
ータはブール値をビットパターンが〈00----00〉か、
〈11----11〉の整数として表す。これらのオペレータは
様々なソース言語におけるブール値を次のように２進表
現する。 ブール値はユニークな表現を持たず、従って普通のリテ
ラル ノードで表現することはできなくても、全ての規
則的なIL変換をブール式に当てはめることのできるよう
にすることは極めて望ましいことである。従って、バッ
クエンド12が２つの特殊なリテラル ノードを提供し、
これらノードのアドレスをグローバル変換GEM＄ST_G_TR
UE及びGEM＄ST_G_FALSEに包含させる。これらのリテラ
ル ノードはスタティック ストレージ イニシャリゼ
ーション用には使用できないが、ILGにおけるオペラン
ドとして使用することができる。 AND及びORオペレータを伴うブール式は全評価及びフロ
ー又は短絡評価の２通りの異なる方法で評価することが
できる。全評価では双方のオペランドが十分に評価され
て、実際のモード値を発生し、これらの値をAND又はOR
命令にオペランドとして用いて、実モード結果を得る。
フロー又は短絡評価では第１オペランドを評価する。式
の値を第１オペランドの値によって決定する場合には、
第２オペランドをスキップさせる。そうしないと、第２
オペランドが評価されて、式の値が第２オペランドの値
となる。 ソース言語にはAND及びOR式の全評価を必要とするもの
があり、ソース言語には短絡評価を必要とするか、又は
この短絡評価用の特殊なオペレータを有するものがあ
り、さらに他のソース言語には評価の種類を特定せず、
コンパイラに選択をまかせるものがある。これらのケー
スに対して次の３組のオペレータを準備する。 （ａ）LANDC及びLORC（“Logical AND Conditional"及
び“Logical OR Conditional"）はフロー ブール オ
ペレータである。これらのオペレータはそれらの第１オ
ペランドを評価し、且つそれらの第２オペランドの評価
をバイパスさせることができる。 （ｂ）LANDU及びLORU（“Logical AND Unconditional"
及び“Logical OR Unconditional"）は全評価ブール
オペレータである。これらのオペレータは普通の２進オ
ペレータのように作用し、２つの全評価オペランド式か
ら得られる値を計算する。 （ｃ）LANDU及びLOR（“Logical AND及びLogical OR"）
はCILオペレータであり、これらのオペレータは評価の
種類もオペランドの順序も特定しない。上記オペレータ
はILの拡張中にLANDC及びLORCか、LANDU及びLORUタプル
のいずれかと置き換えることができる。さらに上記オペ
レータをLANDC及びLORCタプルと置き換える際に、それ
らの第１オペランドを評価するコストがそれらの第２オ
ペランドを評価するコストよりも高くなると思われる場
合には、上記オペレータのオペランドを入れ替えること
ができる。 バック エンド12はLAND,LOR,LANDC又はLORCタプルの各
オペランドに属するタプルを識別できるようにする必要
がある。CILではFLOWMARKタプルをこの目的のために用
いる。これらタプルの内の１つのタプルの第１オペラン
ドに関連する全てのタプルは第２オペランドに関連する
全タプルの直前に置く必要があり、又第２オペランドに
関連する全タプルはブール オペレータそのものの直前
に置く必要がある。これらのタプルの内の１つのタプル
のいずれかのオペランドに関連する第１タプルの直前に
はFLOWMARKタプルを置く必要がある。 例． ＄1:FLOWMARK;!第１オペランドの開始 ＄2:FETCH（Ｘ）； ＄3:GTR（＄2,

〔０〕）； ＄4:FLOWMARK;!第２オペランドの開始 ＄5:FETCH（Ｘ）； ＄6:LSS（＄5,〔10〕）； ＄7:LAND（＄3,＄６）！オペレータ タプル 選択オペレータはブール オペランドの値に応じて２つ
の任意タイプの値の一方の値を選択する。論理OR及びAN
Dタプルと同様に次の３つの選択タプルがある。 （ａ）SELCは、その第１オペランドが真であるか、偽で
あるかに応じてその第２又は第３オペランドを評価す
る。 （ｂ）SELUはそのオペランドの内の３個のオペランドを
全て評価してから、その第２か又は第３オペランドの値
を選択する。 （ｃ）SELは評価の種類を特定しないCILオペレータであ
る。このオペレータはILの拡張中にSELCか、SELUにより
置き換えられる。 又、論理AND及びORタプルと同様に、SEL及びSELCは、そ
れらのオペランドに関連するタプルのオペランドの順序
が連続し、しかもFLOWMARKタプルが前に置かれるように
する必要がある。 FLOWMARKタプル。 例 ＄1:FLOWMARK;!第１オペランドの開始 ＄2:FETCH（Ｘ）； ＄3:GEQ（2,

〔０〕）； ＄4:FLOWMARK;!第２オペランドの開始 ＄5:FETCH（Ｘ）； ＄6:FLOWMARK;!第３オペランドの開始 ＄7:FETCH（Ｘ）； ＄8:NEG（＄７）； ＄9:SEL（＄3,＄5,＄８）！オペレータ タプル 又は ＄1:FLOWMARK;!第１オペランドの開始 ＄2:FETCH（Ｘ）； ＄3:GEQ（＄2,

〔０〕）； ＄4:FLOWMARK;!第２オペランド用のコードがな い。 ＄5:FLOWMARK;!第３オペランドの開始 ＄6:FETCH（Ｘ）； ＄7:SEL（＄3,

〔０〕，＄６）！オペレータ タプル ‐‐‐‐第２オペランドに注意する ブール オペレータの全てを表13にリストしてある。 実行時間のチェック： チェック オペレータはプログラムの実行中に或る条件
が真であるか、どうかをチェックし、その条件が真でな
い場合には例外として除外する。ASSERT以外のチェック
オペレータの全てはそれらの第１オペランドの値を戻
す。各チェック タプルは条件のフィールドを有してお
り、これは条件が真でなければ例外である旨を知らせる
べく特定化し、その例外の除外を知らせた後に制御を戻
すべきか、どうかを指示するフィールドを続行させるこ
とができる。制御が例外の除外後にチェック タプルに
戻れば、このチェック タプルは除外が起こらなかった
場合に戻ることになる値と同じ値に戻る。これらのチェ
ック オペレータを表14にリストしてある。 フロー制御： ILG55は基本ブロックを構成する。基本ブロックは、ブ
ランチ ターゲット タプルで始まり、ブランチ タプ
ル又はフロー終了タプルで終る一連のタプルである。基
本ブロックはその冒頭部だけを入力させ、原則として前
記冒頭部の全てのコードは、制御が基本ブロックの終り
まで進む前に実行させる（前記条件付き評価についての
説明参照） CILGでは基本ブロックをエンド ツー エンドに連結す
る。基本ブロックの終りのブランチ タプルは、制御が
その基本ブロックからLABELタプルで開始させなければ
ならない次の基本ブロックに流れる場合に省くことがで
きる。同様に、基本ブロックの冒頭におけるLABELタプ
ルは、それへのブランチがない場合に省くことができ
る。（即ち、バック エンド ブランチ タプルにより
先行されないLABELタプルを見つける場合には、それにB
RANCHを挿入し、又バック エンドがブランチ ターゲ
ット タプルにより後続されないブランチ タプルを見
つける場合には、同期ラベル シンボル付のLABELタプ
ルを挿入する。）IL拡張フェーズは各基本ブロックに対
して、それらの相互関係を表現する別のフロー グラフ
データ構造を有する円形のタプル リストを発生す
る。 基本ブロック内のフローは暗黙的にタプルの線形順序付
けに準ずる。基本ブロック間の全てのフローは明示フロ
ー制御タプルで表現されるため、ILGの基本ブロックは
ルーチンの意味合いに影響を及ぼすことなく任意の順序
で配列させることができる。 各基本ブロックの冒頭におけるブランチ ターゲット
タプルはシンボル表におけるラベル シンボル又はエン
トリ シンボル ノードへのポインタを包含している。
基本ブロック間の制御フローはブランチ タプルの属性
である宛先リストによって表現される。宛先リストにお
ける各ノードはラベル シンボル又はエントリ シンボ
ル ノードを示し、これは同じルーチンにおける或るブ
ランチ ターゲット タプルによっても示され、制御を
基本ブロックで始める基本ブロックに転送すべきことを
指示する。 ブランチ ターゲット タプルは基本ブロックの開始を
マークする。全ブランチ ターゲット タプルは次のよ
うな属性を有している。属性 意味 ブロック エントリ これがそのスコープ（有効範囲）のエ ントリ基本ブロックであるか、どうか を示すフラグ。 このタプルに関連するラベル又はエントリ シンボル
ノードへのラベル シンボル Ａポインタ。 スコープ ブロック シンボル表におけるブロック ノード へのポインタ 揮発性 制御がこのルーチン用のILGにて表 現されない（非ローカルGO TOの 如き）或る制御の転送によりこの基本 ブロックに到達できないことを示すフ ラグ。 ブランチ タプルは基本ブロックの終りをマークし、且
つその後続するものを指定する。全てのブランチ タプ
ルは次のような属性を有している。属性 意味 宛先リスト ブランチ用の宛先リストへのポインタ。 ターゲット シンボル シンボル ノードへのポインタ。この フィールドは数個のブランチ オペレ ータにしか用いられず、それぞれ異な る意味を有しているも、常にゼロか、 又はラベル シンボル ノードへのポ インタを包含する。 宛先リストは宛先ノードのリストであり、このリストは
宛先ノードの次のフィールドと一緒にリンクされる。ブ
ランチ タプルの宛先リスト フィールドは斯種のリス
トにおける第１宛先ノードへのポインタを包含してい
る。（なお、宛先ノードは僅か１つの宛先リストに生じ
得るだけであり、宛先リストは１個のブランチ タプル
だけで示すことができる。２つのブランチの宛先が同じ
でも、これらのブランチは別々の同じ宛先リストを持た
なければならない。）各宛先ノードはターゲット フィ
ールドを有しており、これはラベルまたはエントリ シ
ンポル ノードへのポインタを包含している。宛先ノー
ドは、ブランチ ターゲット タプルのラベル シンボ
ル フィールドが同じシンボル ノードへのポインタを
包含している基本ブロックへ制御を予想転送することを
表す。宛先ノードは２種類ある。大抵の種類のブランチ
タプルは単純な宛先ノードを用いて、宛先リストにお
けるその位置に基づく宛先を選定する。しかし:BRSELタ
プルとセレクタ宛先ノードを用いて、セレクタがタプル
のオペランド値に整合する宛先を選定する。セレクタ宛
先ノードは低テスト値と高テスト値（これらはいずれも
長いワードの整数である）の追加のフィールドを有して
いる。このセレクタ宛先ノードはオペランドの値が宛先
の低テスト値と高テスト値との間に落ちる場合にオペラ
ンドの値と一致する。 宛先リストで一組の宛先を指定してから、タプル オペ
ランドに基づいて１つの宛先を選択する定型ブランチ
オペレータとは異なり、間接ブランチ オペレータ（JU
MP及びJUMPLOCAL）はアドレス式（通常はラベル変数）
によって指定されるアドレスに制御を転送する。これら
のオペレータはGO TOに指定されたFORTRAN又はラベル変
数へのPL/Iに用いられるオペレータである。 バック エンドはさらに、間接ブランチ タプルの可能
な宛先を確かめてからルーチン フロー グラフを正し
く組立てることのできるようにする必要がある。従っ
て、間接ブランチ タプルは定型ブランチ オペレータ
と同じような宛先リストを有する。しかし、これらの宛
先リストは（JUMPタプル用のオプションである）単一宛
先を包含しているだけである。この宛先のターゲット
ラベルはVBRANCHタプルが直ぐ後に後続するVLABELを識
別する。この場合、VBRANCHタプルの宛先リストは、間
接ブランチのこのルーチンにおける実際に有り得る宛先
の全てをリストする。 VLABELタプルとVBRANCHタプルとの斯かる組合わせのこ
とを仮想基本ブロックと称する。このブロック用のコー
ドは発生させることはなく、これはVLABELとVBRANCHと
の間には他のタプルを設ける必要がないからである。従
って間接ブランチからの制御を後続する仮想ブロックの
いずれかに通すことができる。このようにすれば、多数
の間接ブランチが同じ宛先を有する場合に、単一の仮想
基本ブロックでそれら全ての宛先を表現することができ
るので有利である。 各ルーチンには他にもう１つの仮想基本ブロックがあ
る。このブロックはBEGIN及びBNTRYPTRタプルから成る
ブロックがある。このブロック用のコードは、このブロ
ックの実行を常にENTRYにて開始させるから発生させな
いが、そのブロックはバック エンド用ルーチンのエン
トリ点を全て識別する。 基本ブロックはブランチ タプル又はフロー終了タプル
で終わらせることができる。制御がフロー終了タプルに
達すると、その制御は現行ルーチンから完全に離れる。
フロー終了タプルは制御を現行ルーチンにおける宛先に
は転送しないから、それらのタプルは宛先リスト及びタ
ーゲット シンボルの属性を持たない。 なお、JUMPオペレータは、それが宛先リストを持たない
場合、このことは現行ルーチンに可能な宛先がないこと
を意味することからして、実際上はフロー終了オペレー
タである。JUMPSYMBOLはフロー終了オペレータであり、
これはCILにおける既知のラベルーへのノン（非）ロー
カル GO TOを表現するのに用いられ、EILでは上記オペ
レータはノン ローカルJUMPと置き換えられる。 フロー制御オペレータの全てを表15にリストしてある。
ルーチンの呼出し及びパラメータの受渡し： リンケージには制御、パラメータ、復帰値に関する３種
類の規約がある。“リンケージ規約”とは、呼出しルー
チンと被呼ルーチンを適切に「互いに通信」させるジェ
ネレーテッド コードについての全ての規則のことを称
する。これらの規則の内の幾つかはコード ジャネレー
タ29に組込む。他の場合には呼出し及び被呼ルーチンを
一致させなければならない選択性がある。これらの選択
性の内の幾つかは（双方のルーチンにアクセスする必要
がある場合）シェルによって成され、他の選択はフロン
ト エンド20により成されて、シンボル表30及びILG55
にてコード化される。 制御リンケージ規約は命令を規定し、これらの命令は呼
出しルーチンから被呼ルーチンへと制御を通して、被呼
ルーチンの実行文脈を確立させて、制御を呼出しルーチ
ンへと戻すべく実行させる必要がある。制御リンケージ
規約は呼出しルーチンにおけるINITCALL及びCALLタプル
と、被呼ルーチン用のエントリ シンボル ノードとに
より決定される。 オペランドが外部レファレンスであるCALLタプルは識別
したコール（呼）であり、ライン内の被呼ルーチンをコ
ンパイルしたり、又は被呼ルーチンの個別化したコピー
を発生する範囲がどんなであれ、識別した呼に対するリ
ンケージを選択するのは全く自由である。識別されない
呼に対しては、INITCALLタプルの呼出し規約フィールド
が、その呼に使用すべき制御リンケージ規約を特定化し
なければならない。このフィールドの値は列挙したタイ
プGEM＄CALLING_CONVENTIONからのものとする必要があ
り、これらの定数を次のリストに定義する。定数 意味 標準（Standard） ターゲット システムには標準の外部呼出 し規約を用いる。（これはMIPS履行用 に規定した呼出し規約に過ぎない。） 呼（Coll） CALLリンケージ（VAXだけ）を用い る。 Jsb JSBリンケージ（VAXだけ）を用いる。 ルーチン ブロック ノードは標準のエントリ フィー
ルドを有しており、これはこのルーチンへの非識別呼に
よって呼出される斯かるルーチンをコピーするのにどの
制御リンケージ規約を用いるのかを指定する。このフィ
ールドの値は列挙したタイプGEM＄ENTRY_CONVENTIONか
ら来るものとする必要があり、その定数を次のリストに
定義する。定数 意味 None ルーチンへの全ての呼は現行コンパイルで 識別された呼であるため、非識別呼から呼 出すべきルーチンの例を生成する必要はな い。 Standard 標準エントリ規約を用いて呼出すことので きるルーチンを生成する。（これはMIP Ｓ履行用に規定した単なる呼出し規約であ る。） Call CALLリンケージ（VAXだけ）を用い る。 Jsb JSBリンケージ（VAXだけ）を用いる。 パラメータ リンケージ規約は他のタイプのものであ
る。ルーチン呼出しは被呼ルーチンに利用できるアーギ
ュメント リストを作る。アーギュメント リストは一
致により呼出し及び被呼ルーチンの双方に知られる位置
（レジスタ又はアドレスが或る標準レジスタに包含され
るメモリ ブロックの位置）におけるスカラ値（アドレ
ス）を収集したものである。 被呼ルーチンの仮パラメータはパラメータ フラグ セ
ットである可変シンボル ノードにより表現される。パ
ラメータ シンボルに関連するアドレスは、呼出しルー
チンによって指定される記憶位置か、呼出しルーチンが
通過させたデータのコピーを包含するローカル記憶位置
のことである。（“アドレス”とは実際にはレジスタの
ことである。）上記仮パラメータはアーギュメント リ
ストから及び下記に述べるようにパラメータ シンボル
のメカニズム及びセマンティク フラグから取り出され
る。 パラメータは、そのパラメータの変数に関連するアドレ
スが呼出しルーチンによって渡された記憶位置（実際の
記憶位置）のアドレスである場合にバインド セマンテ
ィクを有する。上記パラメータは、コンパイラがそのパ
ラメータ用の記憶位置を被呼ルーチン（ローカル記憶位
置）に割当て、必要に応じ実際の記憶位置とローカル記
憶位置との間にコピーを生成する場合にコピー セマン
ティクを有する。（バインド セマンティクを有するパ
ラメータのローカル記憶位置はその実際の記憶位置と同
じである。） コンパイラは、１ルーチン内のパラメータの使用パター
ン及び表10-3にリストしたフラグに基づくパラメータに
対してバインド セマンティクを用いるのか、コピー
セマンティクを用いるのかを選定する。（“エイリアス
効果”についてはCTO.70におけるData Access Modelに
記述されている。）要するにエイリアス効果とは実際の
記憶位置をパラメータ シンボルを介することなくアク
セスする方法である。これは実際の記憶位置となり得る
非ローカル変数、即ち別の効果に対する直接レファレン
スを含み、しかも実際の記憶位置をアクセスすることの
ある他のルーチンを呼出す。 表17は様々なソース言語をセットする際に用いるパラメ
ータ セマンティク フラグを示す。 パラメータ メカニズムは、呼出しルーチンが被呼ルー
チンへの引き渡しを希望することと、アーギュメント
リストに実際上何を記憶させるのかとの関係を特定化す
る。パラメータ シンボルは、このパラメータに対する
値を渡すのに用いられるメカニズムを指定するメカニズ
ム フィールドを有しており、アーギュメント タプル
は、このアーギュメントを渡すべきメカニズムを指定す
るメカニズム フィールドを有している。これらの各フ
ィールドの値は列挙したタイプGEM＄MECHANISMから来る
ものとする必要があり、これらのフィールドの定数を表
18にリストしてある。 パラメータ変数の未知のサイズ フラグが偽である場合
には、そのパラメータのサイズをコンパイル時に確認し
て、そのサイズ フィールドによりパラメータ サイズ
を指定する。パラメータ サイズの未知サイズ フラグ
が真である場合には、そのパラメータのサイズはコンパ
イル時に確認しなくて済む。未知サイズ パラメータの
サイズは、それがアレイ ストリング又はアドレス及び
長さ（長さパラメータに関連するレファレンス）メカニ
ズムを有する場合には、実行時に決定することができ
る。別個の長さワードをアドレス及び長さメカニズムで
渡し、且つパラメータが集合データ タイプのものであ
る場合には、長さアーギュメントをバイト単位でなく、
エレメント（ビット又は文字（キャラクタ））のパラメ
ータ サイズとして解釈する。さらに、パラメータが文
字ストリングであり、このストリングの表現が変化する
場合には、パラメータ サイズはストリングの現行サイ
ズでなく、最大サイズとなり、そのストリングのテスト
部分にのみ適用され、これはストリング長ワード又はヌ
ル ターミネータに必要とされるベースには当てはまら
ない。なお、パラメータは、コンパイラがどの程度コピ
ーするのか判らなければ、コピー セマンティクを有す
ることはできない。実際のパラメータ サイズがコンパ
イル時に判らず、実行時にコンパイラによっても計算で
きない場合には、フロント エンドがパラメータの必須
バインド フラグをセットして、バインド セマンティ
クの使用を余儀なくさせる必要がある。 他のタイプはリターン バリュー リンケージ規約であ
る。被呼ルーチンは２通りの方法で情報を呼出しルーチ
ンに戻すことができる。その第１の方法は出力パラメー
タを用いる方法である。このパラメータは値以外のメカ
ニズムで渡される変数であるため、被呼ルーチンは値を
それに記憶させることができる。第２の方法は復帰値を
用いる方法である。復帰値とは被呼ルーチンにより計算
されて、呼出しルーチンに「戻される」値のことであ
り、この値は特定の結果タプルにより表現式の値として
利用可能となる。 スカラ値はレジスタに戻すことができる。たとえば、我
々の殆ど全て言語は算術関数値を標準レジスタに戻し、
BLISS“出力パラメータ”の特徴は、或るルーチンが任
意のレジスタ値を戻すことにある。 ストリングを戻すルーチンの場合には、アーギュメント
リストにおけるタプルが復帰値を一時バッファに割当
て、そのアドレスを被呼ルーチンに渡し、この被呼ルー
チンのタプルが復帰値をバッファに記憶させ、呼出しル
ーチンのタプルがバッファからその値を検索するように
する必要がある。 復帰ストリングのサイズを被呼ルーチンにより決定する
場合には、呼出しルーチンがその結果に対するスペース
を割り当てることはできない。その理由は、呼出しルー
チンは結果がどの程度の大きさになるのかを前もって知
らないからである。この場合の可能性に対するメカニズ
ムは特定のタプルに対するものである。しかし、これら
の可用性はターゲット環境についての呼出し標準規格に
依存する。 呼出しルーチンは：（ａ）被呼ルーチンが固定バッファ
による値を戻すことを要求したり；（ｂ）被呼ルーチン
がスタックの値を戻すことを要求したり；（ｃ）被呼ル
ーチンがダイナミック ストリングによる値を戻すも、
被呼ルーチンがそのような選定をする場合にはスタック
に戻されたストリングを受け取ることを要求したりする
ことができる。被呼ルーチンは固定バッファによるダイ
ナミック サイズの結果か、又は呼出しルーチンがその
ダイナミック サイズの結果を必要とする場合に、スタ
ックのダイナミック サイズの結果を戻すべく常に用意
しておく必要がある。被呼ルーチンはダイナミック ス
トリングによる結果、呼出しルーチンがダイナミック
ストリングによる結果を要求する場合にスタックの結果
を戻すべく用意しておく必要もある。 そこで、CILでのルーチン呼出しの表現につき考察す
る。プロシャージャ又は機能を呼出すのに多数の個別の
操作が行なわれる。それには次の幾つかのステップが必
要である。 （ａ）アーギュメント リスト用のスペースを割当て
る。 （ｂ）パス−バイ−バリュ（pass-by-value）オペラン
ド式用のスペースを割当てる。 （ｃ）記述子用スペースを割当てる。 （ｄ）アーギュメント記述子を作製する。 （ｅ）アーギュメント記述子を作製する。 （ｆ）結果値に対するスペースを割当てる。（結果値、
即ち出力アーギュメントは、呼出し後まで存在しないア
ーギュメントである。ILにおける機能は結果値でプロシ
ージャとして処理される。 （ｇ）アーギュメント リストを作製する。 （ｈ）ルーチンを呼出す。 （ｉ）アーギュメント、記述子及びアーギュメント リ
スト用に割当てられたスペースを削除する。 （ｊ）呼出しによる結果値を得る。 （ｋ）結果値に対して割当てられたスペースを解除す
る。 ILでとった汎用戦略は、呼出しをするのに伴われる様々
な操作に対して別々のオペレータを与えることにある
が、これらのオペレータは特殊な形態でひとまとめにす
る必要がある。ILのルーチン呼出しは次のようなもので
構成する。即ち、 1.呼出しを行なう連続操作の冒頭にフラグを立てるINIT
CALLステートメント。 2.アーギュメント リストを構成する一連のアーギュメ
ント及び一時割当てステートメント。 3.制御を被呼ルーチンに実際に転送する呼出しステート
メント（CALL又はBPCALL）。 4.呼出しの復帰値をアクセス可能にする一連の結果タプ
ル。 INITCALL及びステートメントは必須のものであるが、ア
ーギュメント リスト及び結果タプルは随意選択できる
ものである。呼出しに伴われるタプルは全て同じ基本ブ
ロック内に発生させる必要があり、どの結果タプルも介
在タプルなしで呼出しタプルを直ぐ後ろに後続させる必
要がある。INITCALLと呼出しとの間にどんなタプルがあ
ろうとも、他の制約は何もない。それでも、ルーチン呼
出し用のILは他の呼出し用アーギュメント リストIL内
に含めることができる。 アーギュメント リストの構成は、このアーギュメント
リストそのものに対するアドレス及び記述子用及び引
き渡す値を一時的に保持するため並びに出力アーギュメ
ント用のスペースを割当てる操作を伴う。これらの活動
状態をアーギュメント タプルと一緒にILに特定化す
る。全てのアーギュメント タプルはARGで始まる名前
を有しており、これらのタプルは表20にリストした属性
を有している。 呼出しルーチンが引き渡す値を有する場合、このルーチ
ンは名前がARGVALで始まるアーギュメント タプルの１
つを用いる。実際のアーギュメント値はこれらのタプル
でアーギュメント タプルのオペランドとして特定化さ
れる。なお、このことは必ずしもアーギュメントを値メ
カニズムを用いて引き渡すことを意味するのではない。
メカニズムが値メカニズムである場合には、オペランド
値をアーギュメント リストに直接記憶させるか、さも
なければテンポラリを割当てて、オペランド値をテンポ
ラリに記憶させ、このテンポラリをレファレンス又は記
述子により引き渡すようにする。（これはBLISSにおけ
る％REFに似ている）。値メカニズムはスカラタイプのA
RGVALタプル及びコンパイル時間の大きさが一定のARGVA
LAタプルでサポートされるだけである。 呼出しルーチンが既存の記憶位置に渡すアドレスを有す
る場合、このルーチンは名前がARGADRで始まるアーギュ
メント タプルの１つを用いる。実際の記憶位置のアド
レスはこれらのタプルでアーギュメント タプルのオペ
ランドとして特定化される。従って、値メカニズムはこ
れらのタプルと一緒に用いることはできない。アーギュ
メント リストにこれらタプルの１つが発生すると、被
呼ルーチンを現行ルーチンに対する既知の記憶位置から
呼出したり、その記憶位置に書き込ませることができる
から、これらのタプルは依存性及び副作用を有すること
ができるため、オフセツト効果及び基本シンボル フィ
ールドを有し、これらのフィールドは全てのメモリ レ
ファレンス タプルに用いられ、又特殊なフラグのパル
ム（parm）が読み取られたり、書き込まれたりし、これ
は被呼ルーチンが記憶位置からの読み取り及び／又は記
憶位置への書き込みをするようにコンパイラをし向ける
か、どうかを指示する。 アーギュメント タプルが汎用メカニズムを指定する場
合には、コードを発生させて記述子用スペースを割当て
て、その基本アドレス フィールド内にそのコードを入
れる。フロント エンドは記述子内に初期化すべき他の
いずれものフィールドを明確に指定させる必要がある。
これはDSCFILDタプルを用いて行なわれ、これらのタプ
ルは汎用メカニズムで以前のアーギュメント タプルに
差し戻され、そのアーギュメントに割当てられた記述子
のフィールドに記憶させる値を指定する。アーギュメン
ト ブロックの構成： 幾つかのRTLリンケージはアーギュメントのコレクショ
ンをアーギュメント ブロックに渡す必要があり、この
ブロックのアドレスは普通のレファレンス パラメータ
のようにRTLルーチンに受け渡す。これは次の３つの特
殊なタプルを用いて行なう。 （ａ）ARGBLOCKは特殊サイズのブロックをスタックに割
当てて、そのアドレスを被呼ルーチンに渡すアーギュメ
ント タプルである。上記ブロックはBLKFIELDタプルを
用いて初期化することができる。 （ｂ）ABLKFIELDタプルは、任意のタプルの代わりに以
前のARGBLOCKタプルを汎用メカニズムで差し戻すことを
除けば、DSCFIELDと同じである。このタプルは値をアー
ギュメント ブロックのフィールドに記憶させる。 （ｃ）ARGDEFINESタプルは、それがコードを発生しない
ことを除けば、アーギュメント タプルと同じである。
このタプルはフロント エンドを正規のアーギュメント
タプルに関連しないアーギュメント的な副作用を特定
化させる。特に上記タプルはアーギュメント ブロック
に通過させたアーギュメントに関連する作用を指示する
のに用いることができる。 ルーチンを集合値に戻すには、呼出しルーチンが割当て
た位置にその値を記憶させる必要がある。名前がARGTMP
で始まるタプルは特定サイズの記憶ブロックを割当て、
そのアドレスを被呼ルーチンに受け渡す。これらのタプ
ルは、ARGADRタプルが既存の記憶ブロックのアドレスを
渡し、又ARGTMPタプルが呼出しに対して特別に割当てた
テンポラリのアドレスを受け渡すことを除けばARGADRと
同じである。 ARGBUF,ARGSTK及びARGDYNタプルはテンポラリを割当
て、ダイナミック ストリング復帰値を得るのに必要な
特殊な記述子を受け渡す。これらのタプルは、いずれも
通常のアーギュメント タプルの属性を有しているが、
それらのメカニズムの属性は、そのメカニズムがダイナ
ミック復帰値のメカニズムの使用により暗示されること
からして無視される。 名前がRESULTで始まるタプルは呼出しルーチンでアクセ
ス可能なルーチン呼出しからの復帰値を作製する。これ
らのタプルの作用は、これらが被呼ルーチンにより戻さ
れたテンポラリ位置、即ちレジスタからの出力パラメー
タをさらに長持ちするテンポラリ位置に動かすことにあ
る。結果タプルの値はそれが検索した復帰値の値に過ぎ
ない。呼出しに対する結果タプルには全て呼出しタプル
を直ぐ後続させる必要がある。 バウンド プロシージャ 呼出し： バウンド プロシージャ値、即ちBPVは未知のルーチン
を呼出すのに必要とされる状態を表す。ルーチンをアッ
プ レベルのレファレンスを含み、割当て変数を他のル
ーチンにスタックすることができるため、バウンド プ
ロシージャ値には呼出すべきルーチンのコード アドレ
スだけでなく、そのためのスタテック リンクを構成す
るのに十分な情報も組込む必要がある。 不都合なことに、BPVはそれらをどのように創成し、そ
れらをどのように表現し、それらをどのようにして呼出
し、又それらがどんなに大きくても、それぞれ異なるソ
フトウェア アーキテクチュアで極めて異なる方法にて
処理される。従って、コンパイラは首尾一貫した表現を
提供しようとはしない。その代わり、フロント エンド
はターゲット ソフトウェア アーキテクチュアに応じ
て異なるコードを生成しようとする。 （ａ）VAX及びMIPSソフトウェア アーキテクチュアに
おけるBPVは単にコード アドレス及びコンテキスト
（文脈）値であり、バウント プロシージャ呼出しは、
コンテキスト値を特定のレジスタにロードさせてからコ
ード アドレスへの呼出しをして行なう。従って、フロ
ント エンドはBPVを一対のアドレス値として表現する
責任がある。コード アドレスはBPLINKタプルで得られ
る。BPVへの呼出しは、アドレス オペランドをコード
アドレス値とするCALLとして表現すべきであり、この
場合、コンテキスト値は、その値をアーキテクチュアの
スタチック リンク レジスタに特殊なレジスタ アー
ギュメントとして受け渡すようにする。 （ｂ）RISCマシンでは全てのプロシージャを或る追加の
情報と一緒にコード アドレスを包含している記述子に
より表現し、BPVは実行時に構成される特殊な記述子
（これはコンテキスト ポインタを包含している）のア
ドレス及びコンテキスト ポインタにロードして、実ル
ーチンを呼出すRTLルーチンのアドレスに過ぎない。フ
ロント エンドは斯様な記述子そのものに対するスペー
スを割当てなければならず、そのスペースに記述子を入
れるのにBPVALタプルを用いる。この場合、BPVは記述子
のアドレスにより表現し、このBPVへの呼出しは上記ア
ドレスへの呼出しにより表現すべきである。 バック エンド12にとって必要なことは、ルーチンの各
入口点に対するパラメータが何であるかを知ることであ
る。フロント エンド20は入口点のパラメータ リスト
を表すパラメータ ノード（次のフィールドによりリン
クされる）のリストにおける最初と最後のノードに対す
る点に各エントリ シンボル ノードのパラム リスト
及びパラム リスト テイル フィールドをセットする
ことによりルーチンの各入口のパラメータを知るように
する。 各パラメータ ノードは、それらが アーギュメント
タプル（表20参照）で行なうのと同じ意味を有している
レジスタ及び特定のレジスタ フィールドが受け渡す入
口点及びアーギュメント位置を含むルーチンのパラメー
タ シンボル ノードを指すシンボル フィールドを有
する。従って、パラメータ ノードのリストは入口点の
パラメータを全て識別すると共に、これらのパラメータ
が、その入口点のアーギュメント リストのどこに生ず
るのかを識別する。 なお、パラメータ シンボルは１つ以上のパラメータ
リストにて発生し、それらは各々異なるアーギュメント
位置にて発生する。しかし、メカニズムは特定アーギュ
メント リストにそれが発生するというよりも、むしろ
パラメータ シンボルの属性と見なせるから、パラメー
タ ノードはメカニズム フィールドを有していない。 RETURNRGタプルは特定レジスタにおけるスカラ値を戻
し、RETURNSTK及びRETURNDYNとはPRISM呼出しスタンダ
ードで与えられるダイナミック ストリング戻しメカニ
ズムの１つを用いてストリング値を戻す。なお、値をア
ーギュメント テンポラリを経て戻すことと、値を普通
の出力パラメータに記憶させることは相違しないため、
アーギュメント テンポラリを経て値を戻すのに呼出し
ルーチン用の特殊なタプルは必要でない。 パラメータ シンボルに関連するアドレスはパラメータ
のローカル記憶位置のアドレスである。被呼ルーチンは
DESCADDRタプルを用いて汎用記述子のメカニズムでパラ
メータ用記述子のアドレスを得ることができる。実際の
サイズを（記述子又は別個のサイズ パラメータの）ア
ーギュメント リストで得ることができれば、未知のパ
ラメータの実際のサイズをSIZEタプルを用いて得ること
ができる。 ルーチン呼出しに伴われるオペレータの全てを表21にリ
ストしてある。 記憶配分及び範囲付け： 字句ブロックは一組の宣言が、例えばルーチン、サブル
ーチン、機能又は開始−終了ブロックに有効であるソー
ス プログラムの範囲であり、ルーチンの字句構造は、
ルートがルーチン ブロック ノードとなるスコープ
ブロック ノードのトリーにより表現される。ILGの各
基本ブロックは単一字句ブロックに属するコードを包含
する。基本ブロックの開始点におけるブランチ ターゲ
ット タプルはシンボル表における対応するブロック
ノードを指すスコープ ブロック フィールドを有して
いる。ルーチンの各字句ブロックはユニークなスコープ
エントリ基本ブロックを持たなければならず、このブ
ロックは字句ブロックの内で、この字句ブロック以外の
いずれかの基本ブロックから制御を受け渡すことのでき
る基本ブロックである。斯かるスコープ エントリ基本
ブロックはブチンチ ターゲット タプルのブロック
エントリ フラグにより識別される。 CILにおける可変シンボルに対するレファレンスは常に
記憶位置のアドレス（即ち、レジスタの名前）をもたら
す：即ち、 1.スタティック変数は記憶域クラスがスタティックか、
グローバル レフか、又は予約したものである。スタテ
ィック変数はコンパイル時に或るPSECTに位置付けられ
るため、このような変数に対する各レファレンスは同じ
位置に照合させる。 2.ローカル変数は、記憶域クラスがオートマチックか、
スタック ローカルか、レジスタか、登用されたレジス
タであって、しかも未知サイズ フラグが偽である変数
である。ローカル変数はそれらの字句単位有効範囲の単
一実行中にしか存在せず、それらの字句単位有効範囲の
多数の実例を同時に実行する場合には多数の実例を持つ
ことができる。ローカル変数はコンパイル時に割当てら
れて、それらのルーチンのスタック フレームにおける
位置を登録したり、又は知ったりする。 3.ダイナミック変数はローカル変数と同じ記憶域クラス
のものであるが、未知サイズ フラグは真である。ロー
カル変数と同様に、ダイナミック変数は、それらの字句
単位有効範囲の単一実行中にしか存在せず、それらの字
句単位有効範囲の多数の実例を同時に実行する場合には
多数の実例を持つことができる。ダイナミック変数は実
行時にCRETEタプルによるスタックに割当てられ、しか
もバック エンドにより創成される関連するポインタ変
数によりアクセスされる。 4.コピー セマンティクスを有するパラメータは、それ
らの未知サイズ フラグのセッテイングに応じてローカ
ル又はダイナミック変数として作用する。 5.バインド セマンティクスを有するパラメータは被呼
ルーチンには全く割当てられない。これらパラメータ
は、実際の記憶位置アドレスを保持するためにバック
エンドにより創作される関連するポインタ変数を経てア
クセスされる。 字句ブロックにおけるタプルは、その字句ブロック又は
シンボル テーブル ブロック トリーにおけるいずれ
かのアンセスタにて宣言される任意の変数を参照するこ
とができる。現行のルーチンの変数を参照することに勿
論何等問題はない。他のルーチンのスタティック変数は
直接参照することができる。他のルーチンのローカル及
びダイナミック変数は、変数を宣言するスタック フレ
ームを位置付ける“スタティック チェーン”を必要と
する。しかし、フロント エンドがルーチン ブロック
及び変数を正しく注釈付ければ、バック エンド12はス
タティック チェーンを創成して、それを用いてコード
を生成すべく応答することができる。 ダイナミック スタックの割当てには次のような幾つか
の種類がある。 1.ダイナミック変数用のスタック記憶域をCREATEタプル
により割当てる。これはCREATEタプルと同じ字句ブロッ
ク内にない基本ブロックに制御を受け渡すまではCREATE
タプルの実行により存在する。（このことはダイナミッ
ク変数用のCREATEタプルを基本ブロックに割当てる必要
があることを意味し、この基本ブロックの有効範囲ブロ
ックは変数を宣言するブロックであり、さもなければ、
そのダイナミック記憶域は変数が有効範囲内にまだ字句
的にある間釈放される。） 2.未知サイズ コピー パラメータ用のスタック記憶域
を割当てるコードをENTRYタプルの直ぐ後に生成する。E
NTRYタプルは主ルーチン ブロックに必須であるため、
この記憶域はルーチンが戻るまで存在する。 3.ダイナミック テンポラリは集合式の値を保持するた
めにバック エンドにより創成することができる。この
テンポラリは少なくとも集合式の値を用いるタプルを実
行するまでその値を創成するタプルの実行により存在す
る。 4.集合ARGVAL_Xタプル用のアーギュメント値を保持する
ためにスタック スペースを割当てる。このスペースは
CALLタプルを実行するまでARGVAL_Xタプルの実行により
存在する。 5.スタック スペースをARGTMP_Xタプル用の戻り値を保
持するために割当てる。このスペースは戻り値をフェッ
チするRESULT_Xの実行により存在する。 本発明は上述した例のみに限定されるものではなく、幾
多の変更を加え得ること勿論である。 テーブル１ （ただし、以下の全角英文字及び記号は実際は半角入力
のものとし、全角アンダーライン２文字分は、実際は半
角アンダーバー２個分とする。） グローバル名及びエクスポーテッド名の プレフィックス変換規約 パッケージからエクスポートされた名前 ・ルーチン名は、GEM＄ZZ_nameの形式である。 ・エクスポーテッドマクロ名は、GEM＄ZZ_nameの形式で
ある。 ・グローバル変数名は、GEM＄ZZ_nameの形式である。 ・リテラル名（グローバル又はエクスポーテッドのいず
れであっても）は、 GEM＄ZZ_K_nameの形式である。 列挙データ型式 ・すべての列挙データ型式は、固有の「型式名」を有す
る。 ・型式XYZの各リテラルは、GEM＄XYZ_K_nameの形式の名
前を有する。 ・名前GEM＄XYZ_K_FIRST及び GEM＄XYZ_K_LASTは、データ型式の範囲の最初と最後の
値を参照する。 集合データ型式 ・各集合データ型式は、固有の「型式名」を有する。 ・集合型式XYZの各フィールドは、GEM＄XYZ_nameの形式
の名前を有する。 ・集合型式の特定の変数のサイズは、 GEM＄XYZ_name__SIZEの形式の名前を有するリテラルと
する。 ・集合型式の全体としてのサイズ（即ち、最大変数のサ
イズ）はGEM＄XYZ__SIZEである。 ・名前GEM＄XYZは、型式宣言マクロを参照し、その拡張
は、 BLOCK〔GEM＄XYZ__SIZE,BYTE〕FIELDS（GEM＄XYZ__FIEL
DS）である。 テーブル３ （ただし、以下の全角英文字及び記号は実際は半角入力
のものとし、全角アンダーライン２文字分は、実際は半
角アンダーバー２個分とする。） GEM＄XX_INIT これは、最初のアクションとしてシェル11により呼び出
される。 （GEM＄XX_INITを呼び出す前にシェルが行うことは、タ
イミングインターバルGEM＄TM_G_ICB_CMPTTL（〈REFERE
NCE〉の（sect_shell_tm）参照）をスタートし、デバッ
ギングパッケージ（〈REFERENCE〉の（sect_shell_db）
参照）を初期化し、“standard error"のアウトプット
ファイルハンドルに対してグローバル変数GEM＄CP_G_ER
ROR_FDBを初期化する。 GEM＄XX_INITからの戻る際に、以下に列挙する全てのGE
M＄XXグローバル変数は、適正に初期化される。他のフ
ロントエンド初期化もGEM＄XX_INITにおいて行われ、又
はGEM＄XX_PROCESS_GLOBALS（以下を参照のこと）まで
延期される。 GEM＄XX_INITの呼び出しを完了するまではシェル11はい
かなるコマンドライン処理を行わないため、VAX/VMSの
下で、LIB＄GET_FOREIGNを呼び出してコマンドラインを
読み取らせ、またCLI＄DCL_PARSEを呼び出してシェルが
処理するコマンドストリングをセットさせることによっ
てDCLコマンドの代わりに外部コマンドでGEM＄XX_INIT
によりGEMコンパイラを実行させる。 GEM＄XX_PROCESS_GLOBALS これは、コマンドラインからのグローバル修飾子（glob
al qualifie）を処理した後であって何からのコマンド
ラインパラメータ又はローカル修飾子を処理する前にシ
ェルによって呼び出される。このルーチンは、グローバ
ル修飾子ブロックを検討し、アクションが適正である限
りこのアクションをとることができる。 GEM＄XX_PROCESS_LOCALS これは、コマンドラインからのローカル修飾子を処理し
た後であって、ローカル修飾子によって特性されたファ
イル21をオープンする前にシェル11によって呼び出され
る。このルーチンは、ローカル修飾子ブロックを検討
し、所望の内容を変化させることができる。このことに
より、個別の修飾子ブロックでは表すことができない修
飾子間の依存性を可能にする。 GEM＄XX_COMPILE これは、ローカル修飾子ブロックに充填されたパラメー
タプラスリスト及びその修飾子を解析し、プラスリスト
によって特定された入力ストリームでGEM＄TIを初期化
した後にシェル11によって呼び出される。このルーチン
は、その入力ストリームをコンパイルするよう応答する
ことができる。 GEM＄XX_FINI これは、最終アクションとして抜け出るまえにシェルに
よって呼び出される。このルーチンは、フロントエンド
の特定クリーンアップを行う。 フロントエンドは、以下のグローバル変数を宣言しなけ
ればならない。グローバル変数は、GEM＄XX_INITが制御
をシェル11に戻す時間によって規定されねばならない
（グローバル変数はリンク時間で規定されるが、イメー
ジ起動時間でアドレスフィックスアップを必要とす
る）。 GEM＄XX_G_GLOBAL_QUALS これは、コンパイラのグローバル修飾子のための修飾子
ブロックに対するポインタのカウンテッドベクトルのア
ドレスを含む（〈REFERENCE〉の （sect_shell_cp）参照）。これらグローバル修飾子ブ
ロックは、シェルによって充填されてから GEM＄XX_PROCESS_GLOBALSを呼び出す。 GEM＄XX_G_LOCAL_QUALS これは、コンパイラのローカル修飾子のための修飾子ブ
ロックに対するポインタのカウンテッドベクトルのアド
レスを含む（〈REFERENCE〉の （sect_shell_cp）参照）。 これらグローバル修飾子ブロックはシェルによって充填
されてから、各グローバル修飾子ブロックがGEM＄XX_CO
MPILEを呼び出す。 GEM＄XX_G_FAC_PREFIX これは、コンパイラメッセージを構成するのに使用され
る機能ストリングを含む可変ストリングのアドレスを含
む。 GEM＄XX_G_FAC_NUMBER これは、コンパイラメッセージコードを構成するのに使
用する整数機能（integer facility）コードを含む。 GEM＄XX_G_IN_DEFAULTS これは、コマンドラインパラメータで特定されるソース
ファイルを開くときに使用するデフォルトファイル仕様
を含む可変ストリングに対するポインタのカウンテッド
ベクトルのアドレスを含む。 GEM＄XX_G_LIB_DEFAULTS これは、/LIBRARY修飾子でコマンドラインパラメータと
して特定されたテキストライブラリーを開くときに仕様
するデフォルトファイル仕様を含む可変ストリングに対
するカウンテッドベクトルのアドレスを含む。 GEM＄XX_G_PRODUCT_ID これは、作表（listing）ファイルのヘッダラインに仕
様されるプロダクト識別ストリングを含む可変ストリン
グのアドレスを含む。 GEM＄XX_G_PREFIX_LEN 作表ファイルのソースラインに添付されるプレフィック
スストリングのために確保されるコラム数を特定する整
数を含む。 ビジュアル メモリ パッケージ（GEM＄VM） ビジュアル メモリ パッケージは、ビジュアルメモリ
を割り当てるための標準インターフェースを提供する。 VMS LIB＄VMファシリティのゾーンメモリコンセプトを
支援する。実際VMSの下では、 GEM＄VMはLIB＄VM上のほとんどトランスペアレントなレ
イヤである。しかし、 GEM＄VMインターフェースはいかなるホストシステム上
でも変更されずに支援されるよう保証される。 ロケータ パッケージ（GEM＄LO） ロケータは、ソーステキスト15の範囲（起動ファイル及
び終了ファイル、ライン、及びコラムナンバー）を記述
する。テキスト入力パッケージは、ロケータをソースラ
インに戻してこのソースラインを読み取る。ロケータ
は、シンボルテーブル16及び中間言語ノードにも使用さ
れ、メッセージ及びデバッガテーブル生成を容易にし、
また作表ファイルのどこで作表パッケージをアクション
をとるかを特定するのに使用される。ロケータはロング
ワードとして表される。ロケータパッケージは、ロケー
タデータベースを維持し、ロケータを生成し、ロケータ
に割り込むルーチンを提供する。テーブル４ 中間言語定義ファイル GEM＄ND_NODES.SDL これは、幾つかの一般型式の定義を含み、以下に列挙す
るSDLファイルの全てを含む。これはまた、ジェネリッ
ク（全体的な）GEM＄NODE集合体の型式を含む。 GEM_CONSTANTS.DAT これは、ノードの種類及びノードの副種類（subkind）
の列挙された型式並びに種々の他の列挙された型式の定
義を含む。 GEM_CONSTANTS.SDL GEM_CONSTANTS.DATのSDL翻訳である。翻訳を行うCONSTA
NTSプログラムを記述するための付録（アベンディック
ス）Ｄを参照されたい。 BLK_NODE.SDL これは、ノード種類フィールドにおける GEM＄NODE_K_BLOCKの値によって識別されるブロックノ
ード（GEM＄BLOCK_NODE）の定義を含む。 SYM_NODE.SDL これは、ノード種類フィールドにおける GEM＄NODE_K_SYMBOLの値によって識別されるシンボルノ
ード（GEM＄SYMBOL_NODE）の定義を含む。 FRM_NODE.SDL これは、ノード種類フィールドにおける GEM＄NODE_K_FRAMEの値によって識別されるフレームノ
ード（GEM＄FRAME_NODE）の定義を含む。 LIT_NODE.SDL これは、ノード種類フィールドでの GEM＄NODE_K_LITERALの値によって識別されるリテラル
ノード（GEM＄LITERAL_NODE）の定義を含む。 PRM_NODE.SDL これは、ノード種類フィールドでの GEM＄NODE_K_PARAMETERの値によって識別されるパラメ
ータノード （GEM＄PRAMETER_NODE）の定義を含む。 TPL_NODE.SDL これは、ノード種類フィールドでの GEM＄NODE_K_CIL_TUPLEの値によって識別される組（タ
プル:Tuple）ノード （GEM＄TUPLE_NODE）の定義を含む。 DES_NODE.SDL これは、ノード種類フィールドでの GEM＄NODE_K_DESTINATIONの値によって識別される組
（タプル）ノード （GEM＄DESTINATION_NODE）の定義を含む。 GEM＄ND.L32 BLISSでコード化されたフロントエンドにより使用され
るライブラリファイルである。これは、上に列挙したフ
ァイルのBLISS翻訳を含む。テーブル５ シンボルテーブル及びILルーチンルーチン （目的）初期化及び終了 GEM＄ST_INIT （モジュールのための中間表現を初期化する） GEM＄ST_FINI （モジュールの中間表現用に割当てられた全てのスペー
スを解除する。）ILGsの生成及び操作 GEM＄IL_ALLOCATE_CIL_NODE （CIL組ノードを割り当てる） GEM＄IL_ALLOCATE_DES_NODE （宛先ノードを割り当てる） GEM＄IL_FREE_DES_NODE （宛先ノードの割り当てを解除する） GEM＄IL_INSERT （一つの組又は組リストを組リストに挿入する） GEM＄IL_UNLINK （組リストから一つの組を取り外す）シンボルテーブルの生成 GEM＄ST_ALLOCATE_BLOCK_NODE （ブロックノードを割り当てる） GEM＄ST_ALLOCATE_FRAME_NODE （記憶フレームノードを割り当てる） GEM＄ST_ALLOCATE_MUTABLE_SYMBOL （副種類を変更できるシンボルノードを割り当てる） GEM＄ST_ALLOCATE_PARAMETER_NODE （パラメータリストノードを割り当てる） GEM＄ST_ALLOCATE_SYMBOL_NODE （副種類を変更できないシンボルノードを割り当てる） GEM＄ST_LOOKUP_LITERAL （特定リテラル値のためのリテラルノードを得る） GEM＄ST_LOOKUP_PSECT （特定名を有するPSECT記憶フレームノードを得る） GEM＄ST_MUTATE_SYMBOL （ミュータブルシンボルノードの副種類を変更する）指定初期値 GEM＄ST_STORE_ADDRESS （変数又はPSECTの初期値としてシンボル又はPSECTアド
レスを指定する） GEM＄ST_STORE_BUFFER （変数又はPSECTの初期値としてバイトの任意ブロック
を指定する） GEM＄ST_STORE_LITERAL （変数又はPSECTの初期値としてリテラルノードの値を
指定する） テーブル6a 帰納(Induction)変数検出のための新規組(TuPle)フィー
ルド IV_IS_INDUCTIVE- TUPLEがループトップTUPLE〔IV_LOOP〕により指定され
るループに関して帰納表現であることを示すフラッグ。
FIND_IVアルゴリズムの終わりに、この組（タプル）
は、IV_BASICがIV_LOOPで指定されるループのBASIC_IVS
セットにある場合にのみ帰納的になる。 IV_BASIC- TUPLEの基本帰納変数候補である。FIND_IVアルゴリズム
が完了した後にIV_BASICがIV_LOOPの基本帰納変数セッ
トにない場合、この組（タプル）は帰納的でない。 IV_LOOP TUPLEがループ内の帰納的である最も内側ループのルー
プトップ。 IV_NON_CONSTANT IV_COEFFICIENT- 各帰納表現Ｅは基本帰納変数Ｉのニリア関数を定義す
る。即ち、Ｅは次式によってＩの項において再計算され
る。即ち、 Ｅ＝（ａ＊Ｉ）＋ｂ ただし、「ａ」はリニア関数の「係数」であり、「ｂ」
は「オフセット」である。IV_COEFFICIENTフィールド
は、係数の定数部分を含む整数フィールドである。 IV_NON_CONSTANTフィールドは、係数が不定部分を有す
ることを示すフラグである。新規フローノードフィールド BASIC_IVS- 「この（This）」ループトップにより表されるループの
ための基本帰納変数候補セットである。初めは、これは
ループにおいて変更されるすべての変数セットである。 アルゴリズムFIND_IVは基本帰納変数のループに従わな
い変数を排除する。ループトップに対してのみ有効であ
る。 CONDITIONAL_SET- 「この（This）」ループトップにより表されるループに
より、各完全トリップ毎に正確に実行されない記憶を有
する変数セット。このセットに存在することは、変数が
帰納変数であることを意味しない。ループトップに対し
てのみ有効である。テーブル７ 共通組（コモンタプル:Common Tuple）フィールドField 意味 種類（Kind） すべてのノードで生ずる総称ノード種類フィード。 全体演算子（Generic operator） 組（タプル）によって行われる一般的演算（オペレーシ
ョン）。これはすべてのノードで生ずる全体的副種類フ
ィールドの他の名前である。 演算子型式（Operator type） 全体演算子に関連して組により実行される特定演算を決
定するデータ型式。 演算子型式は、常にではないが、組における１個又はそ
れ以上のオペランド（特に第１番目のオペランド）のデ
ータ型式と同一であるのが一般的である。組によって計
算される値のデータ型式とは必ずしも同じではない。例
えば、ADD.INT16は２個のオペランドINT16を加算し、 結果INT16を生ずるが、 LSS.INT16は２個のオペランドINT16を比較し、 結果BOOLを生じ、 STORE.INT16は 値INT16をメモリ位置に記憶し、 結果を持たない。 結果型式（Result type） この組により計算される値の型式。たいていの演算子に
関しては、結果型式は演算子型式によって決定される
が、幾つかの演算子に関しては、結果型式は演算子型式
とは独立しており、組により実行される特定演算は双方
の型式に左右される。 オペランド（Operands） この組のオペランドに対するポインタのアレイ。オペラ
ンドの数は全体演算子により決定される。各オペランド
ポインタは他のIL組ノード又はCILにおいてのみシンボ
ル又はリテラルノードを指し示す。個別のオペランドポ
インタフィールドは op1,op2等と称する。 次組（Next tuple） 組の２重リンク組リストにおける次の及び直前の組に対
するポインタである。つぎの組オーダーは、評価の暗黙
オーダーである。CILにおいて、ILGのすべての組はとも
にリンクするとともに、EILにおいて各基本ブロックの
組は個別のリストを形成する。 ロケータ（Locator） この組にコンパイルされたトークン又はトークン群のプ
ログラムソースにおけるテキスト的な位置である。エラ
ーメッセージ、ソース相関テーブル等を構成するのに使
用する。（ロケータはGEM＄LOパッケージ仕様に記載さ
れている。） Exprカウント（Expr count） バックエンドによりセットれれたEILでのみ使用され
る。 Exprカウントフィールドは、CT.029の効果表現インター
フェースにおいて記載されている。 テーブル９ データアクセス演算子（Data Access Operator）演算子 意味 (Operator) フェッチ演算子(Fetch Operators) お FETCH 表現的値をフェッチする。 FGTCHA パックドアレイ（packed array）素子 から符号表現を有する符号付き整数又 はゼロ拡張を有するアドレス整数又は 符号なし整数をフェッチする。 FETCHF 特定の長さを有する文字ストリング、 又はビットストリングをフェッチする。 FETCHS 文字サブストリング又はビットサブ ストリング即ち、基本アドレスからオ フセットした特定の長さの特定の文字 又はビットを有するストリングをフェ ッチする。 FETCHV 可変長文字ストリング即ち、長さが ストリングのテキストに先行するワー ドにある文字ストリングをフェッチす る。 FETCHX ビットフィールドから符号拡張を有 する符号付き整数又はゼロ拡張を有す るアドレス整数又は符号なし整数をフ ェッチする。 FETCHZ 空白終了(null-terminating)文字ス トリングをフェッチする。 FETCHZA パックドアレイ素子からゼロ拡張を 有する符号付き整数をフェッチする。 FETCHZX ビットフィールドからゼロ拡張を有 する符号付き整数をフェッチする。 記憶演算子(Store Opetators) STORE 表現的値を記憶する。 STOREA パックドアレイ素子の整数値又はア ドレス値を記憶する。 STOREF 文字ストリング又はビットストリン グを記憶する。 STORES 文字サブストリング又はビットサブ ストリング即ち、基本アドレスからオ フセットした特定の長さの特定の文字 又はビットを有するストリングを記憶 する。 STOREV 可変長文字ストリング即ち、ストリ ングの長さを含むワードに付随するス トリングのテキストを記憶する。 STOREX ビットフィールドの整数値又はアド レス値を記憶する。 STOREZ 空白終了文字ストリング即ち、空白 文字（全てのゼロビット）が後に付随 するストリングのテキストを記憶する。 VSTORE 算術値又はアドレス値を記憶し、記 憶した値を生成する。 VSTOREA パックドアレイ素子の整数値又はア ドレス値を記憶し、記憶した値を生成 する。 VTOREX ビットフィールドの整数値又はアド レス値を記憶し、記憶した値を生成す る。 増分演算子(Increment Operators) POSTINCR 変数から表現的値をフェッチし、コ ンパイル時定数増分をそれに加算し、 この結果をメモリに戻して記憶し、初 期（非増分の）値を生成する。 POSTINCRA バックドアレイ素子から表現的値を フェッチし、コンパイル時定数増分を それに加算し、この結果をメモリに戻 して記憶し、初期（非増分の）値を生 成する。 POSTINCRX ビットフィールドから表現的値をフ ェッチし、コンパイル自定数増分をそ れに加算し、この結果をメモリに戻し て記憶し、初期（非増分）の値を生成 する。 PREINCR 変数から表現的値をフェッチし、コ ンパイル時定数増分をそれに加算し、 この結果をメモリに戻して記憶し、初 期（増分）の値を生成する。 PREINCRA パックドアレイ素子から表現的値を フェッチし、コンパイル時定数増分を それに加算し、この結果をメモリに戻 して記憶し、初期（増分の）値を生成 する。 PREINCRX ビットフィールドから表現的値をフ ェッチし、コンパイル時定数増分をそ れぞれに加算し、この結果をメモリに戻し て記憶し、初期（増分の）値を生成す る。 可変変更演算子 (Variable Modification Operators) これら演算子は、変数、パックドア レイ素子又はビットフィールドから値 をフェッチし、フェッチした値と他の オペランド値との間の算術的演算を行 い、算術演算の結果をオリジナルのメ モリに戻して記憶し、更新した値を生 成する。 ADDMOD ADDMODA ADDMODX （上の３つは或る値をメモリ位置の算 術的値に加算する。） DIVMOD DIVMODA DIVMODX （上の３つはメモリ位置の算術的値を 或る値で減算する。） IANDMOD IANDMODA IANDMODX （上の３つは或る値でメモリ位置の整 数値の「論理積（And）」をとる。） IORMOD IORMODA IORMODX （上の３つは或る値でメモリ位置の整 数値の「論理和（Or）」をとる。） IXORMOD IXORMODA IXORMODX （上の３つは或る値でメモリ位置の整 数値の「排他的論理和（Or）」をとる。） MULMOD MULMODA MULMODX （上の３つは或る値でメモリ位置の整 数値を乗算する。） REMMOD REMMODA REMMODX （上の３つは或る値によりメモリ位置 の整数値を除算した剰余をとる。） SHRMOD SHRMODA SHRMODX （上の３つは或る値だけメモリ位置の 整数値を右側にシフトする。） SUBMOD SUBMODA SUBMODX （上の３つはメモリ位置の整数値から 或る値を減算する。） テーブル11 算術演算子（Arithmetic Operators）演算子 意味 フェッチ演算子 FETCH 表現的値をフェッチする。 FETCHA パックドアレイ素子から符号拡張を有する 符号付き整数又はゼロ拡張を有するアドレス 又は符号のない整数をフェッチする。 FETCHX ビットフィールドからパックドアレイ素子 から符号拡張を有する符号付き整数又はゼロ 拡張を有するアドレス又は符号のない整数を フェッチする。 FETCHZA パックドアレイ素子からゼロ拡張を有する 符号付き整数をフェッチする。 FETCHZX ビットフィールドからゼロ拡張を有する符 号付き整数をフェッチする。 記憶演算子（Store Operator） STORE 表現的値を記憶する。 STOREA パックドアレイ素子の整数又はアドレス値 を記憶する。 STOREX ビットフィールドの整数又はアドレス値を 記憶する。 VSTORE 算術的値又はアドレス値を記憶し、記憶し た値を生成する。 VSTOREA パックドアレイ素子の整数又はアドレス値 を記憶し、記憶した値を生成する。 VSTOREX ビットフィールドの整数又はアドレス値を 記憶し、記憶した値を生成する。 算術的計算（Arithmetic Computation） ABS オペランドの絶対値を計算する。 ADD オペランドの合計を計算する。 CADD 複素数オペランドと実数オペランドの合計 を計算する。 CDIV 複素数オペランドと実数オペランドの商を 計算する。 CEIL 実数オペランドの値以上の最小整数を計算 する。 CMUL 複素数オペランドと実数オペランドの積を 計算する。 CONJG オペランドの共役複素数を計算する。 CREVSUB 複素数オペランドと実数オペランドの差を 計算する。 CSUB 複素数オペランドと実数オペランドの差を 計算する。 DIV ２個のオペランドの商を計算する。 FLOOR 実数オペランドの値以下の最大整数値を計 算する。 IPWR 第１オペランドを整数の第２オペランドの 累乗に計算し、双方のオペランドがゼロの場 合にエラーの信号を発生する。 IPWRO 第１オペランドを整数の第２オペランドの 累乗に計算し、双方のオペランドがゼロの場 合に一方を生成する。 IPWRZ 第１オペランドを整数の第２オペランドの 累乗に計算し、双方のオペランドがゼロの場 合にゼロを生成する。 MAX オペランドの最大を計算する。 MIN オペランドの最小を計算する。 MOD オペランドの数学的係数を計算する。 （Ada及びPL/IMOD演算子）。 MUL オペランドの積を計算する。 NEG オペランドの負の補数又は２の補数を計算 する。 PMOD 除数が正でなければならないオペランドの 数学的係数を計算する（Pascal MOD演算 子）。 PWR 第１オペランドを第２オペランドの累乗に 計算し、双方のオペランドがゼロの場合にエ ラーの信号を発生する。 PWRO 第１オペランドを第２オペランドの累乗に 計算し、双方のオペランドがゼロの場合に一 方を生成する。 PWRZ 第１オペランドを第２オペランドの累乗に 計算し、双方のオペランドがゼロの場合にゼ ロを生成する。 REM オペランドの剰余を計算する。 （FORTRAN MOD関数、BLISS MOD演算子、Ｃ％演算子、及びPascal及 びAda REM演算子）。 ROUND 実数の小数部分を近似整数値に丸める。 SUB オペランドの差を計算する。 TRUNC 実数の小数部分をゼロに切り捨てる。 桁送り（Shifting）及びマスキング IAND ２個の整数のビット論理積を計算する。 IEQV ２個の整数のビット等価を計算する。 INOT 整数のビット補数を計算する。 IOR ２個の整数のビット論理和を計算する。 IXOR ２個の整数のビット排他的論理和を計算す る。 ROT 整数値を回転させる。 SHL 正の桁送り数（シフトカウント）によって 整数値を左に桁送り（シフト）する。 SHR 正の桁送り数（シフトカウント）によって 整数値を右に桁送り（シフト）する。 SH 桁送り数（シフトカウント）の符号に基づ いて整数の値を左又は右に桁送り（シフト） する。 数学的計算（Mathematical Computations） ACOS オペランドのラジアンのアークコサインを 計算する。 ACOSD オペランドの度数（degrees）のアークコサ インを計算する。 ASIN オペランドのラジアンのアークサインを計 算する。 ASIND オペランドの度数のアークサインを計算す る。 ATAN オペランドのラジアンのアークタンジェン トを計算する。 ATAND オペランドの度数のアークタンジェントを 計算する。 ATAN2 ２個のオペランドの比のラジアンでのアー クタンジェントを計算する。 ATAN2D ２個のオペランドの比の度数でのアークタ ンジェントを計算する。 COS ラジアンで特定されるオペランドの余弦を 計算する。 COSD 度数で特定されるオペランドの余弦を計算 する。 COSH オペランドの双曲線余弦を計算する。 EXP オペランドの指数（ｅの累乗）を計算する。 LOG オペランドのｅを底とする対数を計算する。 LOG2 オペランドの２を底とする対数を計算する。 LOG10 オペランドの10を底とする対数を計算す る。 SIN ラジアンで特定されるオペランドの正弦を 計算する。 SIND 度数で特定されるオペランドの正弦を計算 する。 SINH オペランドの双曲線正弦を計算する。 SQRT オペランドの平方根を計算する。 TAN ラジアンで特定されるオペランドの正接を 計算する。 TAND 度数で特定されるオペランドの正接を計算 する。 TANH オペランドの双曲線正接を計算する。 変換（Conversion） CAST 若干の他の型式の幾つかの値として同一の ビットパターンを有する算術的型式の値を生 成する。 CMPLX ２個の実数オペランドから複素数を構成す る。 CVT １個の算術的型式の値を他の算術的型式の 値に翻訳する。 IMAG 複素数の虚数部分をとる。 REAL 虚数の実数部分をとる。 ROUND 小数部分を丸めることにより実数を整数値 に変換する。 TRUNC 小数部分をゼロに切り捨てることにより実 数を整数値に変換する。 XCVT 変換した値の表現における過剰に大きいビ ットを切り捨てることにより１個の整数型式 の値を他の整数型式に変換する。 比較（Comparisons） EQL １個の算術的値が他の値に等しい場合にテ ストする。 GEQ １個の算術的値が他の値より大きいか、又 は等しい場合にテストする。 GTR １個の算術的値が他の値より大きい場合に テストする。 LSS １個の算術的値が他の値より小さい場合に テストする。 LEQ １個の算術的値が他の値より小さいか、又 は等しい場合にテストする。 NEQ １個の算術的値が他の値とは異なる場合に テストする。 変数変更演算子 Variable Modification Operator） ADDMOD ADDMODA ADDMODX （上記３つは、メモリ位置における算術的値 に或る値を加算する。） DIVMOD DIVMODA DIVMODX （上記３つは、メモリ位置における算術的値 を或る値で除算する。） IANDMOD IANDMODA IANDMODX （上記３つは、メモリ位置における整数値を 或る値で「論理積」をとる。） IORMOD IORMODA IORMODX （上記３つは、メモリ位置における整数値を 或る値で「論理和」をとる。） IXORMOD IXORMODA IXORMODX （上記３つは、メモリ位置における整数値を 或る値で「排他的論理和」をとる。） MULMOD MULMODA MULMODX （上記３つは、メモリ位置における算術的値 を或る値で乗算する。） REMMOD REMMODA REMMODX （上記３つは、メモリ位置における算術的値 の或る値に対する剰余をとる。） SHLMOD SHLMODA SHLMODX （上記３つは、メモリ位置における整数を或 る値だけ左に桁送りする。） SHRMOD SHRMODA SHRMODX （上記３つは、メモリ位置における整数を或 る値だけ右に桁送りする。） SUBMOD SUBMODA SUBMODX （上記３つは、メモリ位置における算術的値 から或る値を減算する。） 増分演算子（Increment Operators） POSTINCR POSTINCRA POSTINCRX （上記のつは、それぞれ変数、パックドアレ イ素子又はビットフィールドから表現的値を フェッチし、フェッチしたものにコンパイル 時定数増分だけ加算し、この結果をメモリ内 に戻して記憶し、初期値（非増分値）を生成 する。） PREINCR PREINCRA PREINCRX （上記３つは、それぞれ変数、パックドアレ イ素子又はビットフィールドから表現的値を フェッチし、フェッチしたものにコンパイル 時定数増分だけ加算し、この結果をメモリ内 に戻して記憶し、増分値を生成する。） テーブル12 文字及びビットストリング演算子 （Character and Bit String Operators） 演算子 意味 フェッチ演算子(Fetch Operators) FETCHF 特定長さの文字ストリング又はビットス トリングをフェッチする。 FETCHS 特定長さ及び特定文字を有するストリン グがベースアドレスからオフセットする文 字サブストリング又はビットサブストリン グをフェッチする。 FETCHV 長さがストリングのテキストに先行する ワークにある可変長さ文字ストリングをフ ェッチする。 FETCHZ 空白終了文字ストリングをフェッチする。 記憶演算子（Store Operators） STOREF 文字又はビットストリングを記憶する。 STORES 特定長さ及び特定文字を有するストリン グがベースアドレスからオフセットする文 字サブストリング又はビットサブストリン グを記憶する。 STOREV 可変長さ文字ストリングを記憶する即ち、 ストリングがストリングの長さを含むワー ドに後続する場合にテキストを記憶する。 STOREZ 空白終了文字ストリングを記憶する即ち、 空白文字（全てのゼロビット）が後続する ストリングのテキストを記憶する。 ストリング操作(String Mamipulations) CONCAT 他のストリングの全ての素子が後続する １個のストリングの全ての素子よりなるス トリングを計算する。 FILL 特定文字の複写（copy）を有する特定長さ に埋め込んだ文字ストリングの複写を生成 する。 REPLECATE 他のストリングの特定数の複写連結であ るストリングを生成する。 SUBSTR 特定開始位置及び長さを有する特定スト リングからサブストリングを抜き出す。 TRANSLSTE 翻訳テーブルとして他の文字ストリン グを使用して１個の文字ストリングの複写 を生成する。 ビットストリング論理演算子 （Bit String Logical Operators） BAND ２個のビットストリングのビット論理 積（“set intersection"）を計算する。 BDIFF ２個のビットストリングのビット差 （“set subtraction"）を計算する。 BEQV ２個のビットストリングのビット 等価（equivalence）を計算する。 BNOT ビットストリングの否定 （“set complement"）を計算する。 BOR ２個のビットストリングのビット論理和 （“set union"）を計算する。 BXOR ２個のビットストリングのビット排他的 論理和（“set difference"）を計算す
る。 変換（Conversions） ELEMENT 文字ストリング又はビットストリングか ら１個の素子を抜き出し、CHAR又は IMAXゼロ又は１として生成する。 SCAST 或る他の値と同一のビットパターンを有 するストリングを生成する。 USTRING 単独の文字よりなるストリングを生成す る。 位置及びサイズ関数 （Position and Size Functions） INDEX 他のストリング内の１文字ストリングの 第１出現位置を計算する。 LENGTH ストリングの長さを計算する。 PINDEX 他のストリング内の１個のストリングの 第１出現位置を計算するが、双方のストリ ングが空の場合、１を生成する。 PSEARCH 他の文字ストリング内にも見られる１文 字ストリングの第１文字の位置を計算する が、双方のストリングが空の場合、１を生 成する。 PVERIFY 他の文字ストリング内にも見られない１ 文字ストリングの第１文字の位置を計算す るが、双方のストリングが空の場合、１を 生成する。 SEARCH 他の文字ストリング内にも見られる１文 字ストリングの第１文字の位置を計算す
る。 VERIFY 他の文字ストリング内にも見られない１ 文字ストリングの第１文字の位置を計算す
る。 非埋込み比較（Unpadded Comparsons） EQL １個のストリングが他のストリングに等 しい場合にテストする。 GEQ １個のストリングが他のストリングより も大きいか、又は等しい場合にテストす
る。 GTR １個のストリングが他のストリングより も大きい場合にテストする。 LEQ １個のストリングが他のストリングより も小さいか、又は等しい場合にテストす
る。 LSS １個のストリングが他のストリングより も小さい場合にテストする。 NEQ １個のストリングが他のストリングとは 異なる場合にテストする。 埋込比較（Padded Comparisons） EQLP １個の埋め込みストリングが他のストリ ングに等しい場合にテストする。 GEQP １個の埋め込みストリングが他のストリ ングよりも大きいか、又は等しい場合にテ ストする。 GTRP １個の埋め込みストリングが他のストリ ングよりも大きい場合にテストする。 LEQP １個の埋め込みストリングが他のストリ ングよりも小さいか、又は等しい場合にテ ストする。 LSSP １個の埋め込みストリングが他のストリ ングよりも小さい場合にテストする。 NEQP １個の埋め込みストリングが他のストリ ングとは異なる場合にテストする。 セット構造子（Set Constructors） BRANGE ビットの連続シーケンスを既存のビット ストリングの一つにセットすることにより 新規なビットストリングを生成する。 BSINGLE 単独のビットを既存のビットストリング のうちの一つにセットすることにより新規 なビットストリングを生成する。 ZEROBITS 特定数のゼロビットのビットストリング を生成する。 セット叙述（Set Predicates） MEMBER ビットストリングが特定インデックスで の１ビットを有するか否かをテストする。 SUPERSET ビットストリング内の全ての１ビットが 他のビットストリングの１ビットでもある か否かをテストする。 SUBSET ビットストリング内の全ての１ビットが 他のビットストリングの１ビットでもある か否かをテストする。 テーブル17 種々のソース言語のためのパラメータセマンティックフ
ラグの設定（セッティング）言語セマンティック Expose/ConcealAlias Effects Input/Output BLISS parameters Don′t care Input C parameters Don′t care Input Standard FORTRAN parameters Don′t care Input/Ou
tput （Old）VAX FORTRAN parameters Expose Input/Outpu
t Pascal value parameters Conceal Input Pascal vAR parameters Expose Input/Output Ada atomic parameters Conceal see Note Ada aggregate parameters Don′t care see Note PL/I parameters Expose Input/Output Note:Adaルーチン宣言におけるパラメータ仕様のIN変更
子,OUT変更子，又はIN OUT変更子によって特定される。 テーブル20 引き数（Argument）のタプル又は組（Tuples）の属性
（Attributes）属性 意味 Pass by register 引き数が、特定のレジスタ又は特定アーキテクチャのシ
ステムコール標準によって決定される位置に渡されるか
否かを指示する。真であれば、引き数は識別子（GEM＄T
S_REG列挙型式からの）がarg位置フィールドにあるレジ
スタに渡される。偽であれば、arg位置は単にこのコー
ルの全ての非レジスタ引き数のうちの１オリジンインデ
ックスであり、GEMは適正な「標準」引き数位置を決定
する。（GEMはarg位置で特定される引き数位置をオーバ
ーライトし、利用できる呼出ルーチン及び被呼ルーチン
の双方を有する場合にレジスタによって渡し、必要な分
析を行う。） Special register Pass by registerが真である場合にのみ真であるとし、
この場合、GEMは特定レジスタを使用しなければならな
い。 Arg location2 Pass by register2 メカニズムがリファレンスである場合のみ関連し、この
場合、これらフィールドは、引き数長さが値によって渡
される引き数位置を特定する。Arg location2に渡たれ
ない長さは０である。 Parm is read 真である場合に、GEMが、被呼ルーチンは渡される実際
の引き数位置の内容を検査することを仮定する指示をす
るフラグ（メカニズムが値でない場合のみ意味があ
る。） Parm is written 真である場合に、GEMが被呼ルーチンは渡される実際の
引き数位置の内容を修飾することを仮定する指示するフ
ラグ（メカニズムが値でない場合のみ意味がある。） Desc size メカニズムがジェネラルである場合即ち、引き数を渡す
よう割当てる記述子のサイズである場合のみ意味があ
る。 Offset 実引き数アドレスを組のアドレスオペランドからオフセ
ットすることを特定する種々のARGADRの組においてのみ
使用される。 Effects 引き数を渡すことにより生ずる 「read」サイドエフェクトを特徴付ける種々のARGADRの
組においてのみ使用される。 Effects2 引き数を渡すことにより生ずる 「write」サイドエフェクトを特徴付ける種々のARGADR
の組においてのみ使用される。 Base Symbol 既知であるアドレスが渡されている変数のシンボルノー
ドを指し示すポインタである種々のARGADRの組において
のみ使用される。 付録 翻訳機制御アクション 以下のアクションはアクション翻訳機の実行フローを制
御する。 アクション（〈結果 バル リスト〉；〈一時 バル
リスト〉）はテンプレートのアクションシーケンスの開
始をマークする。これはそれがオペランド変数を割り付
けるから、テンプレートの第１アクションでなければな
らない。双方のバル リスト（var-list）の内容はテン
プレートの残りの期間にオペランド変数の命名に使用さ
れた識別子のコンマで区切られたシーケンスである。も
しテンプレートがいずれの結果オペランド（result ope
rand）もしくは一時オペランド（temporary operand）
を使用しないなら、これらのバル リストのいずれかは
空である。 結果 バル リザルト中の識別子は結果オペランドの名
前である。ボイド コンテキストのILGノードは０結果
オペランドを有し、一方、他のたいていの表現は１結果
オペランドを有している。例外は、２もしくは３オペラ
ンド（１つはストリング本体をアドレスし、１つはスト
リング長に対するものであり、そして他の１つはストリ
ング本体を保持する）を要求するストリング結果と、２
オペランド（１つは実成分に対するもの、他は虚成分に
対するもの）を要求する複合結果とを含んでいる。 遅延（DELAY）は遅延しないアクションの終了と遅延さ
れたアクションの開始をマークする。遅延アクションが
翻訳されると、現行テンプレートの処理は、対応ILGサ
ブツリーが親サブツリーのリーフとして使用されるまで
一時停止される。親サブツリーのテンプレートが対応リ
ーフを遅延しないなら、翻訳は遅延アクションに続くア
クションを継続しよう。 イグジット（出口）はアクションシーケンスの翻訳を終
了する。イグジットアクションの翻訳は結果オペランド
を戻し、残りのオペランド変数と局部TNを解放し、かつ
このアクションシーケンスを遅延しないテンプレートに
より翻訳を再開する。 終了＿アクションはアクションシーケンスの終了をマー
クする。それは翻訳されないから真のアクションではな
い。終了＿アクションオペレーションはアクションシー
ケンスの字句的に最終の成分でなければならない。この
オペレーションはアクションオペレーションで宣言され
たオペランド識別子の範囲の終端をマークする。 非遅延（リーフ,opr1,opr2,....）は特定パターン「リ
ーフ」の遅延コンテキクスト アクションを処理する。
リーフの結果オペランドは「opr1」，「opr2」等のオペ
ランド変数にコピーされる。コピーされたオペランドの
数はリーフのテンプレートの結果オペランドの数と整合
しなければならない。 ラベル（名前）はアクションシーケンス中の現行位置に
「名前」を標識（label）する。 ゴーツー（名前）は翻訳機を分岐し、かつ「名前」によ
り特定されたラベルに続くアクションで処理を継続す
る。 TN割り付けと寿命アクション 増分_LON（ ）はTNの寿命の決定に使用された線形次数
ナンバ（Linear Order Number）クロック変数を増分す
る。 使用（オペランド）は特定オペランド変数を参照する。
このアクションはオペランドが使用されるテンプレート
の最後の場所をマークするのに使用され、かつ寿命を適
当に延長する。 割り付け＿永久（オペランド、サイズ）は「サイズ」バ
イトの永久クラスTN（permanent class TN）を創生し、
かつ特定「オペランド」変数により参照する。もし「サ
イズ」パラメータが喪失されると、TNのサイズは現行テ
ンプレートの結果データタイプにより決定される。この
アクションはコンテキストが通過する間にTNを創生する
のみである。TNバインド（TNBIND）およびコードが通過
する間にいかにしてこのTNがアクセスされるかの記述に
ついてセーブ_TNアクションを見よ。 割り付け＿遅延された（オペランド、サイズ）は「サイ
ズ」バイトの遅延クラスTNを創生し、かつ特定「オペラ
ンド」変数により参照される。もし「サイズ」パラメー
タが喪失すると、TNのサイズは現行テンプレートの結果
データ タイプにより決定される。このアクションはコ
ンテキスト、TNバインドおよびコードの各々が通過する
間にTNを創生する。このアクションは実行されないが、
一方、遅延されないアクションを翻訳する。このTNの寿
命はこのTNを使用する結果が使用される場合に終了す
る。 割り付け＿局部（オペランド、サイズ）は「サイズ」バ
イトの局部クラスTNを創生し、かつ特定「オペランド」
変数により参照される。もし「サイズ」パラメータが喪
失すると、TNのサイズは現行テンプレートの結果データ
タイプにより決定される。このアクションはコンテキス
ト、TNバインドおよびコードの各々が通過する間にTNを
創生する。このTNの寿命はその創生と同じテンプレート
で終了しなければならない。 フォース＿レジスタ（オペランド）は「オペランド」変
数で特定されたTNをメモリにあってはならないようにマ
ークする。このことはどのレジスタもTNが割り付けられ
ない場合に利用可能でない限りレジスタへの割り付けを
一般に意味している。 フォース＿メモリ（オペランド）は「オペランド」変数
で特定されたTNをレジスタにあってはならないようにマ
ークする。このことはスタック位置への割り付けを一般
に保証する。 マスト（MUST）＿割り付け（オペランド）は「オペラン
ド」変数で特定されたTNを割り付けなくてはならぬよう
マークする。 註：フォース＿レジスタ、フォース＿メモリおよびマス
ト＿割り付けのすべての３つが、これら３つの条件と同
じTN上で矛盾し、かつすべて満足できないようにするこ
とは誤りである。 優先（opr1、opr2）もし「オペランド」がレジスタに割
り付けられるなら、「オペランド２」は同じレジスタに
割り付けられ、さもなければ「オペランド２」は「オペ
ランド１」とは独立に割り付けられる。「オペランド
２」を「オペランド１」と同じレジスタに強制すること
は、たとえ「オペランド１」と「オペランド２」が競合
する寿命を有していても生起する。（優先アクションに
優先する「委任（mandatoru）」に対抗して優先する
「勧告（advisory）」の移動＿値アクション（MOVE_VAL
UE action）を見よ）。 増分＿コスト（ナンバー、オペランド）は量「ナンバ
ー」だけ「オペランド」により特定されたTNの非割り付
けのコストを増大する。 リザーブ_R0（ナンバー）は連続レジスタの「ナンバ
ー」がレジスタ０による開始を維持するようにする。 テスト＿メモリ（オペランド、ラベル）は特定「オペラ
ンド」変数により参照されたTNをテストする。もしTNが
メモリなら、アクション翻訳機は特定「ラベル」に分岐
する。コンテキストとTNバインドが通過する間に、この
アクションは、フォース＿メモリが行われない限り、割
り付けられないTNがメモリに存在しないことを仮定す
る。 テスト＿レジスタ（オペランド、ラベル）は特定の「オ
ペランド」変数により参照されたTNをテストする。もし
TNがレジスタなら、アクション翻訳機は特定「ラベル」
に分岐する。コンテキストとTNバインドが通過する間
に、このアクションは、フォース＿メモリがTNで行われ
ない限り、割り付けられないTNがレジスタにあることを
仮定する。 ILG負荷とセーブアクション 負荷＿リテラル（ノード、オペランド）はテンプレート
パターンにより整合された特定「ノード」のリテラル値
を特定「オペランド」変数に負荷する。もし「ノード」
がリテラルでないなら、それは誤りである。 セーブ_TN（オペランド、ノード、フィールド）は「オ
ペランド」変数により特定された永久クラスTNへの参照
をセーブする。コンテキストが通過する間に、TNポイン
ターはテンプレートの特定「ノード」により整合された
ILGタペル（ILG tuple）の成分「フィールド」でセーブ
される。TNバインドとコードが通過する間に、この情報
は特定「ノード」の特定の「フィールド」からフェッチ
される。各永久クラスTNは、TNバインドとコードが通過
する間に同じTNが位置できるように、コンテキストが適
当なILGフィールドを通過する間にセーブされなければ
ならない。遅延クラスと局部クラスTNはそれらが決して
セーブされるべきでないように各通過を再創生する。 セーブ＿オペランド（オペランド、ノード、フィールド
＿レジスタ、フィールド＿ベース）は特定「オペラン
ド」変数の位置をセーブする。この情報はテンプレート
の特定「ノード」により整合されたILGタペルでセーブ
される。レジスタ値は成分「フィールドレジスタ」でセ
ーブされる。ある種のレジスタ値は生起しなかった割り
付けを符号化するか、あるいはオペランドがレジスタの
代わりにスタックに割り付けられる。もしオペランドが
スタックに割り付けられるなら、スタックオフセットは
「フィールド＿ベース」により特定された「ノード」の
成分でセーブされる。 セーブ＿レジスタ（オペランド、ノード、フィールド）
はテンプレートパターンにより整合された特定「ノー
ド」の特定「フィールド」の特定「オペランド」のレジ
スタナンバーをセーブする。このレジスタナンバーの組
はどんなレジスタも割り付けられなかったということの
符号化を含んでいる。もし特定のオペランドがメモリ位
置に割り付けられるなら誤りが生起する。 コード放出アクション 移動＿値（opr src,opr_dst）は「opr_src」オペランド
から「opr_dst」オペランドの値を移動するコードを発
生する。もしopr srcとopr dstが同一であり、かつこの
アクションがそれらを同一にする割り付けルーチン（al
locator）の指示（hint）であるなら、どのコードも発
生されない。 放出（オプコード、オペランド１、オペランド2,....）
は特定「オプコード」からなり、かつ命令のアドレスモ
ードとして特定オペランド変数を使用する目的命令を出
力する。 メーク＿アドレス＿モード（opr_offset,opr_base,opr_
index,opr_result）は変数「opr_result」に新しいオペ
ランドを作る。これはVAXアドレスモードを創生するた
めに、「opr_offset」をオフセットとして使用し、「op
r_base」をベースレジスタとして使用し、かつ「opr_in
dex」をインデクスレジスタとして使用するVAX特定アク
ションである。もし「opr_offset」が喪失するなら、零
が仮定される。もし「opr_offset」がメモリ位置を特定
するなら、「opr_offset」は零を特定しなければなら
ず、かつ「opr_index」は喪失されなければならない。 負荷＿定数（ナンバー、オペランド）は特定リテラル
「ナンバー」を表す「オペランド」に新しいアドレスを
作る。「ナンバー」がパターンにより整合されたノード
でないリテラル値であることに注意。その代わり、LITR
EF_ILGノードの値を含むアドレスモードを創生するため
に負荷＿リテラルを使用する。 実例 非常に簡単な付加テンプレートと非常に複雑なアドレシ
ングテンプレートを含むいくつかの実例が存在する。こ
れらはテンプレートを書くのに容易なものと困難なもの
双方の実例を与えるべきである。 テンプレートの結果値モードとパターン整合リーフの値
モードの組は目標アーキテクチャーのデータタイプ特性
を使用する。これらの値モードは値が符号化される種々
のやり方の列挙（enumeration）である。この列挙は表
現値が仮想計算機で符号化できる種々のやり方を命名す
る。 VAXの実例 RV（レジスタ値） MV（インダイレクションとインデキシングの無いメ
モリ値） MVIND（インダイレクションはあるがインデキシン
グは無いメモリ値） MV1（バイトコンテキストのあるメモリ値） MV2（ワードコンテキストのあるメモリ値） MV4（長いコンテキストのあるメモリ値） MV8（カッドコンテキストのあるメモリ値） MV16（オクトコンテキストのあるメモリ値） AM（インダイレクションとインデキシングの無いア
ドレスモード） AMIND（インダイレクションは無いがインデキシン
グも無いアドレスモード） AMINX1（バイトインデキシングのあるアドレスモー
ド） AMINX2（ワードインデキシングのあるアドレスモー
ド） AMINX4（長いインデキシングのあるアドレスモー
ド） AMINX8（カッドインデキシングのあるアドレスモー
ド） AMINX16（オクトインデキシングのあるアドレスモ
ード） PCFLOW（偽ラベルあるいは真ラベルへのジャンプに
より表されたフローブール） ストリングGV（長さおよびメモリのアドレスとして
符号化されたストリング値） VARYV（長さワードのアドレスとして符号化された
変動ストリング値） ボイド（サイド効果のみを持つ動作で使用されたど
んな値も存在しない） VAX上の単純ADDL3 結果値モード:RV パターンツリー 0:ADD,INT32 1,2 1:LEAF｛RV,MV,MVIND,MV4｝ 2:LEAF｛RV,MV,MVIND,MV4｝ コスト:2 アクション： アクション（結果、リーフ1,リーフ２）； ！ 「結果」は一時結果である ！ 「リーフ１」はLEAF1:（左オペランド） ！ 「リーフ２」はLEAF2:（右オペランド） 非遅延（1,リーフ１）； 非遅延（2,リーフ２）； 使用（リーフ１）； 使用（リーフ２）； 増分_LON; 割り付け＿永久（結果）； セーブ_TN（結果,0,ILG_TN）； 放出（ADDL3,リーフ1,リーフ2,結果）； 遅延； イグジット； 終了＿アクション； 註：レジスタ割り付けルーチンで使用されたヒューリス
ティクトは、結果オペランドがオペランド１あるいはオ
ペランド２の１つに同等に割り付けられる高い確率を保
証する。そのような割り付けはADDL3命令の代わりにADD
L2命令となろう。 VAX上の単純SUBL3 結果値モード:RV パターンツリー： 0:SUB,INT32 1,2 1:LEAF｛RV,MV,MVIND,MV4｝ 2:LEAF｛RV,MV,MVIND,MV4｝ パターンテスト： ノン コスト:2 アクション： アクション（結果；リーフ1,リーフ２）； ！ 「結果」は一時結果である ！ 「リーフ１」はLEAF1:（左オペランド） ！ 「リーフ２」はLEAF2:（右オペランド） 非遅延（1,リーフ１）； 非遅延（2,リーフ２）； 使用（リーフ２）； 増分_LON; 割り付け＿永久（結果）； セーブ_TN（結果,0,ILG,TN）； 放出（SUBL3,リーフ2,リーフ1,結果）； 遅延； イグジット； 終了＿アクション； 註：オペランド２を使用する後ではあるが、しかしオペ
ランド１を使用する前のLONの増分は、レジスタ割り付
けルーチンのヒューリスティクスがオペランド１と結果
オペランドと、SUBL3の代わりにSUBL2命令となる同じ割
り付けを与える確率を増大する。 VAX上のバイトインデクスされたアドレスモード このテンプレートは付加すべきｋ（ベース＿レジスタ）
［インデクス＿レジスタ］アドレスモードを発生する。
テンプレートは２つのオペランドを保持するためにレジ
スタが使用されることをこのテンプレートの選択が保証
されるVAX_フォルトラン規則に続く。 結果値モード:AMINX1 パターンツリー： 0:ADD,INT32 1,2 1:LITREF,INT32 2:ADD,INT32 3,4 3:LEAF｛RV｝ 4:LEAF｛RV｝ パターンテスト： ノー＿オーバーフロー（０）； ノー＿オーバーフロー（２）； コスト:1 アクション： アクション（結果；インデクス＿レジスタ，ベース＿
レジスタ，リーフ4,リーフ3,lit）； ！ 「結果」は結果アドレスモードlit（ベース＿レ
ジスタ）［インデクス＿レジスタ］である ！ 「インデクス＿レジスタ」はインデクススクラッ
チレジスタである ！ 「ベース＿レジスタ」はベーススクラッチレジス
タである ！ 「リーフ４」はLEAF4である：（インデクス リ
ーフ） ！ 「リーフ３」はLEAF3である：（ベース リー
フ） ！ 「lit」はLITREF1である： 遅延； ！ フォース LEAF4:レジスタの中に ！ 非遅延（4,リーフ４）； 割り付け＿遅延（インデクス＿レジスタ）； フォース＿レジスタ（インデクス＿レジスタ）； マスト＿割り付け（インデクス＿レジスタ）； 優先（リーフ4,インデクス＿レジスタ）； セーブ＿レジスタ（インデクス＿レジスタ,0,ILG_イ
ンデクス＿レジスタ）； 移動＿値（リーフ4,インデクス＿レジスタ）； 使用（リーフ４）； ！ フォース LEAF3:レジスタの中に ！ 非遅延（3,リーフ３）； 割り付け＿遅延（ベース＿レジスタ）； フォース＿レジスタ（ベース＿レジスタ）； マスト＿割り付け（ベース＿レジスタ）； 優先（リーフ３、ベース＿レジスタ）； セーブ＿レジスタ（ベース＿レジスタ,0,ILG_ベース
＿レジスタ）； 移動＿値（リーフ3,ベース＿レジスタ）； 使用（リーフ３）； ！ アドレスモード「lit（リーフ３）［リーフ
４］」の発生 ！ 負荷＿リテラル（1,lit）； メード＿アドレス＿モード（lit,ベース＿レジスタ，
インデクス＿レジスタ，結果）； 増分_LON; イグジット； 終了＿アクション； レジスタにLEAFを強制する７アクションは多分VAXの共
通オペレーションであることに注意。その結果、これら
の７アクションを結合する効果を有する「マクロ」アク
ションが存在しよう。 プリズム訂正0,0の付加にMOVAを使用 結果値モード:RV パターンツリー： 0:ADD,INT64 1,2 1:LITREF,INT64 2:LEAF［RV］ パターンテスト： Lit_14_ビット（１）；もしリテラルが14ビットで適
合するなら続く コスト:1 アクション： アクション（結果；リーフ2,レジスタ2,レジスタ＿結
果,lit）； ！ 「結果」は一時結果である ！ 「リーフ２」はリーフ２を記述する： ！ 「レジスタ２」はリーフ２を保持するスクラッチ
レジスタである： ！ 「レジスタ＿結果」は結果を計算するスクラッチ
レジスタである ！ 「lit」はリテラル１である： 非遅延（2,リーフ２）； 割り付け＿局部（レジスタ２）； フォース＿レジスタ（レジスタ２）； マスト＿割り付け（レジスタ２）； セーブ＿レジスタ（レジスタ2,0,ILG_レジスタ_0）； 移動＿値（リーフ2,レジスタ２）； 使用（リーフ２）； 使用（レジスタ２）； 割り付け＿局部（レジスタ＿結果）； フォース＿レジスタ（レジスタ＿結果）； マスト＿割り付け（レジスタ＿結果）； セーブ＿レジスタ（レジスタ＿結果,0,ILG_レジスタ
＿一時）； 使用（レジスタ＿結果）； 増分_LON: 割り付け＿局部（結果）； セーブ_TN（結果,0,ILG_TN）； 負荷＿リテラル（1,lit）； 放出（MOVA_移動＿形式,lit,レジスタ2,レジスタ＿結
果）； 移動＿値（レジスタ＿結果，結果）； 遅延； イグジット； 終了＿アクション； 註：レジスタ割り付けルーチンのヒューリスティックス
は、リーフ２とレジスタ２が同じレジスタを得る高い確
率を有することを保証する。また、結果とレジスタ＿結
果は同じレジスタをつかまえるように見える。 VAXの長いコンテキストインデキシング このテンプレートは、付加を後続する４の乗算をｋ（リ
ーフ３）［リーフ６］アドレスモードが行うことを保証
する。レジスタが２つのオペランドの保持に利用可能で
あることをこのテンプレートの選択が保証しないVAXパ
スカル規約にこのテンプレートは従う。もしレジスタ利
用可能でないなら、アドレスモードは一時メモリを使用
してシミュレートされる。 結果値モード:AMINX4 パターンツリー： 0:ADD,INT32 1,2 1:LITREF＜INR32 2:ADD,INT32 3,4 3:LEAF｛RV｝ 4:MUL,INT32 5,6 5:LIT,INT32 6:LEAF｛RV｝ パターンテスト： ノー＿オーバーフロー（０）； ノー＿オーバーフロー（２）； ノー＿オーバーフロー（４）； リテラル_4（５）； ！ もしリテラル値が４である
なら続く コスト:1 アクション アクション（結果；インデクス＿レジスタ，ベース＿
レジスタ，リーフ6,リーフ3,lit,一時）； ！ 「結果」は結果アドレスモードである ！ 「インデクス＿レジスタ」はインデクススクラッ
チレジスタである ！ 「ベース＿レジスタ」はベーススクラッチレジス
タである ！ 「リーフ６」はLEAF6である：（インデクス リ
ーフ） ！ 「リーフ３」はLEAF3である：（ベース リー
フ） ！ 「lit」はリテラル１である： ！ 「一時」はリテラル＃２（ノー＿インデクス ケ
ース）であるか ！ （リーフ３）［インデクス＿レジスタ］で
ある ！ （インデクス＿ハズ＿レジスタ＿
一時 ケース） 遅延； 負荷＿リテラル（1,lit）； 非遅延（6,リーフ６）； 非遅延（3,リーフ３）； 割り付け＿遅延（インデクス＿レジスタ）； 増分＿コスト（3,インデクス＿レジスタ）； 優先（リーフ6,インデクス＿レジスタ）； 割り付け＿遅延（ベース＿レジスタ）； 優先（リーフ6,ベース＿レジスタ）； 増分_LON; テスト＿メモリ（インデクス＿レジスタ，ノー＿イン
デクス）； 移動＿値（リーフ6,インデクス＿レジスタ）； ！ レジスタでインデクスを確実にする テスト＿メモリ（ベース＿レジスタ，ノー＿ベー
ス）； 移動＿値（リーフ3,ベース＿レジスタ）； ！ レジスタでベースを確実にする メーク＿アドレス＿モード（lit,ベース＿レジスタ，
インデクス＿レジスタ，結果）； ！ lit5（ベース２）［インデクス１］ イグジット； ラベル（ノー＿インデクス）； ！ 一時レジスタインデクスなし 負荷＿定数（2,一時）； 放出（ASHL,一時，リーフ6,インデクス＿レジス
タ）； ！ ASHL ＃2,リーフ6,インデクス＿メモリ 放出（ADDL2,リーフ3,インデクス＿レジスタ）； ！ ADDL2 リーフ3,インデクス＿メモリ 放出（ADDL2,lit,インデクス＿レジスタ）； ！ ADDL2,＃lit、インデクス＿メモリ メーク＿アドレス＿モード（，インデクス＿レジス
タ,,結果）； ！ ＠インデクス＿メモリ イグジット； ラベル（ノー＿ベース）； ！ 一時レジスタベースなし テスト＿メモリ（リーフ3,インデクス＿ハズ＿レジス
タ＿一時）； ！ インデクスは一時にない 放出（ADDL3,lit,リーフ3,ベース＿レジスタ）；＃li
t ！ ADDL2 リーフ3,ベース＿メモリ メーク＿アドレス＿モード（，ベース＿レジスタ，イ
ンデクス＿レジスタ，結果）； ！ ＠ベース＿メモリ［インデクス＿レジスタ］ 放出； ラベル（インデクス＿ハズ＿レジスタ＿一時）； ！ ベースレジスタはないが、一時インデクスはあ
る メーク＿アドレス＿モード（，リーフ3,インデクス＿
レジスタ，一時）； 放出（MOVAL,一時，インデクス＿レジスタ）； ！ MOVAL ＠リーフ３［インデクス＿レジス
タ］， インデクス レジスタ 放出（ADDL2,lit,インデクス＿レジスタ）； ！ ADDL2 ＃lit,インデクス＿レジスタ メーク＿アドレス＿モード（，インデクス＿レジス
タ,,結果）； ！ （インデクス＿レジスタ） イグジット； 終了＿アクション 基本タイプの定義 以下のルーチンはGEM ILにより規定された代表的タイプ
に対応する基本タイプを規定する。 GEM_TD_DEF_BASIC_TYPEはタイプ ニル、アドレス、符
号付きおよび非符号付き整数、浮動数および複素数を規
定する。GEM_TD_DEF_CHAR_TYPEは多数の基本タイプにわ
たって規定された文字の定義を許容する。 ブーリアンは基本タイプと考えられないことに注意。パ
スカルのような言語のコンパイラーは真要素と偽要素を
含む列挙としてのブーリアンを規定することが提案され
ている。 TYPE_NODE＝ GEM TD_DEF_BASIC_TYPE（ DECL_BLK :in_out GEM_BLOCK_NODE, LOCATOR :value, TYPE_NAME :in VS_STR BASIC_TYPE :value） 整数あるいは実数のような基本タイプを規定する。DECL
_BLKはタイプが規定されるブロックノードである。LOCA
TORはGEMあるいは異種のロケーターである。LOCATORは
ヌルロケーターであってもよい。TYPE_NAMEはタイプを
記述する変動ストリングであり、かつヌルであってもよ
い。BASIC_TYPEは規定されているタイプであり、かつGE
M_TYP列挙の要素でなければならない。特に除外される
のはBOOL,BITS,STR8およびSTR16 GEM_TYP要素である。 TYPE_NODE＝ GEM_TD_DEF_BASIC_TYPE（ DECL_BLK :in_out GEM_BLOCK_NODE, LOCATOR :value, TYPE_NAME :in VS_STR BASIC_TYPE :value） 基本タイプとして文字（charater）を規定する。例え
ば、文字はUINT8,UINT16,UINT32等であってもよい。DEC
L_BLKはタイプが規定されるブロックノードである。LOC
ATORはGEMあるいは異種のロケーターである。LOCATORは
ヌルロケーターであってもよい。TYPE_NAMEはタイプを
記述する変動ストリングであり、かつヌルであってもよ
い。BASIC_TYPEは規定されているタイプであり、かつ文
字セットのサイズと表現を決定する。それはGEM_TYP列
挙の要素でなければならず、かつサイズ８、16および32
ビットの符号付きおよび非符号付き整数に制限されてい
る。 文字およびストリング集合の定義 GEM_TD_DEG_STRINGとGEM_TD_DEG_BITSTRINGは所与の基
本タイプの文字とビットの集合を規定する。 TYPE_NODE＝ GEM_TD_DEF_STRING（ DECL_BLK :in_out GEM_BLOCK_NODE, LOCATOR :value, TYPE_NAME :in VS_STR, STRING_TYPE :value CHAR_TYPE :value, STRING_LB :in GEM_NODE, STRING_UB :in GEM_NODE） STRING_TYPEの文字ストリングを規定する。 ストリングの要素はCHAR_TYPEにより規定されたタイプ
の文字であり、かつストリングは下側オペランドと上側
オペランドであるSTRING_LBとSTRING_UBを有している。
ストリングサイズ（要素の数）はSTRING_UB_STRING_LB
＋１である。未知のサイズの文字ストリングはSTRING_L
B値より小さいSTRING_UB値により示される。 DECL_BLKはタイプが規定されるブロックノードである。
LOCATORはGEMあるいは異種のロケーターである。LOCATO
Rはヌルロケーターであってもよい。TYPE_NAMEはタイプ
を記述する変動ストリングであり、かつヌルであっても
よい。STRING_TYPEはストリング表現であり、かつ多数
の列挙GEM_STRING_REPRとして規定される。CHAR_TYPEは
GEM_TD_DEF_CHAR_TYPEの呼び出しにより戻されたストリ
ングの文字タイプに対して創生されたタイプノードのあ
だ名（handle）である。ヌル。STRING_UBとSTRING_LBは
ストリングの上限と下限である。 TYPE_NODE＝ GEM_TD_DEF_BITSTRING（ DECL_BLK :in_out GEM_BLOCK_NODE, LOCATOR :value, TYPE_NAME :in VS_STR BITSTRING_LB :in） GEM_LITERAL_NODE, BITSTRING_UB :in GEM_LITERAL_NODE） BITSTRING_UB-BITSTRING_LB＋１要素からなるビットス
トリングを規定する。未知のサイズのビットストリング
はBITSTRING_LB値より小さいBITSTRING_UB値により示さ
れる。 DECL_BLKはタイプが規定されるブロックノードである。
LOCATORはGEMあるいは異種のロケーターである。LOCATO
Rはヌルロケーターであっもよい。TYPE_NAMEはタイプを
記述する変動ストリングであり、かつヌルであってもよ
い。BITSTRING_UBとBITSTRING_LBはビットストリングの
上限と下限である。 タイプdefsとポインターの定義 GEM_TD_DEF_TYPEDEFは既存タイプの新しい名前あるいは
同義語の定義を支持する。GEM_TD_SET_POINTER TYPEは
タイプ化されたポインターあるいはタイプ化されないポ
インターの定義を許容する。GEM_TD_SET_POINTER_TYPE
は、ポインターと関連するタイプがGEMタイプ定義サー
ビスで特定されたそのタイプ情報を有した後で以前に特
定されたポインターのタイプを設定する。 TYPE_NODE＝ GEM_TD_DEF_BASIC_TYPE（ DECL_BLK :in_out GEM_BLOCK_NODE, LOCATOR :value, TYPE_NAME :in VS_STR BASIC_TYPE :value） 新しいタイプ名を規定し、かつそれをタイプノードDEF_
TYPEにより表されたタイプと関連付ける。DECL_BLKはタ
イプが規定されるブロックノードである。LOCATORはGEM
あるいは異種のロケーターである。LOCATORはヌルロケ
ーターであってもよい。TYPE_NAMEはタイプを記述する
変動ストリングであり、かつヌルであってもよい。DEF_
TYPEは既存のタイプ定義で創生されたタイプノードであ
る。 TYPE_NODE＝ GEM_TD_DEF_POINTER（ DECL_BLK :in_out GEM_BLOCK_NODE, LOCATOR :value, TYPE_NAME :in VS_STR POINTER_TYPE :value） ポインタータイプを規定する。POINTER_TYPEは既存タイ
プ定義のタイプノードであってもよく、あるいはタイプ
化されないポインターを示すヌルであってもよい。TYPE
_NAMEはタイプを記述する変動ストリングであり、かつ
ヌルであってもよい。LOCATORはGEMあるいは異種のロケ
ーターである。LOCATORはヌルロケーターであってもよ
い。DECL_BLKはタイプが規定されるブロックノードであ
る。 GEM_TD_SET_POINTER_TYPE（ POINTER_TYPE :value, NEW_TYPE :value） GEM_TD_POINTERの呼び出しにより創生された既存のポイ
ンター定義に対して、ポインターに関連するタイプを再
規定する。POINTER_TYPEはポインターを規定する既存の
タイプノードのあだ名である。NEW_TYPEは既存のタイプ
定義を創生したタイプノードのあだ名である。 レンジ、列挙およびセットの定義 GEM_TD_DEF_RANGE,GEM_TD_DEF_ENUM,GEM_TD_SET_ENUM_E
LEMENTおよびGEM_TD_SETは規定されたタイプにわたるレ
ンジ、列挙、列挙要素およびセットを規定する。 TYPE_NODE＝ GEM_TD_DEF_RANGE（ DECL_BLK :in_out GEM_BLOCK_NODE, LOCATOR :value, TYPE_NAME :in VS_STR RANGE_TYPE :value RANGE_LOW_VAL :in GEM_LITERAL_NODE, RANGE_HIGH_VAL :in GEM_LITERAL_NODE） レンジタイプを規定する。レンジはその基礎となるタイ
プ、RANGE_TYPEおよびリテラルノードRANGE_LOW_VALとR
ANGE_HIGH_VALにより示されたレンジの低い値と高い値
により規定される。DECL_BLKはタイプが規定されるブロ
ックノードである。LOCATORはGEMあるいは異種のロケー
ターである。LOCATORはヌルロケーターであってもよ
い。TYPE_NAMEはタイプを記述する変動ストリングであ
り、ヌルであってもよい。RANGE_TYPEは既存の基本タイ
プ定義のタイプノードのあだ名である。RANGE_LOW_VAL
とRANGE_HIGH_VALはレンジの低い値と高い値を示すリテ
ラルノードへのポインターである。 TYPE_NODE＝ GEM_TD_DEF_ENUM（ DECL_BLK :in_out GEM_BLOCK_NODE, LOCATOR :value, TYPE_NAME :in VS_STR ENUM_TYPE :value） 列挙を規定する。列挙要素はルーチンGEM_TD_SET_ENUM_
ELEMENTの呼び出しにより規定される。DECL_BLKはタイ
プが規定されるブロックノードである。LOCATORはGEMあ
るいは異種のロケーターである。LOCATORはヌルロケー
ターであってもよい。ENUM_TYPEは既存の基本タイプ定
義を創生するタイプノードのあだ名である。 前端はまず最終順序の列挙定義に列挙要素を印加しなけ
ればならない。 TYPE_NODE＝ GEM_TD_DEF_ENUM_ELEMENT（ ENUM_TYPE :value, LOCATOR :value, ENUM_ELEMENT_NAME :in VS_STR ENUM_ELEMENT_VALUE:in GEM_LITERAL_NODE） ENUM_ELEMENT_VALUEによりENUM_ELEMENT_NAMEと命名さ
れた要素であるタイプノードあだ名ENUM_TYPEにより示
された列挙を規定する。ENUM_TYPEは列挙の既存のタイ
プノードのあだ名である。LOCATORはGEMあるいは異種の
ロケーターである。LOCATORはヌルロケーターであって
もよい。ENUM_ELEMENT_NAMEは列挙要素を規定する変動
ストリングである。ENUM_ELEMENT_VALUEは要素の値を規
定するリテラルノードである。 GEM_TD_SET_SEL TYPE_NODE＝ GEM_TD_DEF_SET（ DECL_BLK :in_out GEM_BLOCK_NODE, LOCATOR :value, TYPE_NAME :in VS_STR SET_TYPE :value） タイプノードあだ名SET_TYPEにより規定された一組のタ
イプを規定する。DECL_BLKはタイプが規定されるブロッ
クノードである。LOCATORはGEMあるいは異種のロケータ
ーである。LOCATORはヌルロケーターであってもよい。T
YPE_NAMEはタイプを記述する変動ストリングであり、か
つヌルであってもよい。SET_TYPEは以下のものにより戻
されたあだ名であってもよい。 ０ GEM_TD_DEF_BASIC_TYPE ０ GEM_TD_DEF_CHAR_TYPE ０ GEM_TD_DEF_ENUM ０ GEM_TD_DEF_RANGE ０ GEM_TD_TYPEDEF アレイの定義 ルーチンGEM_TD_DEF_ARRAYとGEM_TD_SET_ARRAY_BOUNDS
はアレイとアレイ次元の限界の規定に使用できる。アレ
イ次元の限界は固定され、調整可能であるかあるいは仮
定的なものとして規定できる。 TYPE_NODE＝ GEM_TD_DEF_ARRAY（ DECL_BLK :in_out GEM_BLOCK_NODE, LOCATOR :value, TYPE_NAME :in VS_STR ARRAY_ELEMENT_TYPE:value） ARRAY_DIM_COUNT:value） タイプARRAY_ELEMENT_TYPEのアレイを規定する。DECL_B
LKはタイプが宣言されるプロックノードである。LOCATO
RはGEMあるいは異種のロケーターである。LOCATORはヌ
ルロケーターであってもよい。TYPE_NAMEはタイプを記
述する変動ストリングであり、かつヌルであってもよ
い。ARRAY_ELEMENT_TYPEはアレイ要素のタイプを規定す
るタイプノードのである。ARRAY_DIM_COUNTはアレイの
次元数である。 次元カウントはリテラルノード以外の値の次元として伝
送される。 アレイの次元の限界はGEM_TD_SET_ARRAY_BOUNDSルーチ
ン手段により特定される。 GEM_TD_SET_ARRAY_BOUNDS（ ARRAY_TYPE :value, LOCATOR :value, ARRAY_DIM :value, DIM_LOW_BOUND :in GEM_NODE, DIM_HIGH_BOUND :in GEM_NODE, DIM_INDEX_TYPE :value, DIM_STRIDE :in GEM_LITERAL_NODE） あだ名ARRAY_TYPEにより特定されたアレイタイプ定義に
対して、ARRAY_DIMにより示された次元の限界を設定す
る。LOCATORはGEMあるいは異種のロケーターである。LO
CATORはヌルロケーターであってもよい。DIM_INDEX_LOW
とDIM_INDEX_HIGHは次元の下限と上限を規定する。DIM_
INDEX_TYPEはアレイ次元をインデクスするのに使用され
たタイプを規定するタイプノードのあだ名である。DIM_
STRIDEは規定されている次元の続いて起こる要素間のバ
イトで表したサイズを規定する。ブランクＡ定数の上限
あるいは下限はリテラルノードにより特定される。非一
定限界は限界値の位置を規定するシンボルノードにより
示される。 構造、バリアントおよびユニオンの定義 以下のルーチンはバリアントとユニオンを含む構造を規
定するのに使用される。バリアント成分を有する構造は
以下のルーチンを呼び出すことにより規定される。 ０ GEM_TD_DEF_STRUCT ０ GEM_TD_SET_STRUCT_ELEMENT ０ GEM_TD_STRUCT_SELECTOR ０ GEM_TD_DEF_STRUCT_VARIANT ０ GEM_TD_SET_SELECTOR_RANGE ０ GEM_TD_SET_SELECTOR_DEFAULT ０ GEM_TD_DEF_UNION ０ GEM_TD_SET_UNION_MEMBER TYPE_NODE＝ GEM_TD_DEF_STRUCT（ DECL_BLK :in_out GEM_BLOCK_NODE, LOCATOR :value, TYPE_NAME :in VS_STR STRUCT_SIZE :value） 構造あるいは記録を規定する。DECL_BLKは構造が宣言さ
れるブロックノードである。LOCATORはGEMあるいは異種
のロケーターである。LOCATORはヌルロケーターであっ
てもよい。TYPE_NAMEはタイプを記述する変動ストリン
グであり、かつヌルであってもよい。STRUCT_SIZEはバ
イトで表した構造のサイズである。 GEM_TD_SET_STRUCT_ELEMENT（ STRUCT_TYPE :value, VARIANT_PARENT :value, LOCATOR :value, ELEMENT_NAME :in VS_STR ELEMENT_TYPE :value, ELEMENT_LOC_BYTE:in GEM_LITERAL_NODE, ELEMENT_LOC_BIT :in GEM_LITERAL_NODE, ELEMENT_SIZE :in GEM_LITERAL_NODE） 構造定義あだ名STRUCT_TYPEにより規定された構造の要
素を規定する。この要素はELEMENT_NAMEと命名されかつ
タイプノードあだ名ELEMENT_TYPEにより規定されたタイ
プを有している。VARIANT_PARENTはもし要素がバリアン
トのメンバーを規定しないなら要素の直接の親バリアン
トあるいはヌルである。LOCATORはGEMあるいは異種のロ
ケーターである。LOCATORはヌルロケーターであっても
よい。その位置は定義されている構造のルートに関連
し、かつELEMENT_LOC_BYTEとELEMENT_LOC_BITにより特
定される。 構造要素のサイズはELEMENT_SIZEによりビットで特定さ
れる。ELEMENT_SIZEは以下のＣプログラム断片の構造要
素c1とc2の定義を支持するよう特定されている。 typedef struct m1 ｛ char c1 ： 4; char c2 ： 4; ｝； TYPE_NODE＝ GEM_TD_SET_STRUCT_SELECTOR（ STRUCT_TYPE :value, VARIANT_PARENT :value, LOCATOR :value, ELEMENT_NAME :in VS_STR ELEMENT_TYPE :value, ELEMENT_LOC_BYTE:in GEM_LITERAL_NODE, ELEMENT_LOC_BIT :in GEM_LITERAL_NODE, ELEMENT_SIZE :in GEM_LITERAL_NODE） 記録のバリアント成分のセレクターを規定する。セレク
ターは構造のバリアントを決定する構造要素である。セ
レクター要素はELEMENT_NAMEと命名され、かつタイプノ
ードあだ名ELEMENT_TYPEにより規定されたタイプを有し
ている。VARIANT_PARENTはセレクター要素の直接の親バ
リアントであるか、あるいはもしもこの要素がバリアン
トのメンバーでないならヌルである。LOCATORはGEMある
いは異種のロケーターである。LOCATORはヌルロケータ
ーであってもよい。その位置は規定されている構造のル
ートに相対的であり、かつELEMENT_LOC_BYTEとELEMENT_
LOC_BITにより特定される。構造要素のサイズはELEMENT
_SIZEによりビットで特定される。 TYPE_NODE＝ GEM_TD_DEF_STRUCT_VARIANT（ STRUCT_TYPE :value, LOCATOR :value） 構造のバリアントを規定する。SELECTOR_TYPEはバリア
ントを選択するタイプノードである。LOCATORはGEMある
いは異種のロケーターである。LOCATORはヌルロケータ
ーであってもよい。バリアントを選択するセレクターの
値は次のものによって特定される。GEM_TD_SET_SELECTO
R_RANGEとGEM_TD_SET_SELECTOR_DEFAULT ルーチン GEM_TD_SET_SELECTOR_RANGE（ VARIANT_TYPE :value, LOCATOR :value, RANGE_LOWER_BOUND:in GEM_LITERAL_NODE, RANGE_UPPER_BOUND:in GEM_LITERAL_NODE） バリアントVARIANT TYPEのセレクターレンジを規定す
る。LOCATORはGEMあるいは異種のロケーターである。LO
CATORはヌルロケーターであってもよい。単一セレクタ
ー値を規定する場合にRANGE_UPPER_BOUNDはRANGE_LOWER
_BOUNDと同じ値を有すべきである。単一セレクターとレ
ンジセレクターの結合はバリアントに印加してもよい。 GEM_TD_SET_SELECTOR_DEFAULT（ VARIANT_TYPE :value, LOCATOR :value） そのセレクターのすべての値が列挙されない場合にバリ
アントタイプVARIANT_TYPEを省略バリアント（default
variant）であると規定する。LOCATORはGEMあるいは異
種のロケーターである。LOCATORはヌルロケーターであ
ってもよい。スカラーセレクター値を規定する場合にRA
NGE_UPPER_BOUNDはRANGE_LOWER_BOUNDと同じ値を有すべ
きである。スカラーセレクターとレンジの結合はバリア
ントに印加してもよい。 TYPE_NODE＝ GEM_TD_DEF_UNION（ DECL_TYPE :in_out GEM_BLOCK_NODE, LOCATOR :value, TYPE_NAME :in VS_STR UNION_SIZE :in GEM_LITERAL_NODE） ユニオンを規定する。DECL_BLKは構造が宣言されるブロ
ックノードである。TYPE_NAMEはタイプを記述する変動
ストリングであり、かつヌルであってもよい。LOCATOR
はGEMあるいは異種のロケーターである。LOCATORはヌル
ロケーターであってもよい。UNION_SIZEはバイトで表し
た構造のサイズである。ユニオンのメンバーはルーチン
GEM_TD_SET_UNION_MEMBERの呼び出しにより規定され
る。 GEM_TD_SET_UNION_MEMBER（ UNION_TYPE :value, LOCATOR :value, MEMBER_NAME:in VS_STR, MEMBER_TYPE:value） タイプノードUNION_TYPEにより示されたユニオンのメン
バーを規定する。UNION_TYPEはメンバーを含むユニオン
のタイプノードである。LOCATORはGEMあるいは異種のロ
ケーターである。LOCATORはヌルロケーターであっても
よい。MEMBER_NAMEはメンバーの名前を規定する変動ス
トリングである。MEMBER_TYPEは規定されているメンバ
ーのタイプノードである。 関数とルーチンパラメータの定義 TYPE_NODE＝ GEM_TD_DEF_FUNCTION_TYPE（ DECL_BLK :in_out GEM_BLOCK_NODE, LOCATOR :value, TYPE_NAME :in VS_STR FUNCTION_TYPE:value） タイプノードFUNCTION_TYPEにより特定されたタイプで
ある手順パラメータのタイプを規定する。これはエント
リーシンボルのタイプの規定に使用されず、むしろそれ
はルーチンのパラメータを記述することに注意。DECL_B
LKはタイプが規定されるブロックノードである。LOCATO
RはGEMあるいは異種のロケーターである。LOCATORはヌ
ルロケーターであってもよい。TYPE_NAMEはタイプを記
述する変動ストリングであり、かつヌルであってもよ
い。 実例 以下の実例は多数のタイプとシンボルおよびGEMにそれ
らを記述するのに使用される機構を記述している。パス
カルタイプのブーリアンはGEMタイプユニット32にわた
る列挙として規定されることに注意。 基本タイプの実例 主要（ ） ｛ int a; 符号なしint ua; フロート x; 二重 xx; 文字ストリング｛ ｝＝「ヘロー，ワールド＼ｎ」； TYPINT32＝GEM_TD_DEF_BASIC_TYPE（主＿ブロック，ロ
ケーター，‘int', GEM_TYP_K_INT32）； TYPUINT32＝GEM_TD_DEF_BASIC_TYPE（主＿ブロック，ロ
ケーター，‘符号なしint', GEM_TYP_K_INT32）； TYPREALF＝GEM_TD_DEF_BASIC_TYPE（主＿ブロック，ロ
ケーター，‘フロート', GEM_TYP_K_REALF）； TYPREALG＝GEM_TD_DEF_BASIC_TYPE（主＿ブロック，ロ
ケーター，‘二重', GEM_TYP_K_REALG）； TYPCHAR8＝GEM_TD_DEF_BASIC_TYPE（主＿ブロック，ロ
ケーター，‘文字', GEM_TYP_K_INT8）； TYPSTRING＝GEM_TD_DEF_STRING（ 主＿ブロック，ロケーター， ‘ストリング', GEM_STRREP_K_ASCIZ, TYPCHAR8, 1itノード（1en（str）））； タイプブーリアンの定義の実例 手順bt; ブーリアン マイフラグ； TYPUINT32＝GEM_TD_DEF_BASIC_TYPE（bt_ブロック，ロ
ケーター，‘符号なしint', GEM_TYP_K_INT32）； TYPBOOL＝GEM_TD_DEF_ENUM（bt_ブロック，ロケータ
ー，‘ブーリアン'TYPUINT32）； GEM_TD_SET_ENUM_ELEMENT（TYPBOOL,ロケーター、
‘偽',litノード（val＝０））； GEM_TD_SET_ENUM_ELEMENT（TYPBOOL,ロケーター、
‘真',litノード（val＝１））； 文字およびビット集合の実例 ルーチン testit（parm1,....）＝ 開始 自己ステータス ：ビットベクトル［15］， フラグビット：ビットベクトル［８］； バインドｄビットベクトル＝.parm1:ビットベクトル
［ ］； ・ ・ 終了； TYPBITS1＝GEM_TD_DEF_BITSTRING（testit_ブロック，
ロケーター，‘ビットベクトル', litノード（val＝０）,litノード（val＝14））； TYPBITS2＝GEM_TD_DEF_BITSTRING（testit_ブロック，
ロケーター，‘ビットベクトル', litノード（val＝０）,litノード（val＝７））； TYPBITS3＝GEM_TD_DEF_BITSTRING（testit_ブロック，
ロケーター，‘ビットベクトル', litノード（val＝０）,litノード（val＝１））； ポインターとタイプdefsの実例 int エコー（ ） ｛ 構造 ｔノード ｛ ｝ タイプdefs 構造 ｔノード ssval; ｔノード ＊tp; ｚノード ＊zp; 構造 ｚノード ｛ ・ ・ ｝ TYPSTRUCT1＝構造ｔノードの定義 ！ ｔノードのアライアスとしてssvalを規定する TYPALIAS＝GEM_TD_DEF_TYPEDEF（エコー＿ブロック，ロ
ケーター，‘ssval',TYPSTRUCT1）； TYPPTR1＝GEM_TD_DEF_POINTER（エコー＿ブロック，ロ
ケーター，‘ヌル',TYPSTRUCT1）； ！ 「同義語」ポインターを規定し、次に構造ｚノード
を規定する。最後に ！ ポインタータイプ を修正する TYPPTR2＝GEM_TD_DEF_POINTER（エコー＿ブロック，ロ
ケーター，‘ポインター',ヌル）； TYPSTRUCT2＝構造ｚノードの定義 GEM_TD_DEF_POINTER_TYPEE（TYPPTR2,TYPSTRUCT2）； レンジ列挙とセットの実例 ボイド myproc（ ） ｛ タイプ dn1＝０‥6; dn2＝100‥105; dn3＝66000‥66001; ウイークデー＝（月曜，火曜，水曜，木曜，金
曜）； t_タイプ ＝（int,re,boo）； バル s1:dn1のセット； s2:ウイークデーのセット； s3:t_タイプのセット； ！ レンジdn1を規定する TYPUINT8＝GEM_TD_DEF_BASIC_TYPE（myproc_ブロック，
ロケーター，ヌル， GEM_TYP_K_UINT8）； TYPRANGE1＝GEM_TD_DEF_RANGE（myproc_ブロック，ロケ
ーター，‘dn1', TYPUINT8,litノード（val＝０）,litノード（val
＝６）； ！ レンジdn2を規定する TYPRANGE2＝GEM_TD_DEF_RANGE（myproc_ブロック，ロケ
ーター，‘dn2', TYPUINT8,litノード（val＝100）,litノード（va
l＝105）； ！ レンジdn3を規定する TYPINT32＝GEM_TD_DEF_BASIC_TYPE（myproc_ブロック，
ロケーター，ヌル， GEM_TYP_K_UNIT32）； TYPRANGE＝GEM_TD_DEF_RANGE（myproc_ブロック,TYPINT
32,‘dn3', litノード（val＝66000）,litノード（val＝6600
1）； TYPENUM1＝GEM_TD_DEF_ENUM（myproc_ブロック，ロケー
ター，‘ウイークデー',TYPUNIT8）； GEM_TD_SET_ENUM_ELEMENT（TYPENUM1,ロケーター，
‘月曜',litノード（val＝０））； GEM_TD_SET_ENUM_ELEMENT（TYPENUM1,ロケーター，
‘火曜',litノード（val＝１））； GEM_TD_SET_ENUM_ELEMENT（TYPENUM1,ロケーター，
‘水曜',litノード（val＝２））； GEM_TD_SET_ENUM_ELEMENT（TYPENUM1,ロケーター，
‘木曜',litノード（val＝３））； GEM_TD_SET_ENUM_ELEMENT（TYPENUM1,ロケーター，
‘金曜',litノード（val＝４））； TYPENUM2＝ GEM_TD_DEF_ENUM（myproc_ブロック，ロケ
ーター，‘t_タイプ',TYPEUINT32）； GEM_TD_SET_ENUM_ELEMENT（TYPENUM2,ロケーター，
‘int',litノード（val＝０））； GEM_TD_SET_ENUM_ELEMENT（TYPENUM2,ロケーター，
‘re',litノード（val＝１））； GEM_TD_SET_ENUM_ELEMENT（TYPENUM2,ロケーター，
‘boo',litノード（val＝２））； ！ バルs1,s2およびs3のセットを規定する。 TYPSET1＝GEM_TD_SET（myproc_ブロック，ロケーター，
‘セット',TYPRANGE1）； TYPSET2＝GEM_TD_SET（myproc_ブロック，ロケーター，
‘セット',TYPENUM1）； TYPSET3＝GEM_TD_SET（myproc_ブロック，ロケーター，
‘セット',TYPENUM2）； アレイの実例 手順 ディマー； タイプ nd＝記録‥‥ バル ary1:整数のアレイ［１‥10］ ary2:整数のアレイ［１‥10,100‥110］； ary3:ndのアレイ［900‥1700］ ary4:ndのアレイ［‘a'‥‘z'］ TYPSTRUCT1＝記録タイプndの定義 ！ アレイ１「ary1」を規定する TYPINT32＝GEM_TD_DEF_BASIC_TYPE（ディマー＿ブロッ
ク，ロケーター，ヌル,GEM_TYP_K_INT32）； TYPARRAY＝GEM_TD_DEF_ARRAY_TYPE（ディマー＿ブロッ
ク，ロケーター，ヌル,TYPINT32,1）； GEM_TD_DEF_ARRAY_BOUNDS（TYPARRAY,ロケーター,1,lit
ノード（val＝１）,litノード（val＝10）,TYPINT32,li
tノード（val＝４））； ！ アレイ「ary2」を規定する TYPARRAY＝GEM_TD_DEF_ARRAY（ディマー＿ブロック，ロ
ケーター，ヌル,TYPINT32,2）； GEM_TD_SET_ARRAY_BOUNDS（TYPARRAY,ロケーター,1,lit
ノード（val＝１）,litノード（val＝10）,TYPINT32,li
tノード（val＝４））； GEM_TD_SET_ARRAY_BOUNDS（TYPARRAY,ロケーター,2,lit
ノード（val＝100）,litノード（val＝110）,TYPINT32,
litノード（value＝40））； ！ 代案として、ary2のアレイ規格を次のように規定し
てもよい。 TYPARRAY1＝GEM_TD_SET_ARRAY（ディマー＿ブロック，
ロケーター，ヌル,TYPINT32,1）； GEM_TD_SET_ARRAY_BOUNDS（TYPARRAY1,ロケーター,1,li
tノード（val＝100）,litノード（val＝110）,TYPINT3
2,litノード（value＝40））； TYPARRAY2＝GEM_TD_SET_ARRAY（ディマー＿ブロック，
ロケーター，ヌル,TYPARRAY1,1）； GEM_TD_SET_ARRAY_BOUNDS（TYPARRAY2,ロケーター,1,li
tノード（val＝１）,litノード（val＝10）,TYPINT32,l
itノード（value＝40））； ！ アレイ「ary3」を規定する TYPARRAY＝GEM_TD_DEF_ARRAY（ディマーブロック，ロケ
ーター，ヌル,TYPARRAY1,1）； GEM_TD_DEF_ARRAY_BOUNDS（TYPARRAY,ロケーター,1,lit
ノード（val＝900）,litノード（val＝1700）,TYPINT3
2,sizeof（nd））； 調整可能なアレイ定義の実例 サブルーチン ｘ（cv,ary1,ary2,a,b） 文字＊（＊） cv 次元 ary1（1:10,1:b） 次元 ary2（a:b,1:＊） TYPINT32＝GEM_TD_DEF_BASIC_TYPE（x_ブロック，ロケ
ーター，ヌル,GEM_TYP_K_INT32）； TYPCHAR＝GEM_TD_DEF_CHAR_TYPE（x_ブロック，ロケー
ター，ヌル,GEM_TYP_K_INT8）； ！ アレイ「cv」を規定する TYPINT＝GEM_TD_DEF_ARRAY（x_ブロック，ロケーター，
ヌル,TYPCHR,1）； GEM_TD_SET_ARRAY_BOUNDS（TYPARRAY1,ロケーター,1,li
tノード（val＝１）,litノード（val＝１）,TYPINT32,l
itノード（value＝１））； ！ アレイ「ary1」を規定する TYPREALF＝GEM_TD_DEF_BASIC_TYPE（x_ブロック，ロケ
ーター，ヌル,GEM_TYP_K_REALF）； TYPARRAY＝GEM_TD_DEF_ARRAY（x_ブロック，ロケータ
ー,TYPREALF,2）； 2,litノード（val＝４））； GEM_TD_SET_ARRAY_BOUNDS（TYPARRAY,1,ロケーター,lit
ノード（val＝１）,litノード（val＝40）,TYPINT32,li
tノード（value＝４））； GEM_TD_SET_ARRAY_BOUNDS（TYPARRAY,2,ロケーター,lit
ノード（val＝１）,b_シンボル,TYPINT32,litノード（v
alue＝４））； ＊＊＊＊＊＊＊＊＊＊ ！ アレイ「ary2」を規定する TYPARRAY＝GEM_TD_DEF_ARRAY（x_ブロック，ロケータ
ー，ヌル,TYPREALF,TYPINT32,2,litノード（val＝
４））； GEM_TD_SET_ARRAY_BOUNDS（TYPARRAY,ロケーター,1,a_
シンボル,b_シンボル,TYPINT32,litノード（val＝
４））； GEM_TD_SET_ARRAY_BOUNDS（TYPARRAY,ロケーター,2,lit
ノード（val＝１）,litノード（val＝１）,TYPINT32,li
tノード（value＝４））； 構造とバリアントの実例 タイプ t_タイプ＝（it,re,ptr,v1,v2,v3）； ndp ＝＠nd nd＝記録 ネクスト:ndp; ケース tt :t_タイプ オブ it :（iv:整数）； re :（rv:実数）； ptr:（pv:ndp;和：整数）； さもなければ：（i1:整数;i2:実
数）； 終了； ！ 実例に使用された基本タイプを規定する TYPINT32＝GEM_TD_DEF_BASIC_TYPE（typeit_ブロック，
ロケーター，‘整数',GEM_TYP_K_INT32）； TYPREALF＝GEM_TD_DEF_BASIC_TYPE（typeit_ブロック，
ロケーター，‘実数',GEM_TYP_K_PEALF）； TYPNIL＝GEM_TD_DEF_BASIC_TYPE（typeit_ブロック，ロ
ケーター，ヌル,GEM_TYP_K_NIL）； ！ ndにndpポシンターを規定する TYPPTR＝GEM_TD_DEF_POINTER（typeit_ブロック，ロケ
ーター，‘ndp',TYPNIL）； ！ t_タイプ列挙を規定する TYPENUM＝GEM_TD_DEF_ENUM（myproc_ノード，ロケータ
ー，‘t_タイプ',TYPINT32）； GEM_TD_SET_ENUM_ELEMENT（TYPENUM,ロケーター，‘i
t',litノード（val＝０））； GEM_TD_SET_ENUM_ELEMENT（TYPENUM,ロケーター，‘r
e',litノード（val＝１））； GEM_TD_SET_ENUM_ELEMENT（TYPENUM,ロケーター，‘b
oo',litノード（val＝２））； GEM_TD_SET_ENUM_ELEMENT（TYPENUM,ロケーター，‘v
1',litノード（val＝３））； GEM_TD_SET_ENUM_ELEMENT（TYPENUM,ロケーター，‘v
2',litノード（val＝４））； GEM_TD_SET_ENUM_ELEMENT（TYPENUM,ロケーター，‘v
3',litノード（val＝５））； ！ 構造定義ndを規定する TYPSTRUCT＝GEM_TD_DEF_STRUCT（typeit_ブロック，ロ
ケーター，‘nd',litノード（nd_サイズ））； GEM_TD_SET_STRUCT_ELEMENT（TYPSTRUCT,,ヌル，ロケ
ーター，‘次ぎ',TYPPTR; litノード（1_バイト（次ぎ））,litノード（1_ビット
（次ぎ））,litノード（ビット＿サイズ（次ぎ））； ！ バリアントパートのセレクタを規定する TYPSEL＝GEM_TD_DEF_STRUCT_SELECTOR（TYPSTRUCT,ヌ
ル，‘tt',TYPENUM, litノード（1_バイト（tt））,litノード（1_ビット（t
t））,litノード（ビット＿サイズ（tt））； ！ 省略（default）を含む構造のバリアントを規定す
る V1＝GEM_TD_DEF_STRUCT_VARIANT（TYPSEL,ロケータ
ー）； GEM_TD_SET_STRUCT_RANGE（V1,ロケーター,litノー
ド（val＝０）,litノード（val＝０）； GEM_TD_SET_STRUCT_ELEMENT（TYPSTRUCT,V1,ロケー
ター，‘iv',TYPINT, litノード（1_バイト（iv））,litノード（1_ビッ
ト（iv））,litノード（ビット＿サイズ（iv））； V2＝GEM_TD_DEF_STRUCT_VARIANT（TYPSEL,ロケータ
ー）； GEM_TD_SET_STRUCT_RANGE（V2,ロケーター,litノー
ド（val＝１）,litノード（val＝１）； GEM_TD_SET_STRUCT_ELEMENT（TYPSTRUCT,V2,ロケー
ター，‘rv',TYPREALF, litノード（1_バイト（rv））,litノード（1_ビッ
ト（rv））,litノード（ビット＿サイズ（rv））； V3＝GEM_TD_DEF_STRUCT_VARIANT（TYPSEL,ロケータ
ー）； GEM_TD_SET_STRUCT_RANGE（V3,ロケーター,litノー
ド（val＝２）,litノード（val＝２）； GEM_TD_SET_STRUCT_ELEMENT（TYPSTRUCT,V3,ロケー
ター，‘pv',TYPPTR, litノード（1_バイト（pv））,litノード（1_ビッ
ト（pv））,litノード（ビット＿サイズ（pv））； GEM_TD_SET_STRUCT_ELEMENT（TYPSTRUCT,V3,ロケー
ター，‘和',TYPPTR, litノード（1_バイト（和））,litノード（1_ビッ
ト（和））,litノード（ビット＿サイズ（和））； V4＝GEM_TD_DEF_STRUCT_VARIANT（TYPSEL,ロケータ
ー）； GEM_TD_SET_SELECTOR_RANGE（V4,ロケーター）； GEM_TD_SET_STRUCT_ELEMENT（TYPSTRUCT,V4,ロケー
ター，‘i1'TYPPTR, litノード（1_バイト（i1））,litノード（1_ビッ
ト（i1））,litノード（ビット＿サイズ（i1））； GEM_TD_SET_STRUCT_ELEMENT（TYPSTRUCT,V4,ロケー
ター‘i2'TYPPTR, litノード（1_バイト（i2））,litノード（1_ビッ
ト（i2））,litノード（ビット＿サイズ（i2））； GEM_TD_SET_POINTER_TYPE（TYPPTR,TYPSTRUCT）； 構造およびユニオン定義の実例 主 （ ） ｛ 構造 ディマー３ ｛ int x; int y; int z; ｝； ユニオン anon｛ int ival; フロート fval; 文字 ＊pval 構造 ディマー３ 1oc; ｝； 構造 n1 ｛ ユニオン anon a; ユニオン anon b; ユニオン anon c; ｝； 構造 n1,n11,n12,n13; TYPINT32＝GEM_TD_DEF_BASIC_TYPE（主＿ブロック，ロ
ケーター，‘int',GEM_TYP_K_INT32）； TYPREALF＝GEM_TD_DEF_BASIC_TYPE（主＿ブロック，ロ
ケーター，ヌル,GEM_TYP_K_REALF）； TYPCHAR＝GEM_TD_DEF_CHAR_TYPE（主＿ブロック，ロケ
ーター，ヌル,GEM_TYP_K_UNIT8）； TYPPTR＝GEM_TD_DEF_POINTER（主＿ブロック，ロケータ
ー，ヌル,TYPCHAR）； ！ 構造「ディマー３」を規定する TYPSTRUCT＝GEM_TD_DEF_STRUCT（主＿ブロック，ロケー
ター，‘ディマー3',litノード（ディマー3_サイズ）； GEM_TD_SET_STRUCT_ELEMENT（TYPSTRUCT,ヌル，ロケ
ーター，‘x',TYPINT32, locバイト（ｘ）,locビット（ｘ）,litノード（x_
サイズ））； GEM_TD_SET_STRUCT_ELEMENT（TYPSTRUCT,ヌル，ロケ
ーター，‘y',TYPINT32, locバイト（ｙ）,locビット（ｙ）,litノード（y_
サイズ））； GEM_TD_SET_STRUCT_ELEMENT（TYPSTRUCT,ヌル，ロケ
ーター，‘z',TYPINT32, locバイト（ｚ）,locビット（ｚ）,litノード（z_
サイズ））； ！ ユニオン「anon」を規定する TYPUNION＝GEM_TD_DEF_UNION（主＿ブロック，ロケー
ター，‘anon',litノード（anon_サイズ））； GEM_TD_SET_UNION_MEMBER（TYPUNION,ロケーター，‘iv
al',TRPINT32）； GEM_TD_SET_UNION_MEMBER（TYPUNION,ロケーター，‘fv
al',TRPREALF）； GEM_TD_SET_UNION_MEMBER（TYPUNION,ロケーター，‘pv
al',TRPPTR）； GEM_TD_SET_UNION_MEMBER（TYPUNION,ロケーター，‘1o
c',TRPSTRUCT）； ！ 構造「n1」を規定する TYPSTRUCT＝GEM_TD_DEF_STRUCT（主＿ブロック，ロケ
ーター，‘n1',litノード（n1_サイズ））； GEM_TD_SET_STRUCT_ELEMENT（TYPSTRUCT,ヌル，ロケー
ター，‘a',TYPUNION, locバイト（ａ）,locビット（ａ）,litノード（ano
n_サイズ））； GEM_TD_SET_STRUCT_ELEMENT（TYPSTRUCT,ヌル，ロケー
ター，‘b',TYPUNION, locバイト（ｂ）,locビット（ｂ）,litノード（ano
n_サイズ））； GEM_TD_SET_STRUCT_ELEMENT（TYPSTRUCT,ヌル，ロケー
ター，‘c',TYPUNION, locバイト（ｃ）,locビット（ｃ）,litノード（ano
n_サイズ））；

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号 ６６２４８３ (32)優先日 1991年２月27日 (33)優先権主張国 米国（ＵＳ） (31)優先権主張番号 ６６２４６４ (32)優先日 1991年２月27日 (33)優先権主張国 米国（ＵＳ） (72)発明者 デイビッドソン キャロライン スウィー ニー アメリカ合衆国 ニューハンプシャー州 03049 ホーリス ライドアウト ロード 155 (72)発明者 フェイマン ロバート ネイル ジュニア アメリカ合衆国 ニューハンプシャー州 03806 ウイルトン プットナム ヒル ロード （番地なし) (72)発明者 グラブ リチャード バリー アメリカ合衆国 マサチューセッツ州 01886 ウエストフォード キャリエイジ ウェイ ５ (72)発明者 ホブス スティーブン オー アメリカ合衆国 マサチューセッツ州 01886 ウエストフォード バターナット ロード 10 (72)発明者 マーフィー デニス ジョセフ アメリカ合衆国 マサチューセッツ州 01886 ウエストフォード デイポット ロード 86

Claims (9)

【特許請求の範囲】
1. 【請求項１】メモリを有するコンピュータシステムで実
   行され、ソースプログラムのコンパイル中にコード生成
   を実行して対応する目的モジュールを生じるコード生成
   方法であって、前記のソースプログラムのうちの第１の
   ソースプログラムが前記のメモリに記憶されており、第
   １のプログラム言語で書込まれたソース文を含むこの第
   １のソースプログラムをコンパイルして前記の対応する
   目的モジュールのうちの第１の目的モジュールを生ぜし
   める当該コード生成方法において、 前記の第１のソースプログラムに対する中間言語グラフ
   を生成する中間言語生成工程であって、前記の中間言語
   グラフはタプルを有するものであって前記の第１のソー
   スプログラムを中間言語で表現するものであり、各タプ
   ルは前記の第１のソースプログラムで実行すべき単一の
   処理を表すようになっている当該中間言語生成工程と、 前記の中間言語グラフの一部をコードテンプレートとマ
   ッチングさせるマッチング工程であって、前記のコード
   テンプレートは、前記の中間言語グラフの前記の一部に
   マッチングして前記の第１の目的モジュールの一部を生
   成する案内をする予め決定した中間言語パターンを含ん
   でいる当該マッチング工程と、 前記の中間言語グラフの前記の一部を解析し、前記のコ
   ードテンプレート中に含まれ前記の中間言語グラフの前
   記の一部中の式の評価順序を表す予め決定したアクショ
   ンを用いてこの評価順序を決定する解析工程と、 前記の予め決定したアクションを用い且つ前記の評価順
   序に応じて、変数に対しテンポラリネームを割当てると
   ともにこのテンポラリネームに割当ての生涯を割当て、
   この割当ての生涯が、テンポラリネーム及びその蓄積が
   前記の中間言語グラフ中で前記の変数と関連している存
   続範囲を表すようにする割当工程と、 前記の中間言語グラフの前記の一部におけるタプルを必
   要に応じ更新し、前記の予め決定したアクションによっ
   て示される前記の解析及び割当工程を実行する更新工程
   と、 前記の中間言語グラフ及び前記の予め決定したアクショ
   ンを用いることにより前記の目的モジュールの前記の一
   部に含まれる機械命令を生成する機械命令生成工程と を具えることを特徴とするコード生成方法。
2. 【請求項２】請求項１に記載のコード生成方法におい
   て、前記のテンポラリネームが局所的又は非局所的テン
   ポラリネームの１つであり、局所的テンポラリネームは
   前記の中間言語グラフの前記の一部に制限された生涯を
   有する可変割当てであり、非局所的テンポラリネームは
   前記の中間言語グラフの前記の一部を越えて継続する生
   涯を有する可変割当てであることを特徴とするコード生
   成方法。
3. 【請求項３】請求項２に記載のコード生成方法におい
   て、 前記のマッチング工程が前記の中間言語グラフの前記の
   一部に亘って第１パス中に実行し、 非局所的テンポラリネームを割当てるための前記の解析
   工程及び前記の割当て工程を、前記の中間言語グラフの
   前記の一部に亘って第２パス中に実行し、この一部を更
   新して前記の中間言語グラフの変更した一部を生ぜし
   め、 局所的テンポラリネームを割当てるための前記の割当て
   工程を前記の中間言語グラフの前記の変更した一部を用
   いて第３パス中に実行し、前記の変更した一部を更新し
   て前記の中間言語グラフの他の変更した一部を生ぜし
   め、 前記の機械命令生成工程を前記の中間言語グラフの前記
   の他の変更した一部に亘って第４パス中に実行すること
   を特徴とするコード生成方法。
4. 【請求項４】請求項１に記載のコード生成方法におい
   て、前記の予め決定したアクションのうちの１つが、前
   記のテンポラリメモリと関連する前記の変数が前記のメ
   モリ中に記憶されていることを表すことを特徴とするコ
   ード生成方法。
5. 【請求項５】請求項１に記載のコード生成方法におい
   て、前記の予め決定したアクションの１つが、前記のテ
   ンポラリネームと関連する前記の変数の１つがレジスタ
   に記憶されていることを表すことを特徴とするコード生
   成方法。
6. 【請求項６】請求項１に記載のコード生成方法におい
   て、前記の予め決定した中間言語パターンが結果値モー
   ドと、パターン木と、一連のブールテストと、前記のコ
   ードテンプレートにより生成されるコードのコストとを
   含み、前記の結果値モードが前記の第１の目的モジュー
   ルの前記の一部によって計算された結果値を表し、前記
   のパターン木が前記の予め決定した中間言語パターンの
   演算子及び被演算子を表し、前記の一連のブールテスト
   が、前記の予め決定した中間言語パターンが前記の中間
   言語グラフの前記の一部にマッチングしていることが真
   実であるというこの一部に関する文を表し、前記のコス
   トは整数として表されているとともにこのコストが生成
   コードの前記の一部と関連するパーフォーマンスコスト
   を表すことを特徴とするコード生成方法。
7. 【請求項７】請求項６に記載のコード生成方法におい
   て、前記のマッチング工程は、前記のコードテンプレー
   トに関連するコストと他のコードテンプレートに関連す
   るコストとを比較し、前記のコードテンプレート及び前
   記の他のコードテンプレートのうち最小の関連コストを
   有する方を選択する工程を含んでいることを特徴とする
   コード生成方法。
8. 【請求項８】請求項１に記載のコード生成方法におい
   て、前記の第１の目的モジュールを第１の目的コンピュ
   ータシステムに対するものとし、前記のソースプログラ
   ムのうちの第２のソースプログラムは、他の目的コンピ
   ュータシステムに対する前記の目的モジュールのうちの
   第２の目的モジュールを生じるようにコンパイルされる
   ことを特徴とするコード生成方法。
9. 【請求項９】メモリを有するコンピュータシステムに用
   いられ、ソースプログラムのコンパイル中にコード生成
   を実行して対応する目的モジュールを生じるコード生成
   装置であって、前記のソースプログラムのうちの第１の
   ソースプログラムが前記のメモリに記憶されており、第
   １のプログラム言語で書込まれたソース文を含むこの第
   １のソースプログラムをコンパイルして前記の対応する
   目的モジュールのうちの第１の目的モジュールを生ぜし
   める当該コード生成装置において、 前記の第１のソースプログラムに対する中間言語グラフ
   を生成する中間言語生成手段であって、前記の中間言語
   グラフはタプルを有するものであって前記の第１のソー
   スプログラムを中間言語で表現するものであり、各タプ
   ルは前記の第１のソースプログラムで実行すべき単一の
   処理を表すようになっている当該中間言語生成手段と、 前記の中間言語グラフの一部をコードテンプレートとマ
   ッチングさせるマッチング手段であって、前記のコード
   テンプレートは、前記の中間言語グラフの前記の一部に
   マッチングして前記の第１の目的モジュールの一部を生
   成する案内をする予め決定した中間言語パターンを含ん
   でいる当該マッチング手段と、 前記の中間言語グラフの前記の一部を解析し、前記のコ
   ードテンプレート中に含まれ前記の中間言語グラフの前
   記の一部中の式の評価順序を表す予め決定したアクショ
   ンを用いてこの評価順序を決定する解析手段と、 前記の予め決定したアクションを用い且つ前記の評価順
   序に応じて、変数に対しテンポラリネームを割当てると
   ともにこのテンポラリネームに割当ての生涯を割当て、
   この割当ての生涯が、テンポラリネーム及びその蓄積が
   前記の中間言語グラフ中で前記の変数と関連している存
   続範囲を表すようにする割当手段と、 前記の中間言語グラフの前記の一部におけるタプルを必
   要に応じ更新し、前記の予め決定したアクションによっ
   て示される前記の解析及び割当を実行する更新手段と、 前記の中間言語グラフ及び前記の予め決定したアクショ
   ンを用いることにより前記の目的モジュールの前記の一
   部に含まれる機械命令を生成する機械命令生成手段と を具えることを特徴とするコード生成装置。