(57)【要約】【課題】セグメントレジスタへの設定コードを最小限に抑えて、オブジェクトのコードサイズを削減する。【解決手段】１回目のコンパイルで従来のコンパイラと同様にオブジェクトコードを生成する。この場合は、セグメントレジスタに値を設定するコードを生成する。このコードを受け取ったリンカが「変数がどのセグメント番号に割り当たるか」という情報（この情報の集合体を「セグメント情報」と呼ぶ）を出力し、その情報を利用して再度コンパイルする。２回目以降のコンパイル時にはセグメント情報から変数のセグメント番号が分かっているので、セグメントレジスタの書き換えが必要かどうか分かる。セグメントレジスタの書き換えが不要だと分かればセグメントレジスタの設定コードを削減することができる。【選択図】図４
2011123719.tif 000002
【特許請求の範囲】
【請求項１】
ソースプログラムファイルを読み込み、前記ソースプログラムファイルに基づいて、オブジェクトコードを生成するコンパイラと、
前記オブジェクトコードを読み込み、前記オブジェクトコードに基づいて、関数及び変数のメモリ配置が確定したロードモジュールファイルと、変数がどのセグメント番号に割り当たるかを示す情報の集合体であるセグメント情報とを生成するリンカと
を含み、
前記コンパイラは、
前記セグメント情報を読み込むセグメント情報設定部と、
前記セグメント情報が存在しない場合、セグメントレジスタに値を設定するオブジェクトコードを生成するコード生成部と
を具備する
言語処理システム。
【請求項２】
請求項１に記載の言語処理システムであって、
前記セグメント情報は、
変数のシンボル情報と、
所定のサイズのアドレス空間に収まるｎｅａｒデータか、前記所定のサイズのアドレス空間に収まらないｆａｒデータかを示す情報と、
ｆａｒデータであればセグメント番号と
を有する
言語処理システム。
【請求項３】
請求項２に記載の言語処理システムであって、
前記コード生成部は、データアクセスの際にｆａｒデータかどうかを判定し、ｆａｒデータである場合、前記セグメントレジスタの値が変更されたか否か判定し、前記セグメントレジスタの値が変更された場合、もしくは前記セグメント情報が存在せず判定不能の場合、セグメント番号を前記セグメントレジスタに設定してからオブジェクトコードを生成する
言語処理システム。
【請求項４】
請求項２に記載の言語処理システムであって、
前記コード生成部は、データアクセスの際にｆａｒデータかどうかを判定し、ｆａｒデータではない場合、もしくはｆａｒデータであっても、前記セグメントレジスタの値が変更されたか否か判定した際に、前記セグメントレジスタの値が変更されていない場合、セグメント番号を前記セグメントレジスタに設定するオブジェクトコードを不要とする
言語処理システム。
【請求項５】
請求項２乃至４のいずれか一項に記載の言語処理システムであって、
前記コンパイラによる１回目のコンパイルの際、前記コード生成部は、データアクセスの際にｆａｒデータかどうかを判定し、ｆａｒデータの場合、前記セグメント情報の参照を試み、前記セグメント情報が存在しない場合、判定不能として前記セグメントレジスタに値を設定するオブジェクトコードを生成し、
前記リンカは、前記コード生成部が生成したオブジェクトコードを基にメモリ配置を決定し、各変数のアドレスが確定した後、前記セグメント情報を生成し、
前記コンパイラによる２回目以降のコンパイルの際、前記セグメント情報設定部は、前記セグメント情報を読み込み、前記コンパイラ内部で変数のセグメント番号を情報として保持し、
前記コード生成部は、データアクセスの際にｆａｒデータかどうかを判定し、ｆａｒデータの場合、前記セグメント情報の参照を試み、前記セグメント情報が存在する場合、前記セグメントレジスタの値と変数のセグメント番号とを比較し、前記セグメントレジスタの値と変数のセグメント番号とが同じであれば、前記セグメントレジスタを設定するオブジェクトコードを生成せず、前記セグメントレジスタの値と変数のセグメント番号とが同じでなければ、前記セグメントレジスタを設定するオブジェクトコードを生成する
言語処理システム。
【請求項６】
コンパイラにより、ソースプログラムファイルを読み込み、前記ソースプログラムファイルに基づいて、オブジェクトコードを生成することと、
リンカにより、前記オブジェクトコードを読み込み、前記オブジェクトコードに基づいて、関数及び変数のメモリ配置が確定したロードモジュールファイルと、変数がどのセグメント番号に割り当たるかを示す情報の集合体であるセグメント情報とを生成することと、
前記コンパイラにより、前記セグメント情報を読み込むことと、
前記セグメント情報が存在しない場合、前記コンパイラにより、セグメントレジスタに値を設定するオブジェクトコードを生成することと
を含む
言語処理方法。
【請求項７】
請求項６に記載の言語処理方法であって、
前記セグメント情報は、
変数のシンボル情報と、
所定のサイズのアドレス空間に収まるｎｅａｒデータか、前記所定のサイズのアドレス空間に収まらないｆａｒデータかを示す情報と、
ｆａｒデータであればセグメント番号と
を有する
言語処理方法。
【請求項８】
請求項７に記載の言語処理方法であって、
前記コンパイラにより、データアクセスの際にｆａｒデータかどうかを判定することと、
ｆａｒデータである場合、前記セグメントレジスタの値が変更されたか否か判定することと、
前記セグメントレジスタの値が変更された場合、もしくは前記セグメント情報が存在せず判定不能の場合、セグメント番号を前記セグメントレジスタに設定してからオブジェクトコードを生成することと
を更に含む
言語処理方法。
【請求項９】
請求項７に記載の言語処理方法であって、
前記コンパイラにより、データアクセスの際にｆａｒデータかどうかを判定することと、
ｆａｒデータではない場合、もしくはｆａｒデータであっても、前記セグメントレジスタの値が変更されたか否か判定した際に、前記セグメントレジスタの値が変更されていない場合、セグメント番号を前記セグメントレジスタに設定するオブジェクトコードを不要とすることと
を更に含む
言語処理方法。
【請求項１０】
請求項７乃至９のいずれか一項に記載の言語処理方法であって、
前記コンパイラによる１回目のコンパイルの際、データアクセスの際にｆａｒデータかどうかを判定し、ｆａｒデータの場合、前記セグメント情報の参照を試み、前記セグメント情報が存在しない場合、判定不能として前記セグメントレジスタに値を設定するオブジェクトコードを生成することと、
前記リンカにより、前記コンパイラが生成したオブジェクトコードを基にメモリ配置を決定し、各変数のアドレスが確定した後、前記セグメント情報を生成することと、
前記コンパイラによる２回目以降のコンパイルの際、前記セグメント情報を読み込み、前記コンパイラ内部で変数のセグメント番号を情報として保持することと、
前記コンパイラにより、データアクセスの際にｆａｒデータかどうかを判定し、ｆａｒデータの場合、前記セグメント情報の参照を試み、前記セグメント情報が存在する場合、前記セグメントレジスタの値と変数のセグメント番号とを比較し、前記セグメントレジスタの値と変数のセグメント番号とが同じであれば、前記セグメントレジスタを設定するオブジェクトコードを生成せず、前記セグメントレジスタの値と変数のセグメント番号とが同じでなければ、前記セグメントレジスタを設定するオブジェクトコードを生成することと
を更に含む
言語処理方法。
【請求項１１】
コンパイラとして、ソースプログラムファイルを読み込み、前記ソースプログラムファイルに基づいて、オブジェクトコードを生成するステップと、
リンカとして、前記オブジェクトコードを読み込み、前記オブジェクトコードに基づいて、関数及び変数のメモリ配置が確定したロードモジュールファイルと、変数がどのセグメント番号に割り当たるかを示す情報の集合体であるセグメント情報とを生成するステップと、
前記コンパイラとして、前記セグメント情報を読み込むステップと、
前記セグメント情報が存在しない場合、前記コンパイラとして、セグメントレジスタに値を設定するオブジェクトコードを生成するステップと
を計算機に実行させるための
言語処理用プログラム。
【請求項１２】
請求項１１に記載の言語処理用プログラムであって、
前記セグメント情報は、
変数のシンボル情報と、
所定のサイズのアドレス空間に収まるｎｅａｒデータか、前記所定のサイズのアドレス空間に収まらないｆａｒデータかを示す情報と、
ｆａｒデータであればセグメント番号と
を有する
言語処理用プログラム。
【請求項１３】
請求項１２に記載の言語処理用プログラムであって、
前記コンパイラとして、データアクセスの際にｆａｒデータかどうかを判定するステップと、
ｆａｒデータである場合、前記セグメントレジスタの値が変更されたか否か判定するステップと、
前記セグメントレジスタの値が変更された場合、もしくは前記セグメント情報が存在せず判定不能の場合、セグメント番号を前記セグメントレジスタに設定してからオブジェクトコードを生成するステップと
を更に計算機に実行させるための
言語処理用プログラム。
【請求項１４】
請求項１２に記載の言語処理用プログラムであって、
前記コンパイラとして、データアクセスの際にｆａｒデータかどうかを判定するステップと、
ｆａｒデータではない場合、もしくはｆａｒデータであっても、前記セグメントレジスタの値が変更されたか否か判定した際に、前記セグメントレジスタの値が変更されていない場合、セグメント番号を前記セグメントレジスタに設定するオブジェクトコードを不要とするステップと
を更に計算機に実行させるための
言語処理用プログラム。
【請求項１５】
請求項１２乃至１４のいずれか一項に記載の言語処理用プログラムであって、
前記コンパイラとして実施する１回目のコンパイルの際、データアクセスの際にｆａｒデータかどうかを判定し、ｆａｒデータの場合、前記セグメント情報の参照を試み、前記セグメント情報が存在しない場合、判定不能として前記セグメントレジスタに値を設定するオブジェクトコードを生成するステップと、
前記リンカとして、前記コンパイラが生成したオブジェクトコードを基にメモリ配置を決定し、各変数のアドレスが確定した後、前記セグメント情報を生成するステップと、
前記コンパイラとして実施する２回目以降のコンパイルの際、前記セグメント情報を読み込み、前記コンパイラ内部で変数のセグメント番号を情報として保持するステップと、
前記コンパイラとして、データアクセスの際にｆａｒデータかどうかを判定し、ｆａｒデータの場合、前記セグメント情報の参照を試み、前記セグメント情報が存在する場合、前記セグメントレジスタの値と変数のセグメント番号とを比較し、前記セグメントレジスタの値と変数のセグメント番号とが同じであれば、前記セグメントレジスタを設定するオブジェクトコードを生成せず、前記セグメントレジスタの値と変数のセグメント番号とが同じでなければ、前記セグメントレジスタを設定するオブジェクトコードを生成するステップと
を更に計算機に実行させるための
言語処理用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソース入力手段、構文解析手段、オブジェクトコード生成手段を有する言語処理プログラムに関する。
【背景技術】
【０００２】
１６ビットのマイクロプロセッサは、通常、１６ビットで表現できる６４キロバイトのアドレス空間を持つ。近年の市場では、６４キロバイトを超えるメモリを必要とする場合が増えてきている。しかし、６４キロバイトを超えるアドレス空間を扱える２４ビットマイクロプロセッサや３２ビットマイクロプロセッサは価格が高く、安価な１６ビットマイクロプロセッサで６４キロバイトを超えるメモリをアクセスできるプロセッサが市場で求められている。
【０００３】
この市場のニーズ（要求）に答えて、１６ビットのマイクロプロセッサで６４キロバイトを超えるアドレス空間をアクセス可能とする手法として、セグメントアドレス方式のマイクロプロセッサが存在する。セグメントアドレス方式の１６ビットマイクロプロセッサは、１６ビットよりも上位のビットを含む上位アドレスを格納するセグメントレジスタを備えることにより、データのビット幅が１６ビットでありながら、６４キロバイトを超えるアドレス空間を扱うことができる。つまり、アドレス空間を６４キロバイトごとに区切り、番号を付けて管理するのがセグメントレジスタであると考えると良い。以降、アドレスを１６ビットで区切った上位アドレスを「セグメント番号」と呼ぶ。
【０００４】
セグメントアドレス方式では、６４キロバイトに収まらないデータにアクセスする場合、データのセグメント番号をセグメントレジスタに設定してからデータにアクセスすることになる。このため、オブジェクトコード生成において、オブジェクトコードのサイズが増大してしまうという問題がある。
【０００５】
関連する技術として、特許文献１（特開平０６−３３７７９１号公報）に、セグメントアドレス方式に関する説明がある。また、特許文献２（特開平０７−１２１３８０号公報）では、コードの削減手法として、不要なセグメントレジスタの設定コードを省略することが記載されている。しかし、セグメントレジスタの設定が省略可能かどうかの判断基準となるセグメントレジスタの設定値の取得方法については、記載されていない。
【０００６】
図１は、ユーザが記述したソースプログラムファイル１から最終的な出力であるロードモジュールファイル２を生成するコンパイル方式（言語処理方式）を示す。ロードモジュールファイルとは、関数や変数など全てのデータのメモリ配置が確定したオブジェクトコードを意味する。
【０００７】
＜従来方式の構成＞
図１で示す通り、従来のコンパイル方式は、コンパイラ（ｃｏｍｐｉｌｅｒ）１０と、リンカ（ｌｉｎｋｅｒ）２０を備える。
【０００８】
コンパイラ１０は、構文解析部１１と、コード生成部１３と、オブジェクト出力部１４を備える。
【０００９】
構文解析部１１は、ソースプログラムファイル１に記述されたプログラミング言語のソースコードを構文解析する。なお、一般的に、構文解析（ｐａｒｓｅｒ）の前に字句解析（ｌｅｘｅｒ）が行われる。字句解析については記載を省略する。例えば、構文解析部１１は、字句解析によってソースプログラムファイル１のプログラム中のトークン（命令語やリテラル）を切り出した後の段階において、そのトークンの属性と文法に記述された構文規則に基づいて、構文木を導出する。
【００１０】
コード生成部１３は、構文木からオブジェクトコードを生成する。
【００１１】
オブジェクト出力部１４は、コンパイラ１０からオブジェクトコードを出力し、リンカ２０に入力する。コンパイラ１０からリンカ２０に渡すデータは、メモリ配置が決定していないオブジェクトコードであるが、当該データの受け渡し方法については、外部ファイルを介した受け渡しでも、メモリ内での受け渡しでも良い。
【００１２】
リンカ２０は、オブジェクトコードに必要なライブラリ等を付け加えて実行可能ファイルを生成し、ロードモジュールファイル２として出力する機能を備える。ロードモジュールファイル２は、メインメモリにロードできる実行ファイル形式のモジュールである。
【００１３】
＜従来方式のデータアクセス処理＞
図２を参照して、図１のコード生成部１３内部の処理について説明する。
【００１４】
ここで、「データ」とは、ソースコード中の変数、並びにプロセッサ内での変数の領域を意味する。変数には、マイクロプロセッサのメモリ（ＲＯＭ、ＲＡＭ等）上に静的に配置されるものや、ソースコードにおける自動変数のように、ＲＡＭのスタック領域に必要に応じて自動的に確保されるものがある。「データアクセス」とは、変数に対してマイクロプロセッサがＲｅａｄ／Ｗｒｉｔｅ（読み込み／書き込み）することを意味する。
【００１５】
また、「ｆａｒデータ」とは、従来の６４キロバイトのアドレス空間に収まらないデータを意味する。また、従来の６４キロバイトのアドレス空間に収まるデータは「ｎｅａｒデータ」と呼んで区別する。個々のデータをｎｅａｒデータとするかｆａｒデータとするかは、ユーザが決める。なお、ｎｅａｒデータかｆａｒデータかを指定することで意味があるのは、一般的には静的に配置される変数である。
【００１６】
（１）ステップＳ１０１
コード生成部１３は、データアクセスの際に、アクセス対象のデータ（ソースプログラムファイル１の変数）がｆａｒデータかどうか確認する。ここでは、ｆａｒデータではない場合、ｎｅａｒデータであるものとする。従来方式において、変数がｆａｒデータかどうかの判定方法については、ソースコード中の変数に対して「＿ｎｅａｒ」や「＿ｆａｒ」という修飾子をつけることで、コンパイラ１０の構文解析部１１が判定する。修飾子を省略した変数をｎｅａｒデータとするかｆａｒデータとするかは、コンパイラ１０の最適化を指示することで、コンパイラ１０の構文解析部１１が、全てｎｅａｒデータとして処理するか、全てｆａｒデータとして処理する。なお、「＿ｎｅａｒ」や「＿ｆａｒ」という修飾子は、便宜上のものであり、実際には、この例に限定されない。
【００１７】
（２）ステップＳ１０２
コード生成部１３は、ｆａｒデータではない（ｎｅａｒデータである）場合、セグメントレジスタ設定コードは不要とする。例えば、コード生成部１３は、ｎｅａｒデータは従来の６４キロバイトのアドレス空間に収まるため、セグメントレジスタにセグメント番号を設定することなくデータにアクセスし、オブジェクトコードを生成する。
【００１８】
（３）ステップＳ１０３
コード生成部１３は、ｆａｒデータである場合、セグメントレジスタ設定コードを出力する。例えば、コード生成部１３は、ｆａｒデータは６４キロバイトのアドレス空間に収まらないため、セグメント番号として１６ビットよりも上位のビットを含む上位アドレスをセグメントレジスタに設定してからデータにアクセスし、オブジェクトコードを生成する。
【００１９】
図３は、ユーザが記述したソースプログラムファイルと、生成されたオブジェクトコード（コンパイラの出力）の例である。
【００２０】
図３では、ソースプログラムファイル（１０１）は、Ｃ言語で書かれている。「＿ｆａｒ」は、ｆａｒデータを意味する修飾子である。また、「＿ｎｅａｒ」は、ｎｅａｒデータを意味する修飾子である。
【００２１】
図３のオブジェクトコードについて、先頭が「；」から始まる文字列は、ユーザが記述したソースプログラムをコメントで表示したものであり、プロセッサの動作とは関係がない。「ｍｏｖ」は、データを転送する命令であり、カンマで区切られた右側に記述したものから左側に記述したものにデータを設定することを意味する。ＤＳは、セグメントレジスタを意味する。「＃」は、定数であることを意味し、「＃１」は、定数１であることを意味する。「ｈｉｇｈ＿ａｄｄｒ（ａ）」は、変数ａの上位アドレスを意味するが、この値は、コード生成時では、確定しておらず、リンカ（ｌｉｎｋｅｒ）で変数のメモリ配置が行われた時点で確定する。「！＿」は、変数の中身であることを意味する。「ＤＳ：」は、セグメントレジスタに設定された上位アドレスを付加して６４キロバイトを超えるアドレス空間をアクセスすることを意味する。
【００２２】
以上を踏まえてソースプログラムとオブジェクトコードを比較すると、ｆａｒデータである変数ａに１を設定する場合、最初に変数ａの上位アドレスをセグメントレジスタに設定してから、改めて変数ａに１を設定するコードを生成することになる。
【００２３】
このとき、コンパイラ（ｃｏｍｐｉｌｅｒ）は、ユーザが記述したソースプログラムを解析してオブジェクトコードを生成するが、最終的に「メモリのどこにデータを配置するか」を決定するのはリンカである。つまり、コンパイラがオブジェクトコードを生成する時点では、ｆａｒデータにアクセスする際にセグメント番号の値は分からない。
【００２４】
例えば、図３のソースプログラムでは、ｆａｒデータの変数ａをアクセスした後にｆａｒデータの変数ｂをアクセスしている。変数ａと変数ｂのセグメント番号が全く同じである場合、セグメントレジスタの値を再設定する必要はない。しかし、コンパイラがコードを生成する時点では、最終的に変数ａと変数ｂのセグメント番号が同じになるかどうかは判断できない。そのため、コンパイラは、毎回セグメントレジスタに値を設定するコードを生成する必要がある。
【００２５】
このセグメントレジスタへの設定コードを最小限に抑えることができれば、オブジェクトコードのサイズを削減することができると考えられる。
【先行技術文献】
【特許文献】
【００２６】
【特許文献１】特開平０６−３３７７９１号公報
【特許文献２】特開平０７−１２１３８０号公報
【発明の概要】
【発明が解決しようとする課題】
【００２７】
本発明の目的は、コンパイラが毎回セグメントレジスタに値を設定するために生成するコードのサイズを最小限に抑えることである。
【課題を解決するための手段】
【００２８】
本発明では、１回目のコンパイルで従来のコンパイラと同様にオブジェクトコードを生成する。この場合は、セグメントレジスタに値を設定するコードを生成する。このコードを受け取ったリンカが「変数がどのセグメント番号に割り当たるか」という情報（以降、この情報の集合体を「セグメント情報」と呼ぶ）を出力し、その情報を利用して再度コンパイルする。２回目以降のコンパイル時には、セグメント情報から変数のセグメント番号が分かっているので、セグメントレジスタの書き換えが必要かどうか分かる。セグメントレジスタの書き換えが不要だと判明する。
【００２９】
本発明の言語処理システムは、コンパイラと、リンカとを含む。コンパイラは、ソースプログラムファイルを読み込み、ソースプログラムファイルに基づいて、オブジェクトコードを生成する。リンカは、オブジェクトコードを読み込み、オブジェクトコードに基づいて、関数及び変数のメモリ配置が確定したロードモジュールファイルと、変数がどのセグメント番号に割り当たるかを示す情報の集合体であるセグメント情報とを生成する。更に、コンパイラは、セグメント情報を読み込むセグメント情報設定部と、セグメント情報が存在しない場合、セグメントレジスタに値を設定するオブジェクトコードを生成するコード生成部とを具備する。
【００３０】
本発明の言語処理方法では、コンパイラにより、ソースプログラムファイルを読み込み、ソースプログラムファイルに基づいて、オブジェクトコードを生成する。また、リンカにより、オブジェクトコードを読み込み、オブジェクトコードに基づいて、関数及び変数のメモリ配置が確定したロードモジュールファイルと、変数がどのセグメント番号に割り当たるかを示す情報の集合体であるセグメント情報とを生成することと、コンパイラにより、セグメント情報を読み込む。また、セグメント情報が存在しない場合、コンパイラにより、セグメントレジスタに値を設定するオブジェクトコードを生成する。
【００３１】
本発明の言語処理用プログラムは、コンパイラとして、ソースプログラムファイルを読み込み、ソースプログラムファイルに基づいて、オブジェクトコードを生成するステップと、リンカとして、オブジェクトコードを読み込み、オブジェクトコードに基づいて、関数及び変数のメモリ配置が確定したロードモジュールファイルと、変数がどのセグメント番号に割り当たるかを示す情報の集合体であるセグメント情報とを生成するステップと、コンパイラとして、セグメント情報を読み込むステップと、セグメント情報が存在しない場合、コンパイラとして、セグメントレジスタに値を設定するオブジェクトコードを生成するステップとを計算機に実行させるためのプログラムである。なお、本発明の言語処理用プログラムは、記憶装置や記憶媒体に格納することが可能である。
【発明の効果】
【００３２】
セグメントレジスタの設定コードを削減することで、オブジェクトコードのサイズを削減することができる。
【図面の簡単な説明】
【００３３】
【図１】従来のコンパイル方式の構成例を示すブロック図である。
【図２】従来のコンパイル方式のデータアクセス処理のフローチャートである。
【図３】従来のコンパイル方式における、データアクセス処理を行うＣ言語とアセンブラ出力である。
【図４】本発明の言語処理システムの構成例を示すブロック図である。
【図５】本発明の言語処理システムのデータアクセス処理のフローチャートである。
【図６】本発明の言語処理システムにおける、データアクセス処理を行うＣ言語とアセンブラ出力である。
【発明を実施するための形態】
【００３４】
＜基本構成＞
以下に、本発明の実施形態について添付図面を参照して説明する。
図４で示す通り、本発明の言語処理システムは、コンパイラ（ｃｏｍｐｉｌｅｒ）１０と、リンカ（ｌｉｎｋｅｒ）２０を備える。
【００３５】
コンパイラ１０は、構文解析部１１と、セグメント情報設定部１２と、コード生成部１３と、オブジェクト出力部１４を備える。
【００３６】
構文解析部１１は、ソースプログラムファイル１に記述されたプログラミング言語のソースコードを構文解析する。なお、一般的に、構文解析（ｐａｒｓｅｒ）の前に字句解析（ｌｅｘｅｒ）が行われる。字句解析については記載を省略する。例えば、構文解析部１１は、字句解析によってソースプログラムファイル１のプログラム中のトークン（命令語やリテラル）を切り出した後の段階において、そのトークンの属性と文法に記述された構文規則に基づいて、構文木を導出する。
【００３７】
セグメント情報設定部１２は、セグメント情報３を読み込む。セグメント情報３は、「変数がどのセグメント番号に割り当たるか」を示す情報の集合体である。セグメント情報３は、各変数のシンボル情報（変数名）と、ｎｅａｒデータかｆａｒデータか（ｎｅａｒ／ｆａｒ）を示す情報を持ち、更に、ｆａｒデータである場合は、セグメント番号を情報として保持する。ここでは、セグメント情報設定部１２は、リンカ２０からセグメント情報を受け取る。セグメント情報３の受け渡し方法については、外部ファイルを介した受け渡しでも、メモリ内での受け渡しでも良い。
【００３８】
コード生成部１３は、構文木からオブジェクトコードを生成する。
【００３９】
オブジェクト出力部１４は、コンパイラ１０からオブジェクトコードを出力し、リンカ２０に入力する。コンパイラ１０からリンカ２０に渡すデータは、メモリ配置が決定していないオブジェクトコードであるが、当該データの受け渡し方法については、外部ファイルを介した受け渡しでも、メモリ内での受け渡しでも良い。
【００４０】
リンカ２０は、ロードモジュールファイル２と、セグメント情報３を出力する機能を備える。ここでは、リンカ２０は、セグメント情報３をセグメント情報設定部１２に提供する。
【００４１】
本発明の言語処理システムの例として、ＰＣ（パソコン）、シンクライアント端末／サーバ、ワークステーション、メインフレーム、スーパーコンピュータ等の計算機を想定している。コンパイラ１０とリンカ２０は、同一の計算機上に限らず、それぞれ異なる計算機上に存在していても良い。但し、実際には、これらの例に限定されない。
【００４２】
構文解析部１１、セグメント情報設定部１２、コード生成部１３、及びオブジェクト出力部１４は、プログラムで駆動される処理装置等のハードウェアと、そのハードウェアを駆動して所望の処理を実行させるプログラム等のソフトウェアと、そのソフトウェアや各種データを格納する記憶装置によって実現される。処理装置の例として、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、マイクロプロセッサ（ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ）、マイクロコントローラ、或いは、同様の機能を有する半導体集積回路（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ（ＩＣ））等が考えられる。記憶装置の例として、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  ａｎｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）や、フラッシュメモリ等の半導体記憶装置、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等の補助記憶装置、又は、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）やメモリカード等の記憶媒体（メディア）が考えられる。また、オブジェクト出力部１４は、ネットワークを介して通信する必要がある場合、ネットワークインタフェースを含むものとする。ネットワークインタフェースの例として、ＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）等のネットワークアダプタや、アンテナ等の通信装置、接続口（コネクタ）等の通信ポート等が考えられる。また、ネットワークの例として、インターネット、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、無線ＬＡＮ（Ｗｉｒｅｌｅｓｓ  ＬＡＮ）、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、バックボーン（Ｂａｃｋｂｏｎｅ）、ケーブルテレビ（ＣＡＴＶ）回線、固定電話網、携帯電話網、ＷｉＭＡＸ（ＩＥＥＥ  ８０２．１６ａ）、３Ｇ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ）、専用線（ｌｅａｓｅ  ｌｉｎｅ）、ＩｒＤＡ（Ｉｎｆｒａｒｅｄ  Ｄａｔａ  Ａｓｓｏｃｉａｔｉｏｎ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、シリアル通信回線、データバス等が考えられる。但し、実際には、これらの例に限定されない。
【００４３】
＜データアクセス処理＞
図５を参照して、図４のコード生成部１３内部の処理について説明する。
【００４４】
（１）ステップＳ２０１
コード生成部１３は、データアクセスの際に、アクセス対象のデータ（ソースプログラムファイル１の変数）がｆａｒデータかどうか確認する。ここでは、ｆａｒデータではない場合、ｎｅａｒデータであるものとする。本発明において、変数がｆａｒデータかどうかの判定方法については、図４のセグメント情報３を基に、セグメント情報設定部１２が判定する。この場合、ソースコード中の「＿ｎｅａｒ」や「＿ｆａｒ」という修飾子による変数の領域配置指定と、セグメント情報３とが競合することになる。セグメント情報設定部１２は、セグメント情報３を優先しても良いし、「＿ｎｅａｒ」や「＿ｆａｒ」という修飾子を優先しても良い。セグメント情報３を優先すると、コードサイズが削減される。「＿ｎｅａｒ」や「＿ｆａｒ」という修飾子を優先すると、ユーザの意図が反映される。
【００４５】
（２）ステップＳ２０２
コード生成部１３は、ｆａｒデータではない（ｎｅａｒデータである）場合、セグメントレジスタ設定コードは不要とする。例えば、コード生成部１３は、セグメントレジスタにセグメント番号を設定することなくデータにアクセスし、オブジェクトコードを生成する。
【００４６】
（３）ステップＳ２０３
コード生成部１３は、ｆａｒデータである場合、セグメントレジスタの値と変数のセグメント番号を比較する。
【００４７】
（４）ステップＳ２０４
コード生成部１３は、セグメントレジスタの値が変更されたか否か判定する。
【００４８】
（５）ステップＳ２０５
コード生成部１３は、セグメントレジスタの値が変更された場合、もしくは判定不能の場合、セグメントレジスタ設定コードを出力する。例えば、コード生成部１３は、セグメント番号をセグメントレジスタに設定してからデータにアクセスし、オブジェクトコードを生成する。
【００４９】
（６）ステップＳ２０６
コード生成部１３は、セグメントレジスタの値が変更されていない場合、セグメントレジスタ設定コードは不要とする。例えば、コード生成部１３は、セグメントレジスタにセグメント番号を設定することなくデータにアクセスし、オブジェクトコードを生成する。
【００５０】
図６は、図３と同じソースプログラムを、本発明の言語処理システムに入力して得られたオブジェクトコードである。
【００５１】
＜全体動作＞
［１回目のコンパイル］
コンパイラ１０は、１回目のコンパイルでは、従来と同様に、オブジェクトコードを生成する。このとき、セグメント情報３はまだ作られていないため、セグメント情報設定部１２は何も行わない。コード生成部１３は、データアクセスの際にｆａｒデータかどうかを判定し、ｆａｒデータの場合は、直前のセグメントと変数のセグメントを比較するが、セグメント情報が設定されていないため、判定不能としてセグメントレジスタに値を設定する（ための）オブジェクトコードを生成する。ここでは、コード生成部１３は、ｆａｒデータの場合は、セグメント情報の参照を試みることでセグメント情報の有無を確認し、セグメント情報が存在していれば、直前のセグメントと変数のセグメントを比較し、セグメント情報が存在していなければ、判定不能としてセグメントレジスタに値を設定するオブジェクトコードを生成する。但し、実際には、この例に限定されない。
【００５２】
［セグメント情報出力］
リンカ２０は、コンパイラ１０が生成したオブジェクトコードを基にメモリ配置を決定する。この際、各変数のアドレスが確定するので、リンカ２０は、セグメント情報３を出力する。
【００５３】
［２回目以降のコンパイル］
コンパイラ１０は、セグメント情報３を利用して、２回目以降のコンパイルを行う。セグメント情報設定部１２は、セグメント情報を読み込み、コンパイラ１０内部で変数のセグメント番号を情報として持つ。コード生成部１３は、ｆａｒデータにアクセスするコードを生成する際、セグメントレジスタの値と変数のセグメント番号を比較する。ここでは、１回目のコンパイルの際と同様に、コード生成部１３は、ｆａｒデータかどうかを判定し、ｆａｒデータの場合は、セグメント情報の参照を試みることでセグメント情報の有無を確認し、セグメント情報が存在していれば、直前のセグメントと変数のセグメントを比較する。コード生成部１３は、比較した両者（セグメントレジスタの値と変数のセグメント番号）が同じであれば、セグメントレジスタを設定するオブジェクトコードを生成しない。図６では、セグメント情報３において変数ａ，ｂ，ｃのセグメント番号が同じであったために、コード生成部１３は、変数ｂと変数ｃをアクセスする際に、セグメントレジスタに値を設定するオブジェクトコードを出力していない。
【００５４】
なお、ここでは、同一の計算機上で１回目のコンパイルと２回目以降のコンパイルを実施する事例を想定して説明しているが、実際には、この例に限定されない。例えば、同じソースプログラムファイルを複数の計算機上でコンパイルする場合について、最初の１台目でのコンパイルを、１回目のコンパイルとみなし、このときにリンカが生成したセグメント情報を複数の計算機で共有するようにすれば、他の計算機でのコンパイルを、２回目以降のコンパイルとみなすことができる。複数の計算機上で複数回コンパイルする場合についても、最初の１台目での１回目のコンパイル以外は、全て２回目以降のコンパイルとみなすことができる。
【００５５】
ｆａｒデータにアクセスする際に、セグメントレジスタの値とこれからセグメントレジスタに設定しようとするセグメント番号が同じであるなら、セグメントレジスタを設定するコードを生成する必要はない。しかし、従来の技術では、コンパイル時に変数のメモリ配置が確定しないため、「セグメントレジスタの値とこれからセグメントレジスタに設定しようとするセグメント番号が同じであるかどうか」が判断できない。そのため、セグメントレジスタの設定コードが不要な場合でも、設定コードを出力していた。
【００５６】
本発明では、リンカが生成するセグメント情報を利用して再度コンパイルすることで、変数のセグメント番号が分かるため、必要のないセグメントレジスタ設定コードを削減できる。
【００５７】
具体的には、１回目のコンパイルで従来のコンパイラと同様にオブジェクトコードを生成する。この場合は、セグメントレジスタに値を設定するコードを生成する。このコードを受け取ったリンカが「変数がどのセグメント番号に割り当たるか」という情報を出力し、その情報を利用して再度コンパイルする。この情報の集合体を「セグメント情報」と呼ぶ。２回目以降のコンパイル時には、セグメント情報から変数のセグメント番号が分かっているので、セグメントレジスタの書き換えが必要かどうか分かる。セグメントレジスタの書き換えが不要だと分かればセグメントレジスタの設定コードを削減することができる。
【００５８】
以上、本発明の実施形態を詳述してきたが、実際には、上記の実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の変更があっても本発明に含まれる。
【符号の説明】
【００５９】
１…  ソースプログラムファイル
２…  ロードモジュールファイル
３…  セグメント情報
１０…  コンパイラ（ｃｏｍｐｉｌｅｒ）
１１…  構文解析部
１２…  セグメント情報設定部
１３…  コード生成部
１４…  オブジェクト出力部
２０…  リンカ（ｌｉｎｋｅｒ）
【図１】
2011123719.tif 000003
【図２】
2011123719.tif 000004
【図３】
2011123719.tif 000005
【図４】
2011123719.tif 000006
【図５】
2011123719.tif 000007
【図６】
2011123719.tif 000008