JP5448976B2

JP5448976B2 - コード生成処理装置及びコード生成処理プログラム

Info

Publication number: JP5448976B2
Application number: JP2010081822A
Authority: JP
Inventors: 勝己奥田
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2010-03-31
Filing date: 2010-03-31
Publication date: 2014-03-19
Anticipated expiration: 2030-03-31
Also published as: JP2011215759A

Description

本発明は、計算機向け機械語プログラムを生成するためのコード生成処理装置に関し、特に、複数のソースプログラムを複数のオブジェクトファイルにコンパイルあるいはアセンブルし、その後、複数のオブジェクトファイルをリンクしてプロセッサが実行可能な機械語プログラムを生成するコード生成処理装置及びそのプログラムに関する。

一般のアセンブラやリンカの処理方式では、コード生成対象プロセッサの命令セットアーキテクチャに固有の情報をアセンブラやリンカのプログラムコード中に含んでいる。従って、命令セットアーキテクチャの新規開発や仕様変更をした場合、アセンブラやリンカのプログラムコードの新規開発や修正が必要となる。また、特定用途向けプロセッサの開発や構成可能プロセッサにおける拡張命令の開発においては、命令の追加、修正、削除が頻繁に発生するため、アセンブラやリンカなどの開発ツールの再構築に要する時間の短縮が課題となる。この課題に対し、従来、コード生成対象プロセッサの命令セットアーキテクチャに非依存なアセンブラの方式が提案されてきた。

例えば、特許文献１「アセンブラ処理方式」では、プロセッサの周辺リソース情報と命令構成情報をそれぞれ定義したファイルからテーブルを構築し、テーブルを基にソースプログラムからオブジェクトコードを生成するための方法が開示されている。この方法によれば、プロセッサの周辺リソース情報と命令構成情報のファイルを変更することによって、アセンブラの再構築を必要とすることなくプロセッサの仕様変更に対応すること可能である。

この他に、プロセッサに依存する情報を表としてアセンブラの処理から切り離した方式は特許文献２「機械語翻訳プログラム方式」でも開示されている。一般に、アセンブリ言語において命令オペランドとして記述される式の値は、必ずしもそのまま命令に格納されるとは限らない。アセンブラは、アセンブリ言語におけるオペランドの式の値にさらに演算を加えた後で、命令のフィールドに格納することを必要とする場合がある。つまり、実際の命令フィールドに格納されるときに適用される演算は、アセンブリ言語における命令オペランド毎に異なる。特許文献２による方法では、この命令フィールドへの格納時に必要となる演算を数式表として命令表に保持することによって、アセンブラの機種依存性を解消していた。

特開平８−２８６９２７号公報特開平４−７７４６号公報

しかしながら、上記従来の方法は、ソースプログラムを一旦オブジェクトファイルに変換し、複数のオブジェクトファイルをリンクして単一の実行可能ファイルを生成するコード生成方式に対応していない。コード生成処理が複数オブジェクトファイルのリンク処理を含む場合、アセンブラおよびリンカに機種依存性が残るため、プロセッサ仕様の変更は依然としてアセンブラプログラムおよびリンカプログラムの変更を必要とすることが問題となる。

以下では、リンク処理における機種依存性の説明を行う。特殊な機能を持った特定のアセンブリ言語記述に依存しないように、図２に示す単純な命令フォーマットとニーモニックの対応を持つアセンブリ言語を想定して説明を進める。命令フォーマット２０１は、オペコードと０個以上のフィールドから構成される。ここで、オペコードは、プロセッサが実行すべき命令を識別すためのコードを表す整数値である。命令のフィールドは、命令のオペランドを表現する整数値である。ただし、命令のオペランドと命令のフィールドは一対一に対応するとは限らない点に注意が必要である。例えば、命令がメモリオペランドを持つ場合、メモリオペランドは、メモリのベースアドレスを保持するレジスタの番号を保持するフィールドとベースアドレスからのオフセットを保持するフィールドの２つを用いて表現される場合もあり得る。ニーモニック２０２は、以降の説明で使用するアセンブリ言語のニーモニック表現である。ニーモニック表現は、命令名と０個以上の命令フィールドの文字列表現である。命令名は、オペコードに対応し、式はフィールドに対応する。式は、以下のＢＮＦで表現可能である。

式 := 数
| シンボル
| 式 + 式
| 式 - 式
| 式 * 式
| 式 / 式
| 式 % 式
| 式 >> 式
| 式 << 式
| 式 & 式
| 式 | 式
| ^ 式
| - 式
| ( 式 )

上記ＢＮＦにおける記号はＣ言語の演算子の意味、結合性、優先度に従うものとする。例えば、＋演算子は和を意味し、左結合を持ち、＊演算子より低い優先度を持つ。上記ＢＮＦにおける数は、正の整数値を表す文字列である。また、シンボルは、データや手続きのアドレス、セクション開始アドレスを。式の中におけるシンボルは、数式における変数と考えて良い。

例として、ＭＩＰＳアーキテクチャのＧＮＵアセンブラのアセンブリ言語表現おけるニーモニック
lui $1, %hi(foo)
という記述は、図２によるニーモニックでは
lui 1, foo >> 16
と記述される。
また、ＧＮＵアセンブラにおける
beq $1, $2, foo
は、図２におけるニーモニックでは、
beq 1, 2, foo - __pc
として記述することができる。beq命令は、汎用レジスタ１と汎用レジスタ２が等しい場合、アドレスfooに分岐することを表すニーモニックである。ここで、beq命令のアドレスフィールドはプログラムカウンタ相対アドレスであるため、実際の命令フィールドに格納される値はfooの値からプログラムカウンタの値を減じた値である。ここで __pc は、プログラムカウンタを表すシンボルである。

図２のニーモニック表現を入力とするアセンブラは、ニーモニックを機械語に変換する際、式の値を評価し、対応する命令フィールドに値を格納する。しかし、式がシンボルを含む場合、アセンブラは式の値を計算することができない。これは、シンボルの値がアセンブル時にではなくリンク時に決定するためである。リンカは、シンボルの値が決定した後に、リロケーション処理において式の値を計算し命令のフィールドに格納する。

ここで、リンカのリロケーション処理は、アセンブラが出力したオブジェクトファイルのどの位置がシンボルを参照していて、どのように式の値を計算し、値を格納するかについての情報（リロケーション情報）を必要とする。一般のリンク方式では、式の計算方法と値の格納方法についてアセンブラとリンカの間で共通のプロトコルを持つ。すなわち、式の計算方法と値の格納方法の組み合わせ毎に一意な番号をリロケーションタイプとして割り当て、アセンブラがオブジェクトファイルを介してリロケーションタイプをリンカに与えることによってリロケーションの方法を伝達する。したがって、プロセッサの仕様変更によって式の計算方法や格納位置が変わった場合にはアセンブラとリンカの間のプロトコルを変更する必要がある。しかし、このプロトコルの変更はアセンブラプログラムに対する変更だけでは不十分であり、リンカプログラムに対しても変更が必要である。

以上の理由により、従来のテーブルをベースとしたアセンブラでは、命令の生成において機種依存をなくすことができても、リンク処理に関して、機種依存性をなくすことができないという問題があった。

この発明は上記のような課題を解決するためになされたもので、リンク処理に影響を及ぼすプロセッサ仕様の変更や異なるプロセッサを対象とする場合でも再構築することなく利用可能なコード生成装置及びそのプログラムを得ることを目的とする。

この発明に係るコード生成処理装置は、ソースプログラムをオブジェクトファイルにコンパイルあるいはアセンブルし、その後、オブジェクトファイルをリンクしてプロセッサが実行可能な機械語プログラムを生成するコード生成処理装置において、オブジェクトファイルの生成時に、リロケーションを行うための計算手順と計算結果を格納すべきビット位置とをオブジェクトファイルと関連付けるオブジェクトファイル関連付け手段と、リンク時に、オブジェクトファイルと関連付けられたリロケーションを行うための計算手順と計算結果を格納すべきビット位置とを読み出し解釈することによってリロケーション処理を行うリロケーション処理手段とを備え、計算手順は、シンボル参照位置のうちの１つに直接または間接的に格納すべき値の計算手順として２つ以上の命令を含む命令列から構成され、命令は２つ以上のオペランドを使用し、オペランドは定数またはシンボルの値または事前に実行した命令の結果であり、命令列のうち少なくとも１つはシンボルの値を使用する命令であり、命令列のうち少なくとも２つの命令は演算命令であり、演算命令は算術演算命令の集合とビット演算命令の集合とシフト演算命令の集合とに含まれる全てまたは一部の演算命令の集合の中から選択されるものである。

この発明のコード生成処理装置は、リロケーションを行うための計算手順と計算結果を格納すべきビット位置とをオブジェクトファイルと関連付け、リロケーション処理手段は、オブジェクトファイルから、リロケーションを行うための計算手順と計算結果を格納すべきビット位置とを読み出し解釈することによってリロケーション処理を行うようにしたので、リンク処理に影響を及ぼすプロセッサ仕様の変更や異なるプロセッサを対象とする場合でも再構築することなく利用可能とすることができる。

本発明の実施の形態１によるコード生成処理装置の構成図である。本発明の実施の形態１によるコード生成処理装置の命令フォーマットとニーモニックとの対応を示す説明図である。本発明の実施の形態１によるコード生成処理装置の命令情報表の構成図である。本発明の実施の形態１によるコード生成処理装置のアセンブラのニーモニック処理のフローチャートである。本発明の実施の形態１によるコード生成処理装置の式と抽象構文木の対応を示す説明図である。本発明の実施の形態１によるコード生成処理装置のリロケーションプログラムの命令体系を示す説明図である。本発明の実施の形態１によるコード生成処理装置のリロケーションプログラム生成処理のフローチャートである。本発明の実施の形態１によるコード生成処理装置の抽象構文木プログラム変換を示すフローチャートである。本発明の実施の形態１によるコード生成処理装置のリロケーションプログラムコードを示す説明図である。本発明の実施の形態１によるコード生成処理装置のオブジェクトファイルの内部構成を示す説明図である。本発明の実施の形態１によるコード生成処理装置のリンク処理を示すフローチャートである。本発明の実施の形態１によるコード生成処理装置の領域連結処理を示すフローチャートである。本発明の実施の形態１によるコード生成処理装置のテーブル更新処理を示すフローチャートである。本発明の実施の形態１によるコード生成処理装置のリロケーション処理を示すフローチャートである。本発明の実施の形態１によるコード生成処理装置のシンボル値の取得手順を示すフローチャートである。本発明の実施の形態１によるコード生成処理装置のリロケーションプログラム実行時のスタック遷移を示す説明図である。

実施の形態１．
図１は、この発明の実施の形態１によるコード生成処理装置を示す構成図である。
図１に示すコード生成処理装置は、ソースファイル１０１と命令情報表１０２とを用いてオブジェクトファイル１０７を生成するオブジェクトファイル生成部１０３と、オブジェクトファイル１０７からリンク処理を行い、ロードモジュール１１６を出力するリンカ１１３とを備える。ここで、オブジェクトファイル生成部１０３とリンカ１１３は、コンピュータを用いて実現され、それぞれの機能に対応するソフトウェアとこれらのソフトウェアを実行するためのＣＰＵや主記憶装置といったハードウェアから構成されている。あるいはそれぞれ専用のハードウェアで構成されていてもよい。

ソースファイル１０１は、図２に示すニーモニック２０２を持つアセンブリ言語プログラムである。また、命令情報表１０２は、ソースファイル１０１が対象とするプロセッサの命令フォーマットを格納したテーブルであり、これについては後で詳述する。これらソースファイル１０１及び命令情報表１０２はそれぞれ磁気ディスクや光ディスクあるいはフラッシュメモリといった記憶媒体に格納されている。

オブジェクトファイル生成部１０３は、ソースファイル１０１と命令情報表１０２を入力とし、オブジェクトファイル１０７を生成するアセンブラであり、オブジェクトファイル関連付け手段を構成する。このオブジェクトファイル生成部１０３は、文法解析部１０４と機械語生成部１０５とリロケーション用命令列生成部１０６とを備えている。文法解析部１０４は、ソースファイル１０１を入力し、ソースファイル１０１に含まれるニーモニック行を命令名と複数の式に分割する処理部である。機械語生成部１０５は、命令情報表１０２に基づきオブジェクトファイル１０７に含まれる命令領域１０８を生成する処理部である。その他、機械語生成部１０５では、オブジェクトファイル１０７に含まれるデータ領域１０９やシンボルテーブル１１０、リロケーションテーブル１１１などを生成する。リロケーション用命令列生成部１０６は、リロケーションプログラム１１２を生成する。

オブジェクトファイル１０７は、命令領域１０８とデータ領域１０９、シンボルテーブル１１０、リロケーションテーブル１１１、リロケーションプログラム１１２など複数の領域を含む。ただし、これらの領域は、必ずしも単一のオブジェクトファイル１０７に格納されている必要はない。例えば、１つの領域毎に１つのファイルが割り当てられていても良い。また、オブジェクトファイル１０７は、磁気ディスクや光ディスクあるいはフラッシュメモリといった記憶媒体に格納されている。

命令領域１０８とデータ領域１０９は、ソースファイル１０１に含まれる命令やデータから変換された機械語である。ただし、ソースファイル１０１中のシンボル参照箇所は、正しい値が格納されていない状態である。

リンカ１１３は、リロケーション処理手段を構成するもので、一度に複数のオブジェクトファイル１０７を入力とし、プロセッサの主記憶に格納して実行することが可能なロードモジュール１１６を生成する。リンカ１１３は、複数のオブジェクトファイル１０７に含まれる命令領域１０８やデータ領域１０９を同じ種類の領域毎に結合する領域連結部１１４と、ロードモジュール１１６に含まれる命令領域１１７やデータ領域１１８に含まれるシンボル参照位置に正しい値を格納するリロケーションプログラムインタプリタ１１５を持つ。

次に、図３から図９を用いてオブジェクトファイルの生成処理手順の説明を行う。
図３は、命令情報表１０２の構成図である。命令情報表１０２の構築方法に関しては本発明と無関係であるため言及せず構成のみを示す。
命令情報表１０２は、列として命令名３０１、テンプレート３０２、命令サイズ３０３、フィールド情報３０４を持つ。命令名３０１は、命令情報表１０２において一意なエントリを識別する主キーである。テンプレート３０２は、命令のオペコードが格納され、オペコード以外のフィールドに０が格納された命令のテンプレートである。命令サイズ３０３は、命令のバイト数である。フィールド情報３０４は、命令のフィールドに関する情報をフィールド位置表３０５の形式で保持する。フィールド位置表３０５は、１つの命令のすべてのフィールドに対応する個々のエントリを持ち、各エントリはＬＳＢ位置３０６とＭＳＢ位置３０７を持つ。ＬＳＢ位置３０６は、フィールドのＬＳＢ（Least Significant Bit）が存在する命令中でのビット位置を表す。また、ＭＳＢ位置３０７は、フィールドのＭＳＢ（Most Significant Bit）が存在する命令中でのビット位置を表す。尚、図３の命令情報表１０２の構成は、ＪＳＯＮやＹＡＭＬなど一般的なデータ格納用のフォーマットで容易に表現可能かつ記憶媒体に格納可能である。

図４は、アセンブラの処理のうち、機械語生成部１０５がニーモニックの一行に対する機械語生成を行うための処理手順を表すフローチャートである。ここで、機械語生成部１０５が処理を開始する時点で文法解析部１０４がニーモニック行を命令名と０個以上の式に分割しているものとする。また、文法解析部１０４は、文字列表現の式を抽象構文木の形式に変換し、コンピュータの主記憶装置上に格納するものとする。

ステップＳＴ４０１は、命令名をキーとして命令情報表１０２から命令のテンプレート３０２、命令サイズ３０３、フィールド情報３０４を取得する処理である。ステップＳＴ４０２は、命令のテンプレートから命令を作成する処理である。ステップＳＴ４０３〜ＳＴ４０８を含むループ（Ａ）は、１回の実行でニーモニック行に含まれる１つの式を処理し、ニーモニックが式を含まない場合は１回も実行されない。

ステップＳＴ４０３は、ステップＳＴ４０２で取得したフィールド情報３０４から式の値を格納すべき命令中のＬＳＢ位置３０６とＭＳＢ位置３０７を取得する処理である。フィールド情報３０４が保持するフィールド位置表３０５のエントリは、１つの式と一対一に対応している。例えば、ニーモニック中の先頭の式の値を格納すべき位置は、フィールド位置表３０５の先頭のエントリが保持している。

ステップＳＴ４０４は、式の値を計算する処理である。式がシンボルを含む場合、シンボルを含まない部分式のみ計算し、式の簡略化を行っても良い。
ステップ４０５は分岐処理であり、式がシンボルを含まない場合はステップＳＴ４０６を行い、式がシンボルを含む場合は、ステップＳＴ４０７〜ＳＴ４０８を行う。

ステップＳＴ４０６は、ステップＳＴ４０４で計算した値をステップＳＴ４０２で作成した命令中に格納する。ここで命令中での格納位置は、ステップＳＴ４０３で取得した位置である。ステップＳＴ４０７は、リロケーション用命令列生成部１０６が行う処理であり、命令フィールドのＬＳＢ位置と命令フィールドのＭＳＢ位置と式を入力としてリロケーション用プログラムコードを生成する。

ステップＳＴ４０８は、現在処理中の式に関してリロケーションテーブル１１１のエントリを作成する処理である。ステップＳＴ４０８では、オブジェクトファイル１０７中でリロケーション処理が必要な箇所に対応するリロケーションプログラム１１２の位置をリロケーションテーブル１１１のエントリに格納する。

ステップＳＴ４０９は、現在処理中の命令を含む領域に対応するバッファに命令を格納する処理である。この領域はアセンブラにおける一般的な．ｔｅｘｔセクションであるが、その他に定義されたセクションであっても良い。

次に、ステップＳＴ４０７の処理手順を説明する前に、ステップＳＴ４０７の入出力を明らかにするために、入力となる抽象構文木のデータ構造と出力となるリロケーションプログラムに含まれる命令体系について順に説明する。
抽象構文木は、式中の演算子をノードとし、式中の数あるいはシンボルをリーフとするツリー構造である。すなわち、抽象構文木においてノードは演算子をラベルとし、リーフは式数あるいはシンボルをラベルとする。例として、式と抽象構文木の対応を図５に示す。文字列表現の式５０１は、抽象構文木５０２で表現される。式５０１中の演算子である＋と＞＞は、抽象構文木５０２ではノードとして表現され、式中のシンボルｆｏｏと数４および２はリーフとして表される。

図６は、リロケーションプログラム１１２を表現するための命令体系図である。リロケーションプログラム１１２は、スタックマシンで解釈可能な命令体系を持つ。各々の命令は、一つの一意なオペコードを持ち、互いに区別することが可能である。値格納命令６０１は、ｆｉｌｌ命令のみであり、オブジェクトファイル１０７中のシンボル参照位置に対して、リンク時に計算した値を格納するための命令である。ｆｉｌｌ命令は、三つのスタックオペランドをとり、スタックの上から順に値を格納すべきＭＳＢ位置、ＬＳＢ位置、格納すべき値を取得する。

スタック操作命令６０２は、スタックにオペランドを積む命令である。オペランドの種類は、即値とシンボルのいずれかである。即値の場合はｐｕｓｈｉ命令が対応し、シンボルの場合はｐｕｓｈｓ命令が対応する。ｐｕｓｈｉ命令は、即値オペランドで与えられる値をスタックに積むための命令である。一方、ｐｕｓｈｓ命令は、シンボルに対応するシンボルテーブルエントリのインデックスを即値オペランドとし、シンボルテーブル１１０中の当該インデックスのシンボルの値をスタックに積む。ここでシンボルテーブル１１０は、オブジェクトファイル１０７に含まれるシンボルの一覧を表す一般的なシンボルテーブルである。

演算命令６０３は、スタックオペランドに対して演算を行い、演算結果をスタックに積む命令である。各演算命令は、式に現れる演算子に対応している。

図７は、リロケーション用命令列生成部１０６が行うリロケーションプログラムコード生成処理の手順を表すフローチャートである。
リロケーションプログラムコード生成処理は、式の抽象構文木と式の値を格納すべき場所を特定するためのＬＳＢ位置およびＭＳＢ位置を入力とし、リロケーション用のプログラムを出力する処理である。ステップＳＴ７０１は、抽象構文木に対応するリロケーションプログラムコードを出力する処理である。次のステップＳＴ７０２とステップＳＴ７０３は、それぞれＬＳＢ位置とＭＳＢ位置をスタックに積むための命令を出力する。最後にステップＳＴ７０４の処理は、値格納命令であるｆｉｌｌ命令を出力する。

図８は、図７のステップＳＴ７０１の抽象構文木プログラム変換処理の処理手順を表すフローチャートである。尚、図８では、抽象構文木を入力とし、帰りがけ順でノードを巡回し命令列を出力する処理手順を再帰手続きで実現している点に注意が必要である。ステップＳＴ８０１は、ルートノードがリーフであればステップＳＴ８０２を実行し、ルートノードがリーフでなければ、ステップＳＴ８０３を含むループＡとステップＳＴ８０４を実行する分岐処理である。ステップＳＴ８０２は、リーフの種類に応じてスタック操作命令６０２から適切な命令を出力する。ステップＳＴ８０３を含むループＡは、ルートノードのすべての子ノードに対してステップＳＴ８０３を行うループである。ステップＳＴ８０３は、現在の子ノードを新たなルートノードとして設定して自己再起処理を行う。ステップＳＴ８０４は現在処理中のノードのラベルである演算子に対応する演算命令６０３を出力する。

リロケーションプログラムコード生成処理の動作例として、図５の抽象構文木５０２とＬＳＢ位置として０、ＭＳＢ位置として１５を入力とした際の図７、図８の処理による出力結果を図９に示す。リロケーションプログラム数値表現９０１は、記憶媒体に格納されたリロケーションプログラム１１２の数値表現を表わす。また、リロケーションプログラム文字列表現９０２は、リロケーションプログラム数値表現９０１に対応する文字列表現を表わす。図８のフローチャートによる抽象構文木５０２の巡回は、帰りがけ順でｆｏｏ、４、＋、２、＞＞で行われ、対応する命令列としてリロケーションプログラム文字列表現９０２の命令列が出力される。その後、図８の後半処理によって、ＬＳＢ位置０とＭＳＢ位置１５をスタックに格納する命令が出力され、最後に値格納命令ｆｉｌｌ命令が出力される。

次に、図１０を用いてリロケーション用の計算手順と計算結果のビット単位の格納位置をオブジェクトファイル１０７と関連付ける方式を説明する。図１０は、オブジェクトファイル生成部１０３が生成するオブジェクトファイル１０７の内部構成図でありそのフォーマットをオブジェクトファイル１００１として示す。本実施の形態では、計算手順と計算結果の格納位置をいずれもリロケーションプログラム１１２としてオブジェクトファイル１００１中に格納している。オブジェクトファイルフォーマットは、一般的なＥＬＦ形式である。オブジェクトファイル１００１は、一般的なＥＬＦオブジェクトファイルが持つべきシンボルテーブル１００４やリロケーションテーブル１００２に加えてリロケーションプログラム領域１００３を持つ。ＥＬＦ形式では、リロケーションテーブルは、リロケーションを必要とするオブジェクトファイルの領域毎に存在する。ここでは、リロケーションテーブル１００２は、コード領域用のリロケーションテーブルである。リロケーションテーブル１００２の各エントリは、コード領域中でリロケーション処理が必要なバイト単位の位置を領域先頭からオフセットをリロケーション位置オフセットとして保持している。

一般のＥＬＦファイルでは、リロケーションテーブルエントリは、位置オフセットに加えて、ｒ＿ｉｎｆｏフィールドに機種依存のリロケーションタイプとシンボルテーブルインデックスを保持するが、本実施の形態では、シンボルテーブルインデックスの代わりにリロケーションプログラム領域１００３中のリロケーションプログラムのエントリポイントへのバイトオフセットを保持している。リロケーションプログラム領域１００３は、リロケーションテーブル１００２と同様、オブジェクトファイル１００１中のリロケーションを必要とする領域毎に存在し、コード領域と対応している。この対応は、リロケーションプログラム領域１００３の名前．ｒｅｌｐ．ｔｅｘｔの末尾がコード領域の名前．ｔｅｘｔと一致していることによって判別可能である。リロケーションプログラム領域１００３中のプログラムにおけるシンボルの参照は、シンボルテーブル１００４中のインデックスで表現される。尚、本実施の形態ではＥＬＦオブジェクトファイルを用いているが、その他のオブジェクトファイルフォーマットであっても類似の方法で本発明を実施可能である。

以下では、一つ以上のオブジェクトファイルを入力とし、単一の実行可能ファイルを生成するリンカ１１３の処理手順を図１１〜１５を用いて説明する。
図１１は、リンカ処理を表すフローチャートである。ステップＳＴ１１０１を含むループＡは、領域連結部１１４が、１回の実行で１つのオブジェクトファイルに対して領域連結処理を実行する。ステップ１１０２を含むループＢでは、リロケーションプログラムインタプリタ１１５が、個々のオブジェクトファイルに関連するリロケーションテーブルを基にリロケーション処理を行う。

図１２は、ステップＳＴ１１０１の領域連結処理の手順を示すフローチャートである。領域連結処理は、オブジェクトファイルに含まれるすべてのセクションに対してＳＴ１２０１〜ＳＴ１２０３の処理を行う（ループＡ）。ステップＳＴ１２０１は、処理中のセクションが出力対象セクション、すなわち実行可能ファイル中に含ませるべきセクションであれば、ステップＳＴ１２０２〜ステップＳＴ１２０３を実行する分岐処理である。通常ここでは、．ｔｅｘｔセクションや．ｄａｔａセクションなどが処理される。ステップＳＴ１２０２は、セクションを実行可能ファイルに出力する処理である。尚、セクションを実行ファイル中のどこに含ませるかといった情報や出力すべきセクションの判断基準などは、リンカスクリプトやコマンドラインオプションなどよく知られた方法でリンカ１１３に与えられるものとする。ステップＳＴ１２０３は、ステップＳＴ１２０２でセクションに割り当てられた開始アドレスを各種テーブルに反映するためのテーブル更新処理である。

図１３は、ステップＳＴ１２０３のテーブル更新処理の処理手順を示すフローチャートである。テーブル更新処理は、シンボルテーブル１１０とリロケーションテーブル１１１など個々のオブジェクトファイル１０７に付随する情報を更新するほか、出力可能実行ファイルに含まれるグローバルシンボルの情報を含むグローバルシンボルテーブルを更新する。ステップＳＴ１３０１〜ステップ１３０３を含むループＡは、オブジェクトファイル１０７からコピーしたシンボルテーブル１１０のすべてのエントリに対して処理を行うループである。ステップＳＴ１３０１は、セクション開始アドレスをシンボルテーブルエントリの値フィールドに加算する処理である。オブジェクトファイル１０７中においてシンボルテーブルエントリの値フィールドは処理中のセクション開始位置からのバイトオフセットであるが、ステップＳＴ１３０１で処理中のセクション先頭アドレスを加えることによってシンボルの最終的な値が決定する。

ステップＳＴ１３０２は、処理中のシンボルテーブルエントリがグローバルのシンボルであればステップＳＴ１３０３を実行する分岐処理である。ステップＳＴ１３０３は、現在処理中のシンボルテーブルエントリをグローバルなシンボルテーブルに追加する。ステップＳＴ１３０４を含むループＢは、オブジェクトファイル１０７からコピーしたリロケーションテーブル１１１のすべてのエントリに対して処理を行うためのループである。ステップＳＴ１３０４は、リロケーションエントリに含まれるリロケーション位置オフセットに対して、統合された領域における現在処理中の領域の先頭までのオフセットを加える。ステップＳＴ１３０４の処理は、現在作成中の実行可能ファイルの中からリロケーション処理が必要な位置を後のリロケーション処理が取得できるようにするための処理である。

図１４は、図１１におけるステップＳＴ１１０２のリロケーション処理の処理手順を示すフローチャートである。ステップＳＴ１４０１〜ステップＳＴ１４０３を含むループは、１つのオブジェクトファイル１０７に関連するリロケーションテーブル１１１に含まれるすべてのリロケーションテーブルエントリに対して処理を行うループである。ステップＳＴ１４０１は、テーブルエントリから位置オフセットを取得する処理である。テーブル更新処理ＳＴ１２０３によって位置オフセットは、統合された領域の先頭からのオフセットに置き換わっている。ステップＳＴ１４０２は、リロケーションテーブルエントリからリロケーションプログラム１１２の開始位置を取得する処理である。ステップＳＴ１４０３は、ステップＳＴ１４０３は、スタックマシンを模擬することによってリロケーションプログラム１１２を解釈実行する。

ステップＳＴ１４０３におけるリロケーションプログラム１１２がｐｕｓｈｓ命令を含む場合、シンボルテーブル１１０を参照する。図１５は、これを示すためのフローチャートであり、ｐｕｓｈｓ命令解釈実行におけるシンボル値取得手順を示す。ステップＳＴ１５０１は、ｐｕｓｈｓ命令の即値オペランドからシンボルテーブルインデックスを取得する処理である。ステップＳＴ１５０２は、オブジェクトファイル１０７からコピーしたシンボルテーブルからステップＳＴ１５０１で取得したインデックスを元にエントリを取得する処理である。ステップＳＴ１５０３は、ＳＴ１５０２で取得したシンボルテーブルエントリからシンボルが外部シンボルであるかをチェックし、シンボルが外部シンボルでなければステップＳＴ１５０４を実行し、そうでなければステップＳＴ１５０５を実行する。

ステップＳＴ１５０４は、ステップＳＴ１５０２で取得したエントリが保持するシンボル値をスタックにプッシュする処理である。ステップＳＴ１５０５は、シンボルテーブルエントリから対応する文字列を取得する処理である。ＥＬＦファイルでは、シンボルテーブルエントリが文字列テーブルのオフセットを保持しており、文字列テーブル先頭から当該オフセットを加算した位置から０終端の文字列を取得することができる。ステップＳＴ１５０６は、シンボル名がプログラムカウンタとして予約されていないかどうかを判断し、プログラムカウンタであればステップＳＴ１５０７を実行し、そうでなければステップＳＴ１５０８を実行する。

ステップＳＴ１５０７は、プログラムカウンタの値をスタックにプッシュする処理である。プログラムカウンタの値は、ステップＳＴ１４０１で取得した領域先頭からの位置オフセットに領域先頭開始アドレスを加算することによって求める。ステップＳＴ１５０８は、シンボル名をキーとしてグローバルシンボルテーブルをルックアップする処理である。ステップＳＴ１５０９では、ステップＳＴ１５０８の処理が成功していればステップＳＴ１５１０を実行し、そうでなければエラーとする処理である。ステップＳＴ１５１０は、ステップ１５０８で取得したグローバルシンボルテーブルエントリの値をスタックにプッシュする処理である。

リロケーションプログラム１１２の実行例として図１０のリロケーションプログラムを入力としてステップＳＴ１４０３を実行するときの様子を図１６に示す。ステップＳＴ１６０１ではｐｕｓｈｓ命令によって数値０ｘ１００がスタックに積まれる。ｐｕｓｈｓ命令のオペランドはシンボルテーブルインデックスであるので、オペランドの１がそのままスタックに積まれるのではなく、シンボルテーブルの１番目のエントリの値としてここでは０ｘ１００がスタックに積まれる。ステップＳＴ１６０２は、ｐｕｓｈｉ命令によって数値０ｘ４が積まれる。ステップＳＴ１６０３でａｄｄ命令はスタックトップに存在する２つの値０ｘ４と０ｘ１００をポップし、加算した結果の値０ｘ１０４をスタックに積む。ステップＳＴ１６０４では、ｐｕｓｈｉ命令が数値０ｘ２をスタックに積む。ステップＳＴ１６０５では、ｓｈｒ命令がスタックから２つの値０ｘ２と０ｘ１０４をポップし、０ｘ１０４を２ビット右シフトした値０ｘ８２をスタックに積む。ステップＳＴ１６０６とステップＳＴ１６０７では、ｐｕｓｈｉ命令によってそれぞれ値０ｘ０と０ｘＦをスタックに積む。最後にステップＳＴ１６０７では、ｆｉｌｌ命令の解釈実行によってスタックから値０ｘＦ、０ｘ０、０ｘ８２をポップし、ステップＳＴ１４０１で取得した実行可能ファイルのバイトオフセットから０ビットの位置をＬＳＢ、１５（０ｘＦ）ビットの位置をＭＳＢとして値０ｘ８２を格納する。

尚、上記例では、オブジェクトファイル生成部１０３をアセンブラとしたが、直接オブジェクトファイルを生成するようなコンパイラであっても良い。

以上のように、実施の形態１のコード生成処理装置によれば、ソースプログラムをオブジェクトファイルにコンパイルあるいはアセンブルし、その後、オブジェクトファイルをリンクしてプロセッサが実行可能な機械語プログラムを生成するコード生成処理装置において、オブジェクトファイルの生成時に、リロケーションを行うための計算手順と計算結果を格納すべきビット位置とをオブジェクトファイルと関連付けるオブジェクトファイル関連付け手段と、リンク時に、オブジェクトファイルと関連付けられたリロケーションを行うための計算手順と計算結果を格納すべきビット位置とを読み出し解釈することによってリロケーション処理を行うリロケーション処理手段とを備えたので、命令セットアーキテクチャ毎に固有のリンカを構築する必要がなくなり、また、アセンブリ言語記述において、オペランドに従来より複雑な式を記述することができる。

また、実施の形態１のコード生成処理装置によれば、オブジェクトファイル関連付け手段は、命令中でのビット位置を示す命令情報表に基づいてリロケーション時の計算結果を格納すべきビット位置を決定し、オブジェクトファイルと関連付けるようにしたので、容易にリロケーション時の計算結果を格納すべきビット位置を決定することができる。

また、実施の形態１のコード生成処理装置によれば、オブジェクトファイル関連付け手段は、計算手順と計算結果の格納位置をリロケーションプログラムとしてオブジェクトファイル中に格納するようにしたので、オブジェクトファイルのリンク時にリロケーションに必要な計算方法と計算結果の格納位置を容易に取得することができる。

また、実施の形態１のコード生成処理装置によれば、オブジェクトファイルは記憶媒体に格納されるようにしたので、オブジェクトファイルをリンクするリンカとしてオブジェクトファイル関連付け手段とは独立したものを用いることができる。

また、実施の形態１のコード生成処理プログラムによれば、ソースプログラムをオブジェクトファイルにコンパイルあるいはアセンブルするオブジェクトファイル生成部と、オブジェクトファイルをリンクしてプロセッサが実行可能な機械語プログラムを生成するリンカとをコンピュータ上に実現するコード生成処理プログラムであって、オブジェクトファイルの生成時に、リロケーションを行うための計算手順と計算結果を格納すべきビット位置とをオブジェクトファイルと関連付けるオブジェクトファイル関連付け手段と、リンク時に、オブジェクトファイルと関連付けられたリロケーションを行うための計算手順と計算結果を格納すべきビット位置とを読み出し解釈することによってリロケーション処理を行うリロケーション処理手段としてコンピュータを機能させるようにしたので、リンク処理に影響を及ぼすプロセッサ仕様の変更や異なるプロセッサを対象とする場合でも再構築することなく利用可能とすることのできるコード生成処理装置をコンピュータ上に実現することができる。

１０１ソースファイル、１０２命令情報表、１０３オブジェクトファイル生成部、１０４文法解析部、１０５機械語生成部、１０６リロケーション用命令列生成部、１０７オブジェクトファイル、１０８命令領域、１０９データ領域、１１０シンボルテーブル、１１１リロケーションテーブル、１１２リロケーションプログラム、１１３リンカ、１１４領域連結部、１１５リロケーションプログラムインタプリタ、１１６ロードモジュール、１１７命令領域、１１８データ領域。

Claims

ソースプログラムをオブジェクトファイルにコンパイルあるいはアセンブルし、その後、前記オブジェクトファイルをリンクしてプロセッサが実行可能な機械語プログラムを生成するコード生成処理装置において、
前記オブジェクトファイルの生成時に、リロケーションを行うための計算手順と計算結果を格納すべきビット位置とを当該オブジェクトファイルと関連付けるオブジェクトファイル関連付け手段と、
前記リンク時に、前記オブジェクトファイルと関連付けられたリロケーションを行うための計算手順と計算結果を格納すべきビット位置とを読み出し解釈することによってリロケーション処理を行うリロケーション処理手段とを備え、
前記計算手順は、シンボル参照位置のうちの１つに直接または間接的に格納すべき値の計算手順として２つ以上の命令を含む命令列から構成され、前記命令は２つ以上のオペランドを使用し、前記オペランドは定数またはシンボルの値または事前に実行した命令の結果であり、前記命令列のうち少なくとも１つはシンボルの値を使用する命令であり、前記命令列のうち少なくとも２つの命令は演算命令であり、前記演算命令は算術演算命令の集合とビット演算命令の集合とシフト演算命令の集合とに含まれる全てまたは一部の演算命令の集合の中から選択される
ことを特徴とするコード生成処理装置。
オブジェクトファイル関連付け手段は、命令中でのビット位置を示す命令情報表に基づいてリロケーション時の計算結果を格納すべきビット位置を決定し、オブジェクトファイルと関連付けることを特徴とする請求項１記載のコード生成処理装置。
オブジェクトファイル関連付け手段は、計算手順と計算結果の格納位置をリロケーションプログラムとしてオブジェクトファイル中に格納することを特徴とすることを特徴とする請求項１または請求項２記載のコード生成処理装置。
オブジェクトファイルは記憶媒体に格納されることを特徴とする請求項３記載のコード生成処理装置。
ソースプログラムをオブジェクトファイルにコンパイルあるいはアセンブルするオブジェクトファイル生成部と、前記オブジェクトファイルをリンクしてプロセッサが実行可能な機械語プログラムを生成するリンカとをコンピュータ上に実現するコード生成処理プログラムであって、
前記オブジェクトファイルの生成時に、リロケーションを行うための計算手順と計算結果を格納すべきビット位置とを当該オブジェクトファイルと関連付けるオブジェクトファイル関連付け手段と、
前記リンク時に、前記オブジェクトファイルと関連付けられたリロケーションを行うための計算手順と計算結果を格納すべきビット位置とを読み出し解釈することによってリロケーション処理を行うリロケーション処理手段としてコンピュータを機能させ、
前記計算手順は、シンボル参照位置のうちの１つに直接または間接的に格納すべき値の計算手順として２つ以上の命令を含む命令列から構成され、前記命令は２つ以上のオペランドを使用し、前記オペランドは定数またはシンボルの値または事前に実行した命令の結果であり、前記命令列のうち少なくとも１つはシンボルの値を使用する命令であり、前記命令列のうち少なくとも２つの命令は演算命令であり、前記演算命令は算術演算命令の集合とビット演算命令の集合とシフト演算命令の集合とに含まれる全てまたは一部の演算命令の集合の中から選択される
ことを特徴とするコード生成処理プログラム。