JP7295469B2 - 関数生成プログラム、関数生成方法、及び情報処理装置 - Google Patents

Description

本発明は、関数生成プログラム、関数生成方法、及び情報処理装置に関する。

プログラムの実行速度を高速化する技術の一つとしてJIT(Just In Time)コンパイラ技術がある。JITコンパイラ技術とは、実行時に決定されるパラメータ、処理内容、及びプロセッサの状況に応じて、好適な機械語の命令列を生成する技術を言う。JITコンパイラ技術を用いて生成した機械語の命令列は、AOT(Ahead Of Time)型のコンパイラが生成する汎用的に処理可能な機械語の命令列からなる実行ファイルよりも処理が高速である。

但し、JITコンパイラ技術を使うためには、命令セットに含まれる命令ごとに、その命令を実行する機械語を生成する関数を開発者が自ら手作業でソースコードに記述する必要がある。よって、これらの関数を生成し、かつ各関数が正しい機械語を生成するかをテストする工数が膨大となる。

特開２０００－５６９８１号公報

一側面によれば、関数の作成に伴う工数を減らすことが可能な関数生成プログラム、関数生成方法、及び情報処理装置を提供することを目的とする。

一側面によれば、命令に関する命令情報を記憶した記憶部を参照して、前記命令に対応した関数であって、前記命令のオペランドを表す引数を受け取る第１の関数を生成する処理と、前記引数が表す前記オペランドに対して前記命令が行う処理を表す機械語を返す第２の関数を呼び出すコードを前記第１の関数の内部に生成する処理と、前記機械語をメモリに書き込むコードを前記第１の関数の内部に生成する処理と、をコンピュータに実行させるための関数生成プログラムが提供される。

一側面によれば、関数の作成に伴う工数を減らすことが可能となる。

図１は、実行可能プログラムを実行するターゲットマシンのハードウェア構成図である。 図２（ａ）は、AOT(Ahead Of Time)コンパイラ技術でコンパイルすることを前提としたC++の疑似ソースコードの一例を示す図であり、図２（ｂ）は、パラメータqと配列in、outを宣言したC++のソースコードの一例を示す図であり、図２（ｃ）は、配列Tblの初期値を宣言したC++の疑似ソースコードの一例を示す図である。 図３は、AOTコンパイラ技術で得られたアセンブリの疑似コードの模式図である。 図４は、AOTコンパイラ技術で得られた実行可能プログラムの動作について模式的に示す図である。 図５は、JITコンパイラ技術を使用する実行可能プログラムのC++の疑似ソースコードの一例を示す図である。 図６は、入力パラメータqが「8」の場合の、JITコンパイラ技術で生成した機械語の命令列と、それを逆アセンブルした疑似コードの模式図である。 図７は、実行時に呼び出す関数を、JITコンパイラ技術で実行時に生成する実行可能プログラムの動作について示す模式図である。 図８は、mov命令に対応したニーモニック関数の疑似ソースコードの例を示す図である。 図９は、第１実施形態に係る情報処理装置の動作を示す模式図である。 図１０は、MachineCodeEmitter関数のC++の疑似ソースコードが記述されたソースファイルの一例を示す図である。 図１１は、第１実施形態に係る情報処理装置の機能構成図である。 図１２は、第１実施形態に係る関数生成方法について示すフローチャートである。 図１３は、第１実施形態において、ニーモニック関数が記述されたソースファイルを利用した開発環境について示す模式図である。 図１４は、C++のマクロを使用しないで生成した実行可能プログラムを実行するときのメモリの内容を示す模式図である。 図１５（ａ）は、第１実施形態に係る第１の生成部がC++のマクロとしてニーモニック関数movを記述したソースコードの一例を示す図であり、図１５（ｂ）は、マクロを使用した場合において、実行可能プログラムを実行するときのメモリの内容を示す模式図である。 図１６は、ニーモニックが同一で機械語が相違する命令について示す図である。 図１７（ａ）は、ニーモニック「STRpost」、「STRpre」を採用した場合の第１実施形態の命令情報を模式的に示す図であり、図１７（ｂ）は、この命令情報に基づいて第１実施形態に従って生成したニーモニック関数について示す図である。 図１８は、第２実施形態で使用する命令情報について模式的に示す図である。 図１９（ａ）～（ｅ）は、第２実施形態においてオペランドの型を定義するC++の疑似ソースコードの例について示す図である。 図２０（ａ）は、ニーモニック「STRpost」に対応した第２実施形態に係るニーモニック関数STRのC++の疑似ソースコードが記述されたソースファイルの模式図であり、図２０（ｂ）は、ニーモニック「STRpre」に対応した第２実施形態に係るニーモニック関数STRのC++の疑似ソースコードが記述されたソースファイルの模式図である。 図２１（ａ）は、ニーモニック関数の引数をOperand型とした場合のニーモニック関数movのC++の疑似ソースコードを示す図であり、図２１（ｂ）は、このニーモニック関数movを利用して開発者が記述したアプリケーションプログラム用のソースファイル４１のC++の疑似ソースコードを示す図である。 図２２（ａ）は、第２実施形態で生成したニーモニック関数movのC++の疑似ソースコードが記述されたソースファイルの模式図であり、図２２（ｂ）は、このニーモニック関数movを利用して開発者が記述したアプリケーションプログラム用のソースファイルのC++の疑似ソースコードの例を示す図である。 図２３は、第２実施形態に係る関数生成方法について示すフローチャートである。 図２４（ａ）は、第２実施形態に従って生成したニーモニック関数movのC++のソースコードが記述されたソースファイルの例を示す図であり、図２４（ｂ）は、このニーモニック関数movを利用して開発者が記述したアプリケーションプログラム用のソースファイルのC++の疑似ソースコードの例を示す図である。 図２５は、第３実施形態で使用する命令情報について模式的に示す図である。 図２６は、mov命令に対応した第３実施形態に係るニーモニック関数movが記述されたソースファイル３４のC++の疑似ソースコードの例について示す模式図である。 図２７は、第３実施形態に係るニーモニック関数movを利用して開発者が記述したアプリケーションプログラム用のソースファイルのC++の疑似ソースコードの例を示す図である。 図２８は、第３実施形態に係る関数生成方法について示すフローチャートである。 図２９（ａ）、（ｂ）は、第４実施形態において、add命令の文法について示す図である。 図３０は、第４実施形態に係る命令情報を模式的に示す図である。 図３１は、第４実施形態に従って制御部が生成したニーモニック関数ADDのソースコードの一例を示す図である。 図３２は、関数「SET()」を定義するC++の疑似ソースコードを模式的に示す図である。 図３３は、第４実施形態において開発者がC++で記述したアプリケーションプログラム用のソースファイルの疑似ソースコードを模式的に示す図である。 図３４は、出力例を示す図である。 図３５は、第４実施形態に係る情報処理装置の機能構成図である。 図３６は、第４実施形態において制御部が生成したニーモニック関数ADDのC++の疑似ソースコードを示す模式図である。 図３７は、第４実施形態において第４の生成部が生成する関数「SET()」のC++の疑似ソースコードの一例を示す図である。 図３８は、第４実施形態において定義ファイル生成部が生成した定義ファイルの疑似ソースコードを示す模式図である。 図３９は、第４実施形態において開発者が記述したアプリケーションプログラム用のソースファイルのC++の疑似コードを示す図である。 図４０は、第４実施形態に係る開発環境について示す模式図である。 図４１は、第４実施形態における出力例を示す図である。 図４２は、第４実施形態の別の例に係るソースファイルのC++の疑似ソースコードの例を示す模式図である。 図４３（ａ）、（ｂ）は、マクロで置換される関数の最後に可変引数マクロを記述したときに生じる不都合について模式的に示す図である。 図４４は、第４実施形態に係る定義ファイルの生成方法について示すフローチャートである。 図４５は、第１～第４実施形態に係る情報処理装置のハードウェア構成図である。

本実施形態の説明に先立ち、本願発明者が検討した事項について説明する。

前述のようにJITコンパイラ技術はプログラムの実行速度の高速化に有用である。このようなJITコンパイラ技術の利点について、AOT(Ahead Of Time)コンパイラ技術と比較しながら説明する。なお、このJITコンパイラ技術は、プロセッサに依存しない中間言語のコードをプロセッサが直接扱える機械語の命令列に実行時に変換する技術ではなく、実行時に決定されるパラメータ等に適した機械語の命令列を生成するコンパイラ技術である。

図１は、AOTコンパイラ技術やJITコンパイラ技術により生成された実行可能プログラムを実行するターゲットマシンのハードウェア構成図である。

このターゲットマシン１は、サーバやPC(Personal Computer)等の計算機であって、プロセッサ２とメモリ３とを有する。

このうち、プロセッサ２は、算術演算や論理演算を行うALU(Arithmetic and Logic Unit)等の計算コア４とレジスタファイル５とを備える。レジスタファイル５は、インデックスn(=0,1,2,…)で識別される複数の汎用のレジスタRnを備えたハードウェアである。

一方、メモリ３は、実行可能プログラムが展開されるDRAM(Dynamic Random Access Memory)等の揮発性メモリである。その実行可能プログラムは、以下のようにAOTコンパイラ技術を用いてソースコードをコンパイルすることにより生成することができる。また、JITコンパイラ技術で実行可能プログラムが呼び出す機械語の命令列を実行中に動的に生成してもよい。

図２（ａ）は、AOTコンパイラ技術でコンパイルすることを前提としたC++の疑似ソースコード１０の一例を示す図である。

AOTコンパイラ技術では、開発者はC言語やC++の文法に即してソースコードを記述し、そのソースコードをGCC(GNU Compiler Collection)等のコンパイラが機械語の命令列にコンパイルする。

図２（ａ）の例では、処理１０ａにおいて配列「Tbl」の各要素をパラメータ「q」で除する。そして、処理１０ｂにおいて、配列「in」の要素を配列「Tbl」の要素で除し、それを配列「out」に格納する。

図２（ｂ）は、パラメータ「q」と配列「in」、「out」を宣言したC++の疑似ソースコード１１の一例を示す図である。

パラメータ「q」は、前述の処理１０ａにおける除数であり、以下では入力パラメータとも呼ぶ。また、配列「in」と配列「out」は、それぞれ処理１０ｂにおける入力データと出力データである。これらの配列「in」、「out」に格納するデータは特に限定されない。ここでは１６個の画素データからなる画像を１００００００枚格納する二次元配列として配列「in」と配列「out」を宣言する。

図２（ｃ）は、配列Tblの初期値を宣言したC++の疑似ソースコード１２の一例を示す図である。

配列「Tbl」は、画素データを量子化する量子化テーブルの値を格納する配列である。ここでは、各配列「in」、「out」に対応した１６個の要素を持つ配列として配列「Tbl」を宣言する。そして、配列「Tbl」の各要素の初期値は２のべき乗であると仮定する。

図２（ａ）～図２（ｃ）のソースコード１０～１２は全てC言語やC++の文法に即して開発者が記述し、コンパイラによってアセンブリに変換される。

図３は、AOTコンパイラ技術で前述のソースコード１０をコンパイルして得られたアセンブリ１４の疑似コードの模式図である。

そのアセンブリ１４には、プロセッサ２の命令セットに含まれる複数の命令が、各処理１０ａ、１０ｂに対応して生成されている。

例えば、処理１０ａはmov命令からjmplt命令に至る６個の命令で実現され、処理１０ｂはmov命令からjmplt命令に至る１０個の命令で実現される。これらの命令は、プロセッサ２の命令セットに含まれる命令であって、オペランドとして記述されたレジスタやメモリに対して種々の操作を行う。なお、ここでは図１と同様にレジスタをRn(n=0,1,2,…)で表し、命令の位置を表すラベルをLm(m=0,1,2,…)で表す。そして、最初にレジスタR2に入力パラメータ「q」が保存されているものとする。

また、命令セットに含まれる全ての命令は、ニーモニックと呼ばれる名前で一意に識別される。例えば、mov命令のニーモニックは「mov」であり、store命令のニーモニックは「store」である。

アセンブリ１４においては、命令のニーモニックの後ろにオペランドを記述するという文法が採用される。例えば、「mov R0, #0」は、即値である「0」をレジスタR0に格納する命令である。また、「load R1, [Tbl[R0]]」は、メモリ３上に値が保持されている配列「Tbl」のa番目の要素（ａはレジスタＲ０の内容）の値をレジスタR1にロードする命令である。

一方、「store [Tbl[R0]], R1」は、レジスタR1の内容を、メモリ３上に値が保持されている配列「Tbl」のｂ番目の要素（ｂはレジスタＲ０の内容）に格納する命令である。また、「div R1, R1, R2」は、レジスタR1の内容をレジスタR2の内容で除し、その値をレジスタR1に格納する命令である。そして、「jmplt R0, #16, L0」は、レジスタR0の内容が即値の「16」未満の場合にラベルL0にジャンプする命令である。

ここで、処理１０ｂにおける命令「div R2, R2, R1」について考える。この命令は、ソースコード１０の処理１０ｂにおける「in[i]/Tbl[i]」に相当する命令である。除数の「Tbl[i]」は、ソースコード１０の処理１０ａにおいて入力パラメータ「q」で除されている。上記の命令「div R2, R2, R1」は入力パラメータ「q」の値の如何を問わずに正しい除算の結果を与える命令である。したがって、アセンブリ１４は、どのような入力パラメータ「q」に対しても正しい結果を与える汎用的なコードとなっている。

しかしながら、div命令のような除算を行う命令は、どのような種類のプロセッサであっても、他の命令と比較して実行サイクル数が多い命令である。したがって、実行開始してからその結果が得られるまでのスループットが大きく、処理性能の低下を招いてしまう命令である。プロセッサ２の種類にもよるが、div命令以外の数値演算命令の実行サイクル数は１～５であるのに対し、div命令の実行サイクル数は８０程度もあることがある。更に、深層学習や画像処理等ではforループのループの回数が膨大となるため、そのforループの内側にあるdiv命令によってスループットの低下が更に顕著となる。

このようなアセンブリ１４をアセンブラが機械語の命令列に翻訳することにより機械語からなる実行可能プログラムが生成されることになる。LLVMのようにコンパイラの種類によっては、プロセッサ２の種類によらず、仮想的な命令セットを持つプロセッサ向けのアセンブリを生成することがある。この場合、このアセンブリを個別のプロセッサ向けの機械語の命令列に変換することもあるが、div命令のような除算命令があるとスループットが低下する点は同じである。

図４は、AOTコンパイラ技術で得られた実行可能プログラムの動作について模式的に示す図である。

図４に示すように、実行可能プログラム１５は、入力データである配列「in」の各要素と入力パラメータ「q」の入力を受け付ける。そして、前述のように入力パラメータ「q」や配列「in」の値の如何を問わずに、実行可能プログラムは同一のアセンブリ１４から得られた機械語の命令列により処理を行い、その処理の結果を配列「out」の各要素に格納する。

次に、スループットの低下を抑制し得るJITコンパイラ技術を前提としたプログラムについて説明する。

図５は、JITコンパイラ技術を使用する実行可能プログラムのC++の疑似ソースコード１６の一例を示す図である。

このソースコード１６は、その実行結果が図２（ａ）のソースコード１０の実行結果と同一になるように開発者によって記述されたコードであって、処理１６ａと処理１６ｂとを有する。このうち、処理１６ａは、ソースコード１０の処理１０ａと同様に、配列「Tbl」の各要素をパラメータ「q」で除する処理である。また、処理１６ｂは、ソースコード１０の処理１０ｂと同様に、配列「in」の要素を配列「Tbl」の要素で除してそれを配列「out」に格納する処理である。

その処理１６ｂには、関数名がニーモニックと同一の「mov(R0, i)」等の関数が開発者によって記述される。関数「mov(R0, i)」は、言わばアセンブリ「mov R0, #i」に対応した関数であって、「mov R0, #i」が行う処理を表す機械語をメモリ３に書き込む関数である。なお、アセンブリ中では変数は記述することができず、「mov R0, #5」や「mov R0, #-128」など、アセンブリの時点では固定の値しか指定することができない。JITコンパイラ技術を用いた場合、即値に変数ｉが使用できる。このことはJITコンパイラ技術の利点の1つである。このように関数名が命令のニーモニックと同一であり、かつその命令が行う処理を表す機械語をメモリ３に書き込む関数のことを以下ではニーモニック関数と呼ぶ。

処理１６ｂは、i=0～15に対してin[i]/Tbl[i]を実行する機械語の命令列をメモリ３に書き込む処理を実行する記述である。この例では開発者がswitch文を記述したことにより、除数である配列要素「Tbl[i]」の値に応じて異なるニーモニック関数を使って機械語の命令列が生成される。

例えば、「Tbl[i]」の値が「1」の場合には、「in[i]」に対する除数が「１」となるため、「in[i]」に対して何も行う必要がない。よって、この場合は、「case 1」において「in[i]」の値が格納されているレジスタR1の値に対して演算する機械語の生成は行わず、そのままout[i]へ値を格納する機械語をメモリ３に書き込むのみである。

一方、「Tbl[i]」の値が「2」の場合には、「case 2」においてshiftR命令の機械語の生成に対応した「shiftR(R1, R1, #1)」を実行する。このニーモニック関数は、レジスタR1の内容を１ビットだけ右にシフトし、その結果をレジスタR1に書き込む処理を表す機械語をメモリ３に書き込む関数である。よって、「shiftR(R1, R1, #1)」を実行することにより、レジスタR1に格納されている「in[i]」を２で除したのと等価な処理を行う機械語をメモリ３に書き込むことができる。

また、「Tbl[i]」の値が「4」の場合には、「case 4」において「shiftR(R1, R1, #2)」を実行する。これにより、レジスタR1の内容が右に２ビットだけシフトし、レジスタR1に格納されている「in[i]」を４で除したのと等価な処理を行う機械語をメモリ３に書き込むことができる。このように、除数が2のべき乗の値の場合には、shiftR命令に対応するニーモニック関数が実行される。

そして、「Tbl[i]」の値が「1」、「2」、「4」のような2のべき乗ではない場合には、「default」において「div(R1, R1, R2)」を実行する。このニーモニック関数は、div命令に対応した関数であって、レジスタR1の内容をレジスタR2の内容で除した値をレジスタR1に書き込む機械語をメモリ３に書き込む関数である。

このようなソースコード１６によれば、「Tbl[i]」の値が「1」、「2」、「4」のような2のべき乗である場合には、div命令よりも実行サイクル数が少ないshiftR命令に等価な機械語や何もしない機械語がメモリ３に書き込まれる。そして、「Tbl[i]」の値が「1」、「2」、「4」のような2のべき乗でない場合にのみdiv命令に等価な機械語がメモリ３に書き込まれる。

JITコンパイラ技術では、このように「Tbl[i]」等のパラメータの値に応じて実行サイクル数を低減するのに最適な機械語を書き込むことにより、AOTコンパイラ技術と比較してプログラムの実行速度を高速化することができる。

図６は、ソースコード１６をコンパイルして得られた実行ファイルの実行中に、処理１６ｂがメモリにどのような機械語の命令列を書き込んだかを示す模式図である。なお、その実行ファイルを実行する際、入力パラメータqに「8」を与えている。また、図６では、この機械語の命令列を逆アセンブルしたアセンブリ１７の疑似コードも併記している。

図６に示すように、q=8の場合には、配列「Tbl」の各要素が先頭から順に「1」、「2」、「4」となる。よって、処理１６ｂのforループ実行に際して、i=0(case 1)、i=1(case 2)、i=2(case 4)の各場合に対応したshiftR関数とstore関数の各々が生成する機械語１８がメモリ３内に配置されることになる。そして、その機械語１８を逆アセンブルしたコードは、アセンブリ１７におけるコード１７ａ、１７ｂ、１７ｃとなる。

図７は、実行時に呼び出す関数を、JITコンパイラ技術で実行時に生成する実行可能プログラムの動作について示す模式図である。ここでは、JITコンパイラ技術を用いたソースコード１６をコンパイルして得られた実行可能プログラム２０の動作について説明する。

図７に示すように、実行可能プログラム２０は、まず入力パラメータ「q」の入力を受け付ける（ステップP10）。次いで、実行可能プログラム２０は、その入力パラメータ「q」の値に応じて、処理が高速になる機械語１８を生成する（ステップP11）。前述の図６の例では、「Tbl[i]」の値に適した機械語１８が生成される。

続いて、実行可能プログラム２０は、入力データである配列「in」の各要素の入力を受け付けて（ステップP12）、処理の結果を配列「out」の各要素に格納する（ステップP13）。

このとき、機械語１８の中にはスループットの遅いdiv命令が含まれていないため、アセンブリ１４に対応する実行可能プログラムよりも高速な処理を行うことができる。しかも、このように入力パラメータ「p」の値に応じて適切な機械語１８を生成することにより、JITコンパイラ技術ではAOTコンパイラ技術よりもプログラムの実行速度を高速化できる。

ところで、このようなJITコンパイラ技術で使用するニーモニック関数はC++やC言語等のライブラリには存在しない関数であるため、開発者が予め手作業でニーモニック関数を記述しておく必要がある。

図８は、mov命令に対応したニーモニック関数のC++の疑似ソースコードの一例を示す図である。

このソースコード２１は、ニーモニック関数movを定義するためのソースコードである。そのニーモニック関数movの関数名は、mov命令のニーモニック「mov」と同じであり、かつ引数はmov命令がとる「オペランド0」と「オペランド1」の二個である。

ニーモニック関数movの内部には、mov命令の処理を表す機械語をメモリ３に書き込むコードが記述される。ここでは、命令長は３２ビットであり、mov命令のオペコードは８ビットで「0x01」であるとする。この場合、開発者は、変数「mnemonic」にオペコードの「0x01」を代入する文「unsigned mnemonic = 0x01;」をニーモニック関数movの本体に記述する。同様に、開発者は、変数「op0」、「op1」の各々に「オペランド0」、「オペランド1」を代入する文「unsigned op0 = オペランド0;」、「unsigned op1 = オペランド1;」をニーモニック関数movの本体に記述する。

そして、これらの文の後に、開発者は、「write((mnemonic<<24)+(op0<<16)+(op1<<8));」という文を記述する。関数writeは、引数のビット列をメモリ３に書き込む関数である。この例では、「mnemonic」の値を左に２４ビットだけシフトしたビット列と、変数「op0」の値を左に１６ビットだけシフトした値と、変数「op1」の値を左に８ビットだけシフトした値とのビット和が関数writeの引数となる。このビット列においては、先頭の８ビットがmov命令のオペコードとなる。そして、そのオペコードの次の８ビットが変数「op0」のビット列であり、その次の８ビットが変数「op1」のビット列である。なお、アセンブリ１７のshiftR R1, R1, #1等のようにオペランドを３つとる命令に対応するニーモニック関数では、最後の８ビットが３番目の変数「op2」のビット列である。

このようなニーモニック関数を記述するには、開発者は、命令セットの仕様書を参照して各命令のフォーマットを特定し、そのフォーマットに従って関数writeの引数にオペコードとオペランドの各々のビット列を記述する必要がある。

しかしながら、このように手作業でニーモニック関数を記述するのは極めて煩雑な作業であり、開発者の負担増を招いてしまう。また、ニーモニック関数が所望の機械語を正しくメモリ３に書き込む動作するかの検証作業も手作業で行う必要があるため開発者の負担が更に増してしまう。特に、命令セットに含まれる命令の個数が数百個から千個を超えるプロセッサ２もある。例えば、ARM社が仕様を策定しているARMv8-A architecture profileに従うプロセッサでは、オペランドのバリエーションが異なる同一名称の命令を異なる命令として扱うと、約１０００種類もの命令がある。この場合には約１０００種類ものニーモニック関数を開発者が自ら記述しなければならず、全ての命令に対応したニーモニック関数の記述と検証とを手作業で行うために膨大な工数が必要となる。

更に、命令セットは将来的に拡張されることがあり、その度にニーモニック関数の記述と検証をするのは煩わしさに耐えない。

以下に、ニーモニック関数を作成するための工数を減らすことが可能な各実施形態について説明する。

（第１実施形態）
本実施形態では、以下のようにして情報処理装置がニーモニック関数を自動的に生成する。

［全体構成］
図９は、本実施形態に係る情報処理装置の動作を示す模式図である。
この情報処理装置３０は、ニーモニック関数を自動的に生成するツールである制御部３１を備えたPCやサーバ等の計算機である。ニーモニック関数を生成するに際し、制御部３１は、関数を生成するための命令情報３３を参照する。

命令情報３３は、各命令のニーモニックとオペランドの個数とを対応付けた情報であって、開発者によって予め作成される。命令情報３３の各々の行はそれぞれ異なる命令に対応しており、例えば１行目はmov命令に対応し、２行目はload命令に対応する。

この例では、開発者が、一行目のmov命令のニーモニック「mov」を、mov命令のオペランドの個数「2」と対応付けて命令情報３３に格納する。なお、オペランドの個数は命令によって異なり、例えばshiftR命令ではオペランドの個数は「3」となる。

その命令情報３３は、情報処理装置３０内の記憶部にファイルとして格納される。なお、ネットワークを介して情報処理装置３０と接続された外部の記憶部に開発者が命令情報３３を格納し、その記憶部を制御部３１が参照してもよい。

制御部３１は、命令情報３３を一行ずつ読み込んで、その行にあるニーモニックに対応した関数名を有するニーモニック関数を生成する。その生成方法について一行目のニーモニック「mov」を例にして説明する。

まず、制御部３１は、命令情報３３の一行目を読み込むことにより、ニーモニック「mov」とこれに対応したオペランドの個数「2」とを取得する。

次いで、制御部３１は、ニーモニック「mov」に対応した関数名のニーモニック関数をC++のソースファイル３４に記述する。本実施形態ではニーモニックと関数名とを同名にする。そのため、制御部３１は、関数名３４ａが「mov」のニーモニック関数をソースファイル３４に記述することになる。なお、ソースファイル３４に記述するプログラミング言語はC++に限定されず、制御部３１がC言語やC#のソースコードをソースファイル３４に記述してもよい。

また、そのニーモニック関数movは、命令情報３３における個数「2」と同数の引数をとる。これにより、ニーモニック関数movのひな形である「void mov(Operand OP0,Operand OP1){}」という中身が空の関数が記述されることになる。なお、ニーモニック関数movは第１の関数の一例である。

また、「OP0」と「OP1」の各々は、mov命令のオペランドを表す引数である。ここでは、制御部３１がソースファイル３４にソースコード３４ｂを記述することにより、オペランドを表す変数の型としてOperand型を定義する。そして、制御部３１は、コードT1において「OP0」と「OP1」の各々をOperand型として宣言する。

Operand型は、メンバとして「type」と「value」とを有するクラスである。このうち、「type」には、レジスタや即値等のオペランドの種類が格納される。そして、「value」には、即値やレジスタのインデックス等の数値が格納される。なお、ソースファイル３４とは別のソースファイルにおいてOperand型を定義してもよい。

続いて、制御部３１は、ニーモニック関数movの内部にコードT2～T4を生成する。

コードT2は、先に取得した関数名「mov」を変数「nm」に代入する文である。なお、この例では変数「nm」に文字列である「mov」を代入しているが、関数名「mov」と整数値とを予め一対一に対応させておき、その整数値を変数「nm」に代入してもよい。

また、コードT3は、ニーモニック関数movが引数として受け取ったOperand型の「OP0」と「OP1」とを配列「oplist」に代入する文である。

そして、コードT4は、MachineCodeEmitter関数を呼び出し、そのMachineCodeEmitter関数の返り値を関数writeでメモリ３に書き込むコードである。MachineCodeEmitter関数は、変数「nm」と変数「oplist」とを引数として受け取り、変数「oplist」で表されるオペランドに対して変数「nm」で表される命令が行う処理を表す機械語を生成する関数である。なお、MachineCodeEmitter関数は、第２の関数の一例であって、プロセッサ２のアセンブラと共に作成された動作が検証済の関数である。

以上により、制御部３１が、ニーモニック関数movを自動的に生成したことになる。

この後は、命令情報３３の二行目以降に対しても制御部３１が上記と同様の処理を行うことにより、関数名が「load」、「shiftR」、「add」等のニーモニック関数を自動で生成する。そして、制御部３１が、プロセッサ２の命令セットに含まれる全ての命令に対応したニーモニック関数が記述されたソースファイル３４をメモリ等の記憶部に出力する。

これにより、開発者が手作業でニーモニック関数を記述する手間がなくなり、ニーモニック関数を生成するための工数を低減できる。

更に、そのニーモニック関数の関数名は、開発者が慣れ親しんだ命令のニーモニックと同一となるため、開発者が関数名を覚える手間がなく、開発者にとって扱いやすいニーモニック関数を提供できる。

しかも、そのニーモニック関数の引数の個数は、命令のオペランドの個数に等しい。これにより、開発者が慣れ親しんだ「mov OP0 OP1」というアセンブリの文法に類似したコード「mov(OP0,OP1)」でニーモニック関数を呼び出すことができるため、開発者の利便性が向上する。

図１０は、上記のMachineCodeEmitter関数のC++の疑似ソースコードが記述されたソースファイル４３の一例を示す図である。そのソースファイル４３は、アセンブラ自身のソースファイルの一部でもよい。

この例では、コードT5～T8によりMachineCodeEmitter関数の機能が実現される。このうち、コードT5は、変数「mnemonic」と変数「op0」、「op1」、「op2」、「op3」の各々を３２ビットの符号無し整数として宣言する文である。

また、コードT6は、MachineCodeEmitter関数が引数として受け取った変数nmの内容に対応したオペコードを変数「mnemonic」に代入するコードである。例えば、変数「nm」で特定されるニーモニックが「mov」の場合には、mov命令のオペコード「0x01000000」が変数「mnemonic」に代入される。

そして、コードT7は、変数「nm」の内容に応じて変数「OP0」、「OP1」の各々に対してビット操作を行うことにより、命令の仕様で定められたビット位置にこれらの変数を位置させるコードである。例えば、mov命令の場合には、３２ビットの内の１７～２４ビットに第１オペランドが位置し、８～１６ビットに第２オペランドが位置する。そこで、mov命令の場合には、文「op0=OP0<<16」を実行することにより、３２ビットの内の１７～２４ビットに変数「OP0」のビット列を位置させる。一方、変数「OP1」については、文「op1=OP1<<8」を実行することにより、３２ビットの８～１６ビット目に「OP1」のビット列を位置させる。なお、mov命令は第３オペランドをとらないため、文「op2=0」により変数「op2」を「0」にする。

更に、コードT8は、各変数「mnemonic」、「op0」、「op1」、「op2」の各々を上位ビットから順に連結したビット列を生成し、それを返り値として返す文である。そのビット列は、変数「oplist」で特定されるオペランドに対して変数「nm」で特定される命令が行う処理を表す機械語である。

以上説明した関数生成方法によれば、制御部３１が、命令情報３３に基づいてニーモニック関数の内部にMachineCodeEmitter関数を呼び出すコードを生成する。MachineCodeEmitter関数は、引数「nm」で表される命令が、引数「oplist」で表されるオペランドに対して行う処理を表す機械語を生成する関数である。そのため、ニーモニック関数の作成に際し、命令の仕様書を基にして開発者が手作業で機械語を生成するコードを記述する必要がなくなり、ニーモニック関数を作成するのに要する工数を減らすことができる。

プロセッサ２（図１参照）を開発する際には、そのプロセッサ２で動作する機械語の実行ファイルを生成するためのツール群も開発される。そのツール群には、C言語やC++言語で記述されたソースファイルをアセンブリ言語に変換するためのコンパイラや、アセンブリ言語を機械語に変換するためのアセンブラが含まれる。そのようなツール群としては、例えばLLVMがある。MachineCodeEmitter関数は、LLVMのアセンブラに内蔵されている関数であり、アセンブラを開発した際にその動作が検証されて提供されている。そのため、本実施形態では、制御部３１が生成したニーモニック関数が正しい機械語を生成しているかという動作検証を行う必要がない。これにより、ニーモニック関数を作成する工数に加え、ニーモニック関数の動作検証に要する工数も低減でき、ニーモニック関数の作成に伴う工数を低減することができる。

なお、本実施形態ではLLVMの中に含まれるMachineCodeEmitter関数を例に説明したが、本実施形態はこれに限定されない。例えば、MachineCodeEmitter関数に代えて、LLVMとは別のツール群（例えばGCC）の中の機械語生成関数を呼び出すようにニーモニック関数を生成してもよい。機械語生成関数は、MachineCodeEmitter関数と同等の機能を有する関数である。この場合は、制御部３１は、図９の各変数「mov」、「OP0」、「OP1」をその機械語生成関数の引数の個数や型に変換するようなコードを各コードT2、T3に代えてソースファイル３４に記述すればよい。

また、図９の例では、最大で三つの変数「OP0」、「OP1」、「OP2」を配列「oplist」にまとめてMachineCodeEmitter関数に渡すことができるが、各変数「OP0」、「OP1」、「OP2」を別々の引数として受け取る機械語生成関数もある。その場合には、制御部３１は、コードT3を生成せずに、各変数「OP0」、「OP1」、「OP2」のそれぞれを別々の引数として機械語生成関数に渡すようなコードを生成すればよい。

［機能構成］
次に、本実施形態に係る情報処理装置３０の機能構成について説明する。

図１１は、本実施形態に係る情報処理装置３０の機能構成図である。
図１１に示すように、情報処理装置３０は、制御部３１と記憶部３２とを有する。

このうち、記憶部３２は、HDD(Hard Disk Drive)等の記憶装置やDRAM等のメモリによって実現することができ、前述の命令情報３３とニーモニック関数のソースファイル３４とを記憶する。

また、制御部３１は、情報処理装置３０の全体を制御する処理部であり、第１の生成部３６、第２の生成部３７、第３の生成部３８、及び出力部３９を備える。

第１の生成部３６は、命令情報３３を参照して、各命令に対応したニーモニック関数を生成し、そのニーモニック関数をソースファイル３４に記述する処理部である。一例として、第１の生成部３６は、命令情報３３からニーモニックを取得し、そのニーモニックと同じ関数名３４ａ（図９参照）をニーモニック関数に付与する。また、第１の生成部３６は、ニーモニック関数の引数として、命令情報３３におけるオペランドの個数に等しい個数の引数を宣言する。

例えば、命令情報３３におけるニーモニックが「mov」の場合には、第１の生成部３６は、ニーモニック関数movとして「void mov(Operand OP0,Operand OP1){}」という関数を生成し、その関数のソースコードをソースファイル３４に記述する。なお、第１の生成部３６が記述したニーモニック関数の中身は空である。

また、第１の生成部３６は、命令セットに含まれる全てのニーモニック関数を一つのソースファイル３４に記述してもよいし、ニーモニック関数の各々を異なるソースファイルに記述してもよい。

一方、第２の生成部３７は、前述のMachineCodeEmitter関数を呼び出すコードを生成し、そのコードをソースファイル３４に記述する処理部である。MachineCodeEmitter関数の引数は、各オペランドに対応した変数である「oplist」と、命令に対応した変数である「mov」である。これらの引数を受け取ると、MachineCodeEmitter関数は、命令がオペランドに対して行う処理を表す機械語を生成する。

そして、第３の生成部３８は、MachineCodeEmitter関数が生成した機械語をメモリ３に書き込むコードを生成し、そのコードをソースファイル３４に記述する処理部である。そのコードは、例えば「write(MachineCodeEmitter(nm, oplist);」という書式になる。

出力部３９は、第１～第３の生成部３６～３８が記述したソースファイル３４を記憶部３２に書き出す。

［処理の流れ］
図１２は、本実施形態に係る関数生成方法について示すフローチャートである。

まず、第１の生成部３６が、命令情報３３を参照して、ニーモニックとこれに対応するオペランドの個数とを取得する（ステップＳ１０）。

次いで、第１の生成部３６が、中身が空のニーモニック関数を生成し、それをソースファイル３４に記述する（ステップＳ１１）。例えば、ニーモニックが「mov」の場合は、第１の生成部３６は、「void mov(Operand OP0,Operand OP1){}」という中身が空のニーモニック関数をソースファイル３４に記述する。なお、このニーモニック関数の引数の個数は、ステップＳ１０で取得したオペランドの個数となる。

次に、第２の生成部３７がMachineCodeEmitter関数を呼び出すコードを生成する（ステップＳ１２）。例えば、第２の生成部３７は、第１の生成部３６が記述したニーモニック関数の内部に、MachineCodeEmitter関数を呼び出すコード「MaschineCodeEmitter(nm,oplist);」を記述する。

これと共に、第２の生成部３７は、図９のコードT2、T3等のように、ニーモニック関数の引数の値をMachineCodeEmitter関数に渡すための文もソースファイル３４に記述する。

続いて、第３の生成部３８が、MachineCodeEmitter関数が生成した機械語をメモリ３に書き込むコードを生成する（ステップＳ１３）。一例として、第３の生成部３８は、関数writeの引数にMachineCodeEmitter関数を記述した「write(MachineCodeEmitter(nm, オペランドリスト));」というコードT4（図９参照）を生成し、それをソースファイル３４に記述する。

そして、命令情報３３に含まれる全ての行に対してステップＳ１０～Ｓ１３の処理を行う。その後、出力部３９が、全てのニーモニック関数を含むソースファイル３４を記憶部３２に書き出す（ステップＳ１４）。

以上説明した本実施形態によれば、第１～第３の生成部３６～３８の各々が命令情報３３に基づいてニーモニック関数を自動的に生成する。そのため、開発者が手作業でニーモニック関数を記述する場合と比較して、ニーモニック関数を生成する際の工数を減らすことができる。

しかも、このように各生成部３６～３８がニーモニック関数を生成することで、開発者が手作業でニーモニック関数を記述する場合よりもバグの発生を抑制できる。その結果、バグのあるプログラムをターゲットマシン１で無駄に実行する時間が減り、ターゲットマシン１のハードウェア資源の無駄な消費を改善できる。

［開発環境］
開発者は、上記のようにニーモニック関数が記述されたソースファイル３４を利用することにより、ターゲットマシン１のプロセッサ２で実行する様々なアプリケーションプログラムを開発することができる。そこで、そのアプリケーションプログラムの開発環境について以下に説明する。

図１３は、ニーモニック関数が記述されたソースファイル３４を利用した開発環境について示す模式図である。

この例では、情報処理装置３０の内部に開発環境を構築する場合を想定する。その場合、ニーモニック関数を生成するツールである制御部３１が命令情報３３を参照し、図１２のフローチャートに従って全てのニーモニック関数を含むソースファイル３４を生成する。

一方、開発者は、例えばC++を用いてアプリケーションプログラム用のソースファイル４１を作成する。そのソースファイル４１は、JITコンパイラ技術の機能を使用することを前提としたファイルであって、C++のライブラリ関数に加えて、ソースファイル３４にあるニーモニック関数を呼び出す記述を含む。

そして、開発者の指示の下で、コンパイラ、アセンブラ、及びリンカのプログラム群４２がビルドを行う。このうち、コンパイラには、例えば#defineで始まるディレクティブの処理を行うためのプリプロセッサが含まれる。そして、ビルドにおいては、プログラム群４２に含まれるコンパイラがソースファイル４１をコンパイルする。

このとき、コンパイラは、各ソースファイル３４、４１、４３を読み込んでアセンブリの中間言語ファイルを出力する。これらのソースファイルのうち、ソースファイル４３は、前述のMachineCodeEmitter関数が記述されたソースファイルである。そして、アセンブラがその中間言語ファイルを機械語の命令列に変換してオブジェクトファイルを生成する。

その後、リンカは、オブジェクトファイルと種々のライブラリとをリンクすることにより、プロセッサ２で実行可能なバイナリ形式の実行可能プログラム４４を生成する。

なお、ここでは、前述のソースファイル４３が、アセンブラ自身のソースファイルの一部であることを例にして説明した。アセンブラを開発するときの動作検証を通じて、ソースファイル４３に記述されたMachineCodeEmitter関数の動作が正しいことは検証されている。

なお、機械語の生成ルールが秘匿されているようなCPUでは、アセンブラのソースファイルが公開されていないものの、実行ライブラリファイルが入手可能なこともある。その場合には、ソースファイル４３に代えて機械語生成関数の機能を予め機械語の命令列に変換済みの実行ライブラリファイル４３ａを入力として用い、これをリンクすることにより実行可能プログラム４４を生成すればよい。

以上により、アプリケーションプログラム用のソースファイル４１から実行可能プログラム４４を生成することができる。

その実行可能プログラム４４は、JITコンパイラ技術によって、実行時のパラメータや環境に応じて最適な機械語の命令列を実行時に生成する。そのため、この実行可能プログラム４４は、深層学習や画像処理等のようにループの回数が膨大で大規模な演算が必要なアプリケーションプログラムの高速化に特に有効である。同様に、動画圧縮等の画像処理、暗号化処理、復号処理、及びブロックチェーン技術等で使用するアプリケーションプログラムも高速化することができる。

なお、実行可能プログラム４４の実行速度を更に速めるために、以下のようにC++のマクロとしてニーモニック関数を記述してもよい。

図１４は、C++のマクロを使用しないで生成した実行可能プログラム４４を実行するときのメモリ３の内容を示す模式図である。

この例では、開発者によってソースファイル４１にニーモニック関数mov(OP0,OP1)が記述されている場合を想定している。この場合、命令を実行すべきアドレスがニーモニック関数mov(OP0,OP1)の呼び出し処理に対応する機械語が格納されたメモリアドレスに到達すると、関数呼び出しによってソースファイル３４におけるニーモニック関数movが呼び出される。

関数呼び出しの処理は、処理前にレジスタR0、R1、…のデータをメモリ３に退避させたり、処理後にそのデータをレジスタR0、R1、…に復帰させたりするためオーバーヘッドが大きく、プログラム実行を遅くしてしまう。

一方、図１５（ａ）は、第１の生成部３６がC++のマクロとしてニーモニック関数movを生成したしたソースコード４５の一例を示す図である。

図１５（ａ）に示されるように、第１の生成部３６は、ステップＳ１１（図１２参照）において、マクロ「#define」を用いてニーモニック関数movのマクロをソースファイル３４に記述する。

また、図１５（ｂ）は、このようにマクロを使用した場合において、実行可能プログラム４４を実行するときのメモリ３の内容を示す模式図である。

マクロを利用すると、コンパイル時にプリプロセッサがソースファイル４１においてニーモニック関数mov(OP0,OP1)が記述された部分にソースコード４５を展開する。そのため、関数呼び出しを行わなくても「mov OP0, OP1」を実行する機械語をメモリ３に書き込むことができ、実行可能プログラム４４がJITコンパイル技術で機械語を生成する処理の実行速度を速めることが可能となる。

（第２実施形態）
命令セットの中には、ニーモニックが同一であるにも関わらず、機械語が相違する複数の命令が存在する場合がある。そのような相違を反映させるために、これらの命令ごとにニーモニック関数の関数名も変えてしまうと、開発者が覚えるべき関数名が増えてしまい、開発者の負担が増えてしまう。そこで、本実施形態では、ニーモニックが同一で機械語が相違する複数の命令が存在する場合でも開発者の負担増を抑制できる例について説明する。

まず、ニーモニックが同一で機械語が相違する命令について説明する。

図１６は、そのような命令をアセンブリで記述した例について示す図である。
これらの命令５１、５２は、いずれもストア命令であって、そのニーモニックはいずれも「STR」で同一である。

このうち、命令５１は、「アドレスレジスタ」に格納されているアドレスのメモリ３（図１参照）に「SRCレジスタ」の値を書き込み、その後、「アドレスレジスタ」に格納されている値を「即値」分だけインクリメントする命令である。

一方、命令５２は、「アドレスレジスタ」に格納されている値を最初に「即値」分だけインクリメントし、インクリメントされた値のアドレスのメモリ３に「SRCレジスタ」の値を書き込む命令である。

このように、命令５１、５２は、「アドレスレジスタ」に格納されている値を「即値」分だけインクリメントするタイミングが相違しており、異なる処理を行う命令である。

例えば、命令５１ではニーモニックに続く文字列が「SRCレジスタ、[アドレスレジスタ]、即値」となっているのに対し、命令５２ではその文字列が「SRCレジスタ、[アドレスレジスタ、即値]!」となっている。アセンブラは、このような文字列の相違に基づいて両者を区別し、アセンブラ内部で命令５１のニーモニックを「STRpost」と読み替え、かつ命令５２のニーモニックを「STRpre」と読み替えている。

図１７（ａ）は、これらのニーモニック「STRpost」、「STRpre」を採用した場合の第１実施形態の命令情報３３を模式的に示す図である。

そして、図１７（ｂ）は、この命令情報３３に基づいて、第１実施形態に従って生成したニーモニック関数について示す図である。

図１７（ｂ）に示すように、この場合は、命令５１に対応するニーモニック関数STRpostと、命令５２に対応するニーモニック関数STRpreが生成される。開発者は、関数名「STRpost」、「STRpre」を覚えておき、これらをアプリケーションプログラム用のソースファイルに記述することになる。

しかしながら、これらのニーモニック関数の元となる二つの命令はいずれもストア命令であるにも関わらず、このように関数名が異なると開発者が覚えるべき関数名が増えてしまい、開発者の負担が増加することになる。

そこで、本実施形態では、以下のようにしてニーモニック関数の関数名が増加するのを抑制する。

図１８は、本実施形態で使用する命令情報３３について模式的に示す図である。

図１８に示すように、本実施形態に係る命令情報３３においては、関数名、ニーモニック、オペランドの個数、及びオペランドの型が対応付けられて格納される。命令情報３３の各々の行はそれぞれ異なる命令に対応しており、例えば１行目はmov命令に対応し、２行目はload命令に対応する。なお、第１実施形態と同様に、命令情報３３は開発者によって予め作成される。

この命令情報３３において、関数名は、ニーモニック関数の名前であって、各ニーモニックに対応した名前が格納される。なお、本実施形態では関数名とニーモニックとを一対一に対応させる必要はなく、ニーモニックにこだわらずに開発者が覚えやすい同一の関数名を複数のニーモニックに対応させてもよい。例えば、STRpost命令とSTRpre命令はいずれもストア命令であるため、これらの命令に対応した関数名はいずれも「STR」とする。

また、オペランドの個数は、第１実施形態と同様に、各命令がとるオペランドの個数である。

そして、オペランドの型は、命令のオペランドの種類を示す型のリストである。例えば、mov命令においては、第１オペランドはレジスタであり、第２オペランドは即値となる。本実施形態では、レジスタを示すRegister型と即値を示すImmediate型とを予め定義しておき、これらの型のリストをニーモニック「mov」に対応付けて命令情報３３に予め格納する。なお、そのリストの第１成分は第１オペランドの型を示し、第２成分は第２オペランドの型を示す。また、三つのオペランドをとる命令においては、リストの第３成分は第３オペランドの型を示す。

ここで、C++の文法においては、二つの関数の関数名と引数の個数とが同一であっても、それらの引数の型が異なれば各関数を異なる関数として扱うことができる。

そこで、本実施形態では、二つのニーモニック関数STRの各々で引数の型を変えることにより、関数名と引数の個数とが同一であっても異なる処理を実現できるようにする。この例では、ニーモニック「STRpost」に対応したニーモニック関数STRの引数の型をRegister型とPostIncAddrReg型とする。そして、ニーモニック「STRpre」に対応したニーモニック関数STRの引数の型をRegister型とPreIncAddrReg型とする。

これにより、本実施形態に係る命令情報３３においては、関数名が「STR」で同一であり、かつ、オペランドの型が異なる複数の相異なるニーモニック「STRpre」、「STRpost」が存在することになる。

なお、第１実施形態における命令情報３３では、図１７（ａ）のようにニーモニック「STRpost」のオペランドの個数が「3」であるのに対し、本実施形態では図１８のようにその個数は「2」となる。これは、後述のようにPostIncAddrReg型には二つのメンバがあり、これらのメンバにSTRpost命令の第２オペランドと第３オペランドを格納することができるためである。同様に、PreIncAddrReg型も二つのメンバがあり、これらのメンバにSTRpre命令の第２オペランドと第３オペランドを格納できるため、「STRpre」に対応したオペランドの個数も「2」となる。

図１９（ａ）～（ｅ）は、オペランドの型を定義するC++の疑似ソースコードの例について示す図である。

図１９（ａ）は、Register型を定義するソースコードの例である。Register型は、前述のようにレジスタを示す型である。ここでは、Register型を定義するクラスのクラス名を「Reg」とし、そのクラスのメンバを「regIndex」とする。「regIndex」は、レジスタのインデックスを格納する変数であり、例えば符号無し整数型として宣言される。

図１９（ｂ）は、AddrReg型を定義するソースコードの例である。AddrReg型は、アドレスレジスタを示す型である。AddrReg型を表すクラス「AddrReg」のメンバは、アドレスのベース値を保持するレジスタのインデックスを格納する「regIndex」と、アドレスオフセット値である即値を格納する「imm_value」である。なお、「imm_value」の初期値は0とする。

図１９（ｃ）は、PostIncAddrReg型を定義するソースコードの例である。

PostIncAddrReg型のクラスのメンバは、アドレスのベース値を保持するレジスタのインデックスを格納する「regIndex」と、命令実行後にアドレスのベース値をどれだけインクリメントするかを示す即値を格納する「imm_value」である。

図１９（ｄ）は、PreIncAddrReg型を定義するソースコードの例である。

PreIncAddrReg型のクラスのメンバは、アドレスのベース値を保持するレジスタのインデックスを格納する「regIndex」と、命令実行前にアドレスのベース値をどれだけインクリメントするかを示す即値を格納する「imm_value」である。

図１９（ｅ）は、Immediate型を定義するソースコードの例である。Immediate型は、前述のように即値を示す型である。この例では、Immediate型を定義するクラスのクラス名を「Imm」とし、そのクラスのメンバを「imm_value」とする。「imm_value」は、即値を格納する整数型の変数である。

図２０（ａ）は、ニーモニック「STRpost」に対応したニーモニック関数STRのC++の疑似ソースコードが記述されたソースファイル３４の模式図である。

このニーモニック関数STRのソースコードは、命令情報３３に基づいて制御部３１が次のように生成する。

例えば、命令情報３３（図１８参照）においてニーモニック「STRpost」に対応する関数名は「STR」であるから、制御部３１はこのニーモニック関数の関数名５３ａを「STR」とする。

また、制御部３１は、命令情報３３を参照することによりニーモニック「STRpost」のオペランドの個数が「2」であることを特定し、コードT11において「OP0」と「OP1_2」の2個の変数を引数として宣言する。

更に、制御部３１は、命令情報３３を参照することによりニーモニック「STRpost」のオペランドの型がRegister型とPostIncAddrReg型であることを特定する。これに基づいて、制御部３１は、コードT11において各変数「OP0」と「OP1_2」の各々の型をRegister型とPostIncAddrReg型として宣言する。

また、制御部３１は、このニーモニック関数STRの内部においてコードT12～T15を生成する。

このうち、コードT12は、命令情報３３のニーモニック「STRpost」を変数「nm」に代入する文である。また、制御部３１は、命令情報３３から特定したRegister型とPostIncAddrReg型に基づいて、MachineCodeEmitter関数の引数「oplist」に含める変数の個数を特定する。例えば、Register型はメンバ変数が一つであり、PostIncAddrReg型はメンバ変数が二つであるため、これらの型のメンバ変数の総数は三つとなる。そこで、制御部３１は、三つのメンバに対応する三つのOperand型の変数「op0」、「op1」、「op2」を宣言するコードT13を生成する。このうち、変数「op0」は、Register型の変数「OP0」に対応する。また、変数「op1」、「op2」は、PostIncAddrReg型の変数「OP1_2」に対応した二つの変数である。なお、Register型、AddrReg型、PostIncAddrReg型、PostIncAddrReg型、及びImmediateの各々の型がそれぞれいくつのメンバ変数を有するかは、図１９の各クラスを定義するソースファイルにおいて予め定義しておけばよい。

一方、コードT14は、ニーモニック関数STRが引数として受け取った変数「OP0」、「OP1_2」の各々を、MachineCodeEmitter関数の引数「oplist」の型に変換するコードである。

例えば、文「op0.type = REGISTER」により、変数OP0の型「Register」に対応した文字列「REGISTER」が変数op0のメンバ「type」に代入される。また、文「op0.value = OP0.regIndex;」により、変数OP0のメンバ「regIndex」が、変数op0のメンバ「value」に代入される。

同様に、文「op1.type = REGISTER;」と文「op1.value = OP1_2.regIndex;」は、PostIncAddrReg型の変数OP1_2をOperand型の変数op1に型変換をするための文である。そして、文「op2.type = IMMEDIATE_VALUE;」と文「op2.value = OP1_2.imm_value;」は、PostIncAddrReg型の変数「OP1_2」をOperand型の変数「op2」に型変換をするための文である。

更に、文「oplist={op0,op1,op2}」は、Operand型の配列「oplist」の各要素に上記の各変数「op0」、「op1」、「op2」を代入するコードである。その配列「oplist」は、コードT15においてMachineCodeEmitter関数に渡される。

コードT15は、MachineCodeEmitter関数を呼び出して、そのMachineCodeEmitter関数が生成した機械語を関数writeでメモリ３に書き込むコードである。

このようなソースコードによれば、ニーモニック関数STRが引数として受け取った変数「OP0」、「OP1_2」の各々がコードT14においてOperand型の配列「oplist」に変換される。そのため、MachineCodeEmitter関数の第２引数「oplist」の型に各変数「OP0」、「OP1_2」の型を合わせることができ、開発者が意図した機械語をMachineCodeEmitter関数が生成することができる。

図２０（ｂ）は、ニーモニック「STRpre」に対応した本実施形態に係るニーモニック関数STRのC++の疑似ソースコードが記述されたソースファイル３４の模式図である。

図２０（ａ）の例と同様に、このニーモニック関数STRのソースコードについても制御部３１が命令情報３３に基づいて生成する。なお、図２０（ａ）と図２０（ｂ）では関数名がいずれも「STR」で同一となっているが、これらの関数の第２引数の型が相違するため、これらの関数はC++の文法上は別々の関数として区別されるため問題にはならない。

このように、本実施形態においては、関数名と引数の個数が同一でオペランドの型が異なる複数のニーモニックを命令情報３３に格納することにより、これらのニーモニックから同じ関数名のニーモニック関数を生成できる。そのため、ニーモニック関数の関数名が増大するのを防止でき、開発者が覚えるべき関数名が増えるのを抑制することができる。

また、本実施形態では以下のようにデバッグが容易になるという利点も得られる。

図２１（ａ）は、本実施形態とは異なり、ニーモニック関数の引数をOperand型という共通の型で表した場合のニーモニック関数movのC++の疑似ソースコード５５を示す図である。この場合は、ニーモニック関数movの引数とMachineCodeEmitter関数の第２引数の型がいずれもOperand型であるため、本実施形態のような型変換のコードはニーモニック関数movの内部に記述されていない。

そして、図２１（ｂ）は、このニーモニック関数movを利用して開発者が記述したアプリケーションプログラム用のソースファイル４１のC++の疑似ソースコードを示す図である。

開発者は、ソースファイル４１における文「op0.type=REGISTER;」によって第１引数「OP0」がレジスタであることを意図しており、かつ文「op1.type=IMMEDIATE_VALUE」によって第２引数「OP1」が即値であることを意図している。また、ソースファイル４１における文「mov(OP1,OP0);」は、図２１（ａ）においてニーモニック関数movが引数として２つのOperand型の変数を受け付けるよう記述されているため、C++の文法上は問題がない。

しかし、ニーモニック関数movとMachineCodeEmitter関数は、mov命令の第１オペランドがレジスタであり、かつ第２オペランドが即値であることを前提として作成されている。これに対し、文「mov(OP1, OP0);」においては第１引数に即値を表す変数「OP1」が記述され、第２引数にレジスタを表す変数「OP0」が記述されている。文「mov(OP1,OP0);」は、C++の文法上は問題がないため、このような誤りがあってもコンパイル時にエラーが出ない。

よって、この場合には、コンパイル済みのプログラムを実行した後に、開発者がその出力で得られる結果が本来の結果と異なっていることを認識して初めてソースファイル４１のソースコードの誤りに気付くことになる。また、結果がおかしいことに開発者が気付かなければ、そのまま正しい出力が得られているものとして開発者が誤りを見過ごしてしまうことになる。更に、仮に出力がおかしいことに開発者が気付いたとしても、ソースファイル４１の記述行数が多い場合には、記述が誤っている箇所を開発者が特定するのに時間がかかり、デバックに長時間を要してしまう。

一方、図２２（ａ）は、本実施形態で生成したニーモニック関数movのC++の疑似ソースコードが記述されたソースファイル３４の模式図である。本実施形態では、ニーモニック関数movの引数の型は{Register型、Immediate型}となる。

そして、図２２（ｂ）は、このニーモニック関数movを利用して開発者が記述したアプリケーションプログラム用のソースファイル４１のC++の疑似ソースコードの例を示す図である。

ここで、開発者が誤ってニーモニック関数movの第１引数と第２引数の各々の型を逆にしてしまい、「mov(imm,reg);」と記述したとする。この場合は、ソースファイル４１におけるニーモニック関数movの呼び出し時の引数の型の順番が相違しているため、コンパイル時にコンパイラがエラーを出す。よって、図２２（ａ）の例よりも早く開発者が間違いに気づくことができ、かつコンパイル時のエラーメッセージに基づいて間違いの箇所を特定するのが容易となる。

［処理の流れ］
次に、本実施形態に係る関数生成方法について説明する。
図２３は、本実施形態に係る関数生成方法について示すフローチャートである。

まず、第１の生成部３６が、命令情報３３を参照して、相互に対応する関数名、ニーモニック、オペランドの個数、及びオペランドの型を取得する（ステップＳ２０）。

次いで、第１の生成部３６が、中身が空のニーモニック関数を生成し、それをソースファイル３４に記述する（ステップＳ２１）。そのニーモニック関数の引数の個数は、ステップＳ２０で取得したオペランドの個数である。また、第１の生成部３６は、ニーモニック関数の引数の型を、ステップＳ２０で取得したオペランドの型に宣言するコードT11（図２０（ａ）参照）を生成する。

次に、第２の生成部３７が、ニーモニック関数が引数として受け取った変数の型を、MachineCodeEmitter関数の第２引数である配列「oplist」のOperand型に変換するコードを生成する（ステップＳ２２）。例えば、第２の生成部３７は、図２０で説明したコードT14を生成し、それをニーモニック関数の内部に記述する。

次いで、第２の生成部３７がMachineCodeEmitter関数を呼び出すコードを生成する（ステップＳ２３）。例えば、第２の生成部３７は、MachineCodeEmitter関数を呼び出すコード「MaschineCodeEmitter(nm,oplist);」を生成し、それをニーモニック関数の内部に記述する。このとき、第２の生成部３７は、MaschineCodeEmitterの第２引数に、ステップＳ２２の型変換後の配列「oplist」を渡す。これと共に、第２の生成部３７は、図２０のコードT11、T12等のような変数の宣言と代入を行う文もソースファイル３４に記述する。

続いて、第３の生成部３８が、MachineCodeEmitter関数が生成した機械語をメモリ３に書き込むコードを生成し、それをソースファイル３４に記述する（ステップＳ２４）。一例として、第３の生成部３８は、関数writeの引数にMachineCodeEmitter関数を記述した「write(MachineCodeEmitter(nm, oplist));」というコードをソースファイル３４に記述する。

そして、命令情報３３に含まれる全ての行に対してステップＳ２０～Ｓ２４の処理を行う。その後、出力部３９が、全てのニーモニック関数を含むソースファイル３４を記憶部３２に書き出す（ステップＳ２５）。

以上説明した本実施形態によれば、ステップＳ２１において、第１の生成部３６が、ニーモニック関数の引数の型をオペランドの型に宣言するコードT11（図２０（ａ）参照）を生成する。これにより、複数のニーモニック関数の関数名を同一にすることができるため、開発者が覚えるべき関数名が増加するのを防止できる。

しかも、図２２（ａ）、（ｂ）を参照して説明したように、ニーモニック関数の引数の型が間違っているとコンパイル時にエラーが出るため、ソースファイル４１のバグを低減できる。そのため、バグのあるプログラムをターゲットマシン１で無駄に実行する時間が減り、ターゲットマシン１のハードウェア資源の無駄な消費を改善でき、かつ開発者がデバックをするのに要する工数を改善できる。

（第３実施形態）
命令セットに含まれる命令には、オペランドの値に制限が課せられている命令がある。例えば、「mov オペランド0、オペランド1」というフォーマットで記述されるmov命令においては、「オペランド1」の即値の範囲は、符号付9ビットの整数で表現できる-256～+255に制限される。開発者がこのような制限を忘れてニーモニック関数movをソースファイル３４に記述しても、そのソースファイル３４はコンパイル時にエラーとはならず、プログラム実行時にエラーとなる。これについて図２４（ａ）、（ｂ）を参照しながら説明する。

図２４（ａ）は、第２実施形態に従って生成したニーモニック関数movのC++のソースコードが記述されたソースファイル３４の例を示す図である。このソースコードにおいては、引数のOP0、OP1に対してはRegister型やImmediate型等の型の制限はあるものの、引数の値自体には制限がない。

図２４（ｂ）は、このニーモニック関数movを利用して開発者が記述したアプリケーションプログラム用のソースファイル４１のC++の疑似ソースコードの例を示す図である。

この例では、文「imm.value=-1000000;」により、変数immのメンバ「value」に値「-1000000」を代入している。前述のように、mov命令の第２オペランドの値は-256～+255の範囲内に制限されているため、値「-1000000」は第２引数として不適切な値である。

しかし、ソースファイル４１はC++の文法上は正しく記述されているためコンパイル時にエラーは発生しない。また、コンパイルで得られた実行可能プログラムを実行すると、その実行可能プログラムは、MachineCodeEmitter関数を呼び出すことにより、即値-1000000をレジスタに格納するmov命令に対応する機械語を生成しようとする。但し、そのような動作に対応する機械語は存在しないので、実行可能プログラムはその機械語を生成することができずエラーを出力する。このとき、ソースファイル４１の記述行数が多い場合には、そのソースファイル４１におけるどのニーモニック関数の呼び出しがこのエラーの原因となっているかを開発者が特定するのは難しい。

そこで、本実施形態では、以下のようにしてソースファイル４１におけるソースコードの誤りを開発者が気付けるようにする。

図２５は、本実施形態で使用する命令情報３３について模式的に示す図である。

図２５に示すように、本実施形態に係る命令情報３３においては、関数名、ニーモニック、オペランドの個数、オペランドの型、及びオペランドに課された制限の各々が対応付けられて格納される。第１、第２実施形態と同様に、この命令情報３３は、開発者によって予め作成される。

また、第１、第２実施形態と同様に、命令情報３３の各々の行はそれぞれ異なる命令に対応する。例えば、１行目はmov命令に対応しており、オペランドに課された制限は{レジスタのインデックスの範囲が0～31、即値の範囲が-256～+255}というリスト形式で表現される。なお、そのリストの第１成分は第１オペランドに対する制限を表し、第２成分は第２オペランドに対する制限を表す。命令が第３オペランドをとる場合には、その第３オペランドに対する制限がリストの第３成分に格納される。

また、命令情報３３の２行目はshiftR命令に対応しており、オペランドに課された制限は{レジスタのインデックスの範囲が0～31、レジスタのインデックスの範囲が0～31、即値の範囲が-63～+63}となる。

図２６は、mov命令に対応した本実施形態に係るニーモニック関数movが記述されたソースファイル３４のC++の疑似ソースコードの例について示す模式図である。

このニーモニック関数movのソースコードは、命令情報３３に基づいて制御部３１が次のように生成する。

まず、制御部３１は、第２実施形態と同様にしてニーモニック関数movにコードT11～T15を記述する。更に、制御部３１は、命令情報３３を参照することにより、オペランドに課せられた制限を命令ごとに取得する。例えば、mov命令の場合は、{レジスタのインデックスの範囲が0～31、即値の範囲が-256～+255}という制限を制御部３１が取得する。

そして、制御部３１は、ニーモニック関数movの引数が表すオペランドが上記の制限を違反している場合に例外を発生させるコードT16を生成し、それをソースファイル３４に記述する。

ここでは、if文によりオペランドが制限を違反しているかどうかを判断し、違反している場合にthrow文で例外を生成する。例えば、「OP0」のregIndexの値が0～31の範囲にない場合には、プログラム実行の際に「”Invalid register index is passed to mov mnemonic function.”」というエラーメッセージが標準出力に出力される。また、「OP1」のvalueの値が-256～+255の範囲にない場合には、プログラム実行の際に「”Invalid immediate value is passed to mov mnemonic function.”」というエラーメッセージが標準出力に出力される。

そして、図２７は、このニーモニック関数movを利用して開発者が記述したアプリケーションプログラム用のソースファイル４１のC++の疑似ソースコードの例を示す図である。

この例では、文「imm0.value = 1000000;」により、ニーモニック関数movの第２引数「imm0」のメンバ「value」に1000000を代入している。前述のように、mov命令の第２オペランドの値は-256～+255の範囲に制限されている。よって、文「mov(reg0, imm0);」を実行すると例外が発生し、「”Invalid immediate value is passed to mov mnemonic function.”」という文字列が標準出力に出力されることになる。

これにより、開発者は、ニーモニック関数movの引数がmov命令の制限を違反していることに気づくことができ、ソースコード６６を簡単にデバッグすることができる。

［処理の流れ］
次に、本実施形態に係る関数生成方法について説明する。
図２８は、本実施形態に係る関数生成方法について示すフローチャートである。

まず、第１の生成部３６が、命令情報３３を参照して、相互に対応する関数名、ニーモニック、オペランドの個数、オペランドの型、及びオペランドに課された制限を取得する（ステップＳ３０）。

次いで、第１の生成部３６が、中身が空のニーモニック関数を生成し、それをソースファイル３４に記述する（ステップＳ３１）。そのニーモニック関数の引数の個数は、ステップＳ３０で取得部３５が取得したオペランドの個数である。また、その引数の型は、ステップＳ３０で取得部３５が取得したオペランドの型である。

次に、第２の生成部３７が、ニーモニック関数が引数として受け取った変数に対応するオペランドが制限を違反している場合に例外を発生させるコードを生成する（ステップＳ３２）。例えば、第２の生成部３７は、図２６で説明したコードT16を生成し、それをニーモニック関数の内部に記述する。

次に、第２の生成部３７が、ニーモニック関数が引数として受け取った変数の型を、MachineCodeEmitter関数の第２引数であるoperand型の配列に変換するコードを生成する（ステップＳ３３）。例えば、第２の生成部３７は、図２６で説明したコードT14をニーモニック関数の内部に記述する。

次いで、第２の生成部３７がMachineCodeEmitter関数を呼び出すコードを生成する（ステップＳ３４）。例えば、第２の生成部３７は、ニーモニック関数の内部に「MaschineCodeEmitter(nm,oplist)」というコードを記述する。これと共に、第２の生成部３７は、図２６のコードT12、T13等のような変数の宣言と代入を行う文もソースファイル３４に記述する。

続いて、第３の生成部３８が、MachineCodeEmitter関数が生成した機械語をメモリ３に書き込むコードを生成する（ステップＳ３５）。例えば、第３の生成部３８は、関数writeの引数にMachineCodeEmitter関数を記述した「write(MachineCodeEmitter(nm, oplist));」というコードをソースファイル３４に記述する。

そして、命令情報３３に含まれる全ての行に対してステップＳ３０～Ｓ３５の処理を行う。その後、出力部３９が、全てのニーモニック関数を含むソースファイル３４を記憶部３２に書き出す（ステップＳ３６）。

以上説明した本実施形態によれば、ステップＳ３２において、第２の生成部３７が、オペランドが制限を違反している場合に例外を発生させるコードT16（図２６参照）を生成する。そのため、開発者が早期にソースコード６６（図２７参照）の誤りに気付くことができ、開発者がデバッグするのに要する工数を減らすことができる。しかも、バグのあるプログラムをターゲットマシン１で無駄に実行する時間が減り、ターゲットマシン１のハードウェア資源の無駄な消費を改善できる。

なお、命令情報３３の「オペランドに課された制限」の種類としては、（１）「レジスタインデックスが特定の範囲内である」、（２）「即値が特定の範囲内である」、（３）「即値は整数である」、（４）「即値は小数である」等がある。この場合、制御部３１が取得する命令情報３３のデータ形式は、「オペランドに課された制限」の種類の番号（１）～（４）と、制限の上限値と、制限の下限値とを有する形式となる。

そして、（１）～（４）に対応するオペランドの違反をチェックするコードのテンプレートをあらかじめ用意しておき、ステップＳ３２では制御部３１が必要なテンプレートを参照すればよい。更に、制限の上限値と下限値とをチェックする必要があるケースでは、制御部３１がこれらの値をテンプレートに埋め込むことで例外を発生するコードを生成すればよい。

（第４実施形態）
本実施形態では、開発者がソースコードの誤りに気付くのを第３実施形態よりも容易にする。なお、本実施形態で使用するニーモニック関数は特に限定されないが、以下ではadd命令に対応したニーモニック関数を例にして説明をする。そこで、まずadd命令について説明する。

図２９（ａ）、（ｂ）は、add命令のアセンブリの文法について示す図である。
add命令には様々なオペランドをとる種類があるが、図２９（ａ）では「DSTレジスタ」と二つの「SRCレジスタ」とをオペランドとするadd命令について例示している。このadd命令は、二つの「SRCレジスタ」の内容同士を加算した値を「DSTレジスタ」に格納する命令である。

一方、図２９（ｂ）は、「DSTレジスタ」、「SRCレジスタ」、及び「即値」の三つのオペランドをとるadd命令を例示する図である。このadd命令は、「SRCレジスタ」の内容に「即値」を加算した値を「DSTレジスタ」に格納する命令である。

図３０は、本実施形態に係る命令情報３３を模式的に示す図である。
図３０に示すように、この命令情報３３には、第３実施形態に従って関数名、ニーモニック、オペランドの個数、オペランドの型、及びオペランドに課された制限の各々が対応付けられて格納される。なお、本実施形態では関数名をアルファベットの大文字で表すことにする。また、第１～第３実施形態と同様に、命令情報３３は開発者によって予め作成される。

図２９（ａ）、（ｂ）の二つのadd命令に対応して命令情報３３には二つの関数名「ADD」が格納されているため、制御部３１は、第３実施形態に従って二つのニーモニック関数ADDを生成することになる。第３実施形態で説明したように、引数の個数と関数名とが同一の複数のニーモニック関数が存在しても、それらの引数の型が異なればC++の文法上は両者を区別することができる。

以下では、命令情報３３の二行目に対応したニーモニック関数ADDを例にして説明する。命令情報３３によれば、このニーモニック関数ADDのオペランドの型は{Register型,Register型,Immediate型}である。また、第１オペランドと第２オペランドに課された制限は、いずれも「レジスタのインデックスの範囲が0～31」である。そして、第３オペランドに課された制限は、「即値の範囲が-1024～+1023」である。

図３１は、この命令情報３３に基づいて、第３実施形態に従って制御部３１が生成したニーモニック関数ADDのソースコードの一例を示す図である。

ここでは、ファイル名が「mnemonic.h」のソースファイル３４を制御部３１が生成し、そのソースファイル３４の２０行目からニーモニック関数ADDの記述が始まるものとする。なお、このソースファイル３４において第３実施形態で説明したのと同種のコードには第３実施形態と同じ符号を付し、その説明は省略する。

図３１に示すように、このソースファイル３４には、第３実施形態で説明したコードT11～T16が制御部３１によって生成される。このうち、コードT16は、ニーモニック関数ADDの引数が表すオペランドが命令情報３３における制限を違反している場合に例外を発生させるコードである。

更に、この例では、ソースファイル３４の２１行目に、制御部３１が関数「SET()」を呼び出すコードT17を生成する。

図３２は、関数「SET()」を定義するC++の疑似ソースコードを模式的に示す図である。

関数「SET()」の定義は、制御部３１によってソースファイル３４であるmnemonic.hの一部に記述される。この例では、制御部３１が、関数「SET()」を定義するためのコードT20～T22をソースファイル３４に生成する。

このうち、コードT20は、関数「SET()」のマクロを宣言するコードである。ここでは、関数「SET()」は、プリプロセッサによって関数「setCodeInfo(__FILE__, __LINE__, __func__)」に置換されるものとして定義される。

その関数「setCodeInfo」の引数に現れる変数「__FILE__」と「__LINE__」はC++における事前定義マクロであり、変数「__func__」はC++における事前定義識別子である。これらの変数は、コンパイル時にプリプロセッサによって所定の内容に変換される。例えば、「__FILE__」は、当該「__FILE__」が記述されたファイルのファイル名に変換される。また、「__LINE__」は、当該「__LINE__」が記述された行番号に変換される。そして、「__func__」は、当該「__func__」が記述された関数の関数名に変換される。

一方、コードT21は、char型のグローバル変数「g_filename」、「g_funcname」とint型のグローバル変数「g_line」とを定義するコードである。

そして、コードT22は、関数「setCodeInfo」の中身を定義するコードである。関数「setCodeInfo」は、三つの引数「filename」、「line」、及び「funcname」を受け取り、その各々をグローバル変数「g_filename」、「g_line」、及び「g_funcname」に代入する関数として定義される。

この例では、ソースファイル３４（図３１参照）のコードT17の位置においてプリプロセッサが「SET()」を「setCodeInfo(__FILE__, __LINE__, __func__)」に置換する。更に、プリプロセッサは、「__FILE__」を呼び出し元のソースファイル３４のファイル名である文字列「mnemonic.h」に置換し、「__LINE__」をソースファイル３４における関数「SET()」の行番号である「21」に置換する。また、プリプロセッサは、「__func__」を関数「SET()」の呼び出し元の関数であるニーモニック関数ADDの関数名「ADD」に置換する。

よって、ソースファイル３４をコンパイルして生成した実行可能プログラムを実行すると、コードT17に対応する部分の実行時に、変数「g_filename」に「mnemonic.h」が格納され、変数「g_funcname」に「ADD」が格納される。そして、変数「g_line」に「21」が格納される。

図３３は、開発者がC++で記述したアプリケーションプログラム用のソースファイル４１の疑似ソースコードを模式的に示す図である。ここではソースファイル４１のファイル名を「sample.cpp」とし、開発者がそのソースファイル４１にコードT25～T28を記述したものとする。

このうち、コードT25は、「reg0」、「reg1」、及び「imm0」の各変数を定義する文である。このうち、変数「reg0」及び「reg1」はReg型として定義される。また、変数「imm0」はImm型として定義される。

また、コードT26は、「reg0」、「reg1」、及び「imm0」の各変数のメンバに値を代入する文である。この例では、変数「reg0」のメンバ「regIndex」に「0」が代入され、変数「reg1」のメンバ「regIndex」に「1」が代入される。そして、変数「imm0」のメンバ「value」には「100000」が代入される。

一方、コードT27は、ニーモニック関数ADDを呼び出すと共に、その引数に上記の各変数「reg0」、「reg1」、「imm0」の内容を渡すコードである。ここでは、例外処理を行うために開発者がtry文の内部にコードT27を記述する。前述のように変数「imm0」には値「100000」が代入されているが、命令情報３３（図３０参照）によればニーモニック関数addの第３引数がとり得る値は-1024～+1023の範囲に制限されている。よって、このニーモニック関数ADDを実行するとコードT16（図３１参照）において例外が投げられることになる。

そして、コードT28は、このように例外が投げられたときに、各グローバル変数「g_filename」、「g_line」、及び「g_filename」の内容を標準出力に出力するためのコードである。この例では前述のように「g_filename」、「g_line」、及び「g_filename」の各々に「mnemonic.h」、「22」、及び「ADD」が格納されているため、これらが標準出力に出力されることになる。

このソースファイル４１から実行可能プログラム４４（図１３参照）を生成するには、第１実施形態で説明した図１３の処理に従ってプログラム群４２がビルドを行えばよい。

図３４は、このようにして生成した実行可能プログラム４４をターゲットマシン１（図１参照）で実行したときの標準出力への出力例を示す図である。

この例では、前述のようにソースファイル４１（図３３参照）におけるニーモニック関数ADDの第３引数が命令情報３３で規定される制限を満たしていない。よって、標準出力には、コードT16（図３１参照）における「Invalid immediate value of OP2 is passed to add mnemonic function.」というエラーメッセージ７４が出力される。更に、コードT28（図３３参照）における各グローバル変数「g_filename」、「g_line」、及び「g_funcname」の内容を示すメッセージ７５も標準出力に出力される。

開発者は、エラーメッセージ７４とメッセージ７５とに基づいて、自らが記述したプログラムのどこかでニーモニック関数ADDの引数を誤って指定していることに気づくことができる。

しかし、メッセージ７５には、誤りのあるソースファイル４１のファイル名である「sample.cpp」ではなく、ニーモニック関数ADDを定義しているソースファイル３４のファイル名「mnemonic.h」が出力されている。更に、メッセージ７５における行数や関数名にも、記述に誤りがあるソースファイル４１（sample.cpp）における行数や関数名ではなく、ソースファイル３４（mnemonic.h）の行数や関数名が出力される。

これではアプリケーションプログラム用のソースファイル４１（sample.cpp）のどこに間違いがあるのか開発者が分らず、アプリケーションプログラムのデバッグに長時間を要し、プログラム開発が非効率となってしまう。更に、コンパイラに対し複数のソースファイル４１を与えている場合、どのソースファイル４１の中のADD関数の使用で誤っているのかの判別も困難である。

この点に鑑み、本実施形態では以下のようにして開発者がデバッグするのを容易にする。

［機能構成］
図３５は、本実施形態に係る情報処理装置３０の機能構成図である。
なお、図３５において、第１～第３実施形態で説明したのと同じ要素にはこれらの実施形態におけるのと同じ符号を付し、以下ではその説明を省略する。

図３５に示すように、情報処理装置３０の制御部３１は、既述の第１～第３の生成部３６～３８と出力部３９の他に、第４の生成部８０と定義ファイル生成部８１とを有する。

図３６は、本実施形態において制御部３１が生成したニーモニック関数ADDのC++の疑似ソースコードを示す模式図である。ここでは、ファイル名が「mnemonic.h」というソースファイル３４を制御部３１が生成し、そのソースファイル３４に制御部３１がニーモニック関数ADDを生成するものとする。

なお、図３６において、第１～第３実施形態で説明したのと同種のコードには同じ符号を付し、以下ではその説明を省略する。

図３６に示すように、本実施形態では、第１実施形態と同様にして第１の生成部３６がニーモニック関数ADDの引数にコードT11を生成する。そのコードT11は、命令addの三つのオペランドに対応した各引数「OP0」、「OP1」、及び「OP2」の型を宣言するコードである。

また、第１の生成部３６は、ニーモニック関数ADDの複数の引数のうちの最初の位置にコードT18を記述する。コードT18は、「strFile」、「line」、及び「strFunc」の各変数の型を定義するコードである。これらの変数のうち、「strFile」は、ファイル名を格納するための文字列型の変数である。また、「line」は、ファイルにおける行数を格納するための整数型の変数である。そして、「strFunc」は、関数名を格納するための文字列型の変数である。なお、コードT18における「strFile」、「line」、及び「strFunc」の各変数を記述する順序は特に限定されない。第１の生成部３６は、これらの変数を任意の順序でコードT18に記述し得る。

そして、制御部３１は、第３実施形態と同様にしてその他のコードT12～T16をソースファイル３４に生成する。

更に、これらのコードT12～T16の他に、第４の生成部８０がソースファイル３４にコードT17を生成する。図３１の例と同様に、コードT17は、関数「SET()」を呼び出すコードである。また、第４の生成部８０は、ソースファイル３４の一部に関数「SET()」の処理を定義するコードを生成する。

図３７は、本実施形態において第４の生成部８０が生成する関数「SET()」のC++の疑似ソースコードの一例を示す図である。

図３２の例と異なり、本実施形態では、コードT20において関数「setCodeInfo」の引数に、ニーモニック関数ADDの引数である「strFile」、「line」、及び「strFunc」の各変数が渡される。

また、コードT21とT22の各々は、図３２の例と同様に関数「setCodeIndo」の各引数をグローバル変数「g_filename」、「g_funcname」、及び「g_line」の各々に代入するコードである。

一方、定義ファイル生成部８１（図３５）は、図３８に例示する定義ファイル８２を生成する処理部である。

図３８は、定義ファイル生成部８１が生成した定義ファイル８２の疑似ソースコードを示す模式図である。

図３８に示すように、定義ファイル８２は、「#define」で始まる複数のマクロを有する。これらのマクロは、ニーモニック関数の各々に対応するように定義ファイル生成部８１により生成される。そして、各マクロは、開発者が記述したアプリケーションプログラム用のソースファイルにおける各ニーモニック関数の引数に新たな変数を追加する指示をプリプロセッサに与えるマクロとなっている。これについて図３９のソースファイルを例にして説明する。

図３９は、本実施形態において開発者が記述したアプリケーションプログラム用のソースファイル４１のC++の疑似コードを示す図である。なお、図３９において、図３３で説明したのと同じコードには図３３におけるのと同じ符号を付し、以下ではその説明を省略する。

なお、このソースファイル４１においては、図３３の例とは異なり、開発者がニーモニック関数の関数名をアルファベットの小文字で記述するものとする。例えば、開発者は、１０１行目においてニーモニック関数を呼び出すコードT27を「add(reg0, reg1, imm0)」と記述する。そのコードT27におけるニーモニック関数addの第３引数「imm0」のメンバ「value」には、コードT26によって「100000」という値が代入されている。この値は、命令情報３３（図３０参照）における「-1024～1023」との制限を満たさない不適切な値である。

この場合の定義ファイル８２（図３８参照）の一行目のマクロ「#define add(...) ADD(__FILE__, __LINE__, __func__, __VA_ARGS__)」の動作について説明する。

まず、このマクロは、ソースファイル４１におけるニーモニック関数addの関数名「add」を「ADD」に置換するようにプリプロセッサに指示を出す。更に、このマクロは、ニーモニック関数addの引数の前に、新たな引数として「__FILE__」、「__LINE__」、及び「__func__」の各々を追加するようにプリプロセッサに指示を出す。なお、「__VA_ARGS__」は、ニーモニック関数addの引数が格納される可変長引数を示す事前定義識別子である。これにより、ソースファイル４１の１０１行目の記述「add(reg0, reg1, imm0);」は、プリプロセッサによって「ADD(__FILE__, __LINE__, __func__, reg0, reg1, imm0);」と置換されることになる。

前述のように、「__FILE__」、「__LINE__」、及び「__func__」の各々は、ファイル名、行番号、及び関数名に置換されるC++の事前定義マクロや事前定義識別子である。プリプロセッサは、これらの事前定義マクロや事前定義識別子の各々を、ファイル名、行番号、及び関数名に置換する。なお、ファイル名、及び行番号の各々は、ニーモニック関数addに関する関数情報の一例である。したがって、ニーモニック関数「ADD」の引数として、ニーモニック関数「add」が記述されたファイル名、行番号、関数名が渡されることになる。

定義ファイル生成部８１は、命令情報３３（図３０参照）を参照することによりこのような定義ファイル８２を生成し、それを記憶部３２に格納する。

例えば、定義ファイル生成部８１は、命令情報３３を一行ずつ読み込んで関数名を取得し、その関数名ごとにディレクティブを生成する。取得した関数名がSUBの場合には、定義ファイル生成部８１は、定義ファイル８２にディレクティブ「#define sub(...) SUB(__FILE__, __LINE__, __func__, __VA_ARGS__)」を生成することになる。

［開発環境］
図４０は、本実施形態に係る開発環境について示す模式図である。

なお、図４０において、第１実施形態の図１３で説明したのと同じ要素には第１実施形態におけるのと同じ符号を付し、以下ではその説明を省略する。

ここでは、情報処理装置３０の内部に開発環境を構築する場合を想定する。その場合、制御部３１がニーモニック関数のソースファイル３４と定義ファイル８２とを生成する。

一方、開発者は、C++を用いてアプリケーションプログラム用のソースファイル４１を作成する。以下では、開発者が図３９のようにファイル名が「sample.cpp」のソースファイル４１を作成し、そのソースファイル４１の１０１行目にニーモニック関数andを呼び出すコードT27を記述した場合について説明する。

そして、開発者の指示の下で、コンパイラ、アセンブラ、及びリンカのプログラム群４２がビルドを行う。ビルドに際しては、まずコンパイラに含まれるプリプロセッサがソースファイル３４、４１、４３と定義ファイル８２とを読み込む。なお、第１実施形態で説明したように、MachineCodeEmitter関数が記述されたソースファイル４３に代えて、機械語生成関数が記述されたバイナリ形式の実行ライブラリファイル４３ａを使用してもよい。

次いで、プリプロセッサが、定義ファイル８２に従って、ソースファイル４１の１０１行目の「add(reg0, reg1, imm0);」を「ADD(__FILE__, __LINE__, __func__, reg0, reg1, imm0);」に置換する。

このとき、プリプロセッサは、更に「__FILE__」、「__LINE__」、及び「__func__」の各々に、ソースファイル４１の１０１行目を実行した時点での内容を格納する。よって、「__FILE__」にはソースファイル４１のファイル名である「sample.cpp」が格納される。また、「__LINE__」には、ソースファイル４１においてニーモニック関数addが記述されている行番号の「101」が格納される。更に、「__func__」には、プリプロセッサによって置換された後の関数名である「func0」が格納される。

そして、「sample.cpp」、「101」、及び「func0」の各々の内容は、ソースファイル３４におけるニーモニック関数ADD（図３６参照）に、引数「strFile」、「line」、及び「strFunc」として渡される。この状態で当該ソースファイル３４のコードT17における関数「SET()」が実行されることにより、グローバル変数「g_filename」、「g_funcname」、及び「g_line」の各々への代入が実行される。これにより、本実施形態では、グローバル変数「g_filename」、「g_funcname」、及び「g_line」の各々に「sample.cpp」、「func0」、及び「101」が代入されることになる。

続いて、コンパイラがアセンブリファイルを生成し、更にアセンブラがそのアセンブリファイルを機械語の命令列に変換してオブジェクトファイルを生成する。

その後、リンカは、オブジェクトファイルと種々のライブラリとをリンクすることにより、プロセッサ２（図１参照）で実行可能なバイナリ形式の実行可能プログラム４４を生成する。

図４１は、このようにして生成した実行可能プログラム４４をターゲットマシン１（図１参照）で実行したときの標準出力への出力例を示す図である。

前述のように、この例ではソースファイル４１におけるニーモニック関数ADDの第３引数が命令情報３３で規定される制限を満たしていない。よって、標準出力には、コードT16（図３６参照）における「Invalid immediate value of OP2 is passed to add mnemonic function.」というエラーメッセージ８４が出力される。

更に、図３９のコードT28における各グローバル変数「g_filename」、「g_line」、及び「g_funcname」の内容を示すメッセージ８５も標準出力に出力される。

このとき、本実施形態では、定義ファイル８２（図３８参照）を使用したことで、前述のようにグローバル変数「g_filename」、「g_funcname」、及び「g_line」の各々内容は「sample.cpp」、「func0」、及び「101」となっている。

よって、ソースファイル４１（図３９参照）のコードT28を実行することにより、これらの内容を含む「file name:sample.cpp, line:101, function name: func0」というメッセージ８５が標準出力に出力される。そのメッセージ８５には、開発者が自ら記述したアプリケーションプログラム用のソースファイル４１のファイル名「sample.cpp」と、そのソースファイル４１でエラーが発生した行数「101」と、エラーが発生した関数名「func0」が含まれる。

よって、図３４の例と異なり、本実施形態では、エラーが発生したソースファイル４１のファイル名や、そのソースファイル４１でエラーが発生した位置を開発者が特定することができ、開発者が容易にデバッグをすることができる。その結果、デバッグに要する時間を短縮でき、プログラム開発を効率化することが可能となる。

なお、図４１におけるのと同様の実行結果を得るために、定義ファイル８２を使用せずに、例えば開発者が図４２に示すアプリケーション用のソースファイル４１を記述することも考えられる。

図４２は、本実施形態の別の例に係るソースファイル４１のC++の疑似ソースコードの例を示す模式図である。

図４２の例では、開発者が、ソースファイル４１にニーモニック関数ADDを記述すると共に、その引数に「__FILE__」、「__LINE__」、及び「__func__」の各事前定義マクロや事前定義識別子を自ら記述する。この場合は、ニーモニック関数ADDが記述されたソースファイル４１のファイル名が「__FILE__」に格納される。また、ソースファイル４１においてニーモニック関数ADDが記述されている行番号と、その記述を含む関数func0の関数名がそれぞれ「__LINE__」と「__func__」に格納される。

このような記述を行うことによっても図４１におけるのと同様の実行結果を得ることができる。しかし、関数の引数に「__FILE__」、「__LINE__」、及び「__func__」の各事前定義マクロと事前定義識別子を開発者が自ら記述するのは極めて煩わしく、更にタイプミスも発生する恐れもある。

これに対し、本実施形態では定義ファイル生成部８１が自動的に定義ファイル８２を生成するため、このような煩雑さを回避することができ、開発者の負担減を図ることができる。

なお、本実施形態では、図３６に示したように、ソースファイル３４においてニーモニック関数ADDの引数を示すコードT18をコードT11の前の位置に記述したが、順番を逆にしてコードT18をコードT11の後ろの位置に記述することも考えられる。この場合は、ニーモニック関数ADDに対応したマクロも、引数の順番を逆にして「#define add(...) ADD(__VA_ARGS__, __FILE__, __LINE__, __func__)」となる。しかし、このような記述では以下のような不都合が生じる。

図４３（ａ）、（ｂ）は、そのような不都合について模式的に示す図である。
命令セットに含まれる命令には、同一のニーモニックでオペランドの個数が異なる命令が存在する。ここで、add命令がそのような命令の一つであり、レジスタ型のオペランドを３個とるadd命令と、３個のレジスタ型と１個の即値型の合計４個のオペランドをとるadd命令が存在する場合を説明する。

レジスタ型のオペランドを３個とるadd命令は、第２、第３オペランドで指定されるレジスタの値を加算し、その結果を第1オペランドで指定されるレジスタに格納する命令とする。

一方、３個のレジスタ型と１個の即値型の合計４個のオペランドをとるadd命令は、第２、第３オペランドで指定されるレジスタの値を加算する命令とする。その加算の結果は、第３オペランドで指定される即値と加算され、その結果は第１オペランドに格納される。

この場合、前者のadd命令は、後者のadd命令の即値を「0」としたケースとして考えることができる。

一方、C++では、関数の定義において複数の引数を記述した場合であっても、省略時の値が明記された最後の引数を省略してその関数を呼び出すことができる。この特徴を利用して、本実施形態においては、オペランドの個数が異なる２種類のadd命令に対応した一つのニーモニック関数addの定義のみをソースファイル３４に記述する。

図４３（ａ）、（ｂ）における「void ADD(Reg x1, Reg x2, Reg x3, Imm imm=imm(0), string &strFile, size_t line, string &strFunc」が、このように２種類のadd命令の各々の引数を考慮したニーモニック関数ADDであったとする。

このニーモニック関数ADDにおいては、最初の四個の引数「x1」、「x2」、「x3」、「imm」がadd命令のオペランドに対応する。なお、前述のように、この例ではコードT11、T18の順序が図３６の例と逆になっている。

この場合に、コンパイルが成功する図４３（ａ）についてまず説明する。
図４３（ａ）の例では、アプリケーションプログラム用のソースファイル４１に開発者がコード「add(x1, x2, x3, imm)」を記述した場合を想定している。そのコード「add(x1, x2, x3, imm)」は、４個のオペランドをとるadd命令に対応したコードである。

この場合、定義ファイル８２におけるマクロ「#define add(...) ADD(__VA_ARGS__, __FILE__, __LINE__, __func__)」によって、プリプロセッサは上記のコードを「ADD(x1, x2, x3, imm, __FILE__, __LINE__, __func__)」に置換する。

そして、置換後のこのコードが、ソースファイル３４における関数ADDの定義を呼び出す。この場合、「ADD(x1, x2, x3, imm, __FILE__, __LINE__, __func__)」とソースファイル３４における関数ADDの７個の引数の各々の型は一致する。よって、コンパイルは成功することになる。

一方、図４３（ｂ）はコンパイルが失敗する場合を例示する模式図である。
ここでは、開発者が、３個のオペランドをとるadd命令に対応した３個の引数を含むコード「add(x1, x2, x3)」をソースファイル４１に記述した場合を想定している。この場合は、定義ファイル８２におけるマクロ「#define add(...) ADD(__VA_ARGS__, __FILE__, __LINE__, __func__)」によって、プリプロセッサは上記のコードを「ADD(x1, x2, x3, __FILE__, __LINE__, __func__)」に置換する。そして、置換後のこのコードが、ソースファイル３４における関数ADDの定義を呼び出す。

しかし、「ADD(x1, x2, x3, __FILE__, __LINE__, __func__)」の第６引数「__func__」は文字列型であるのに対し、ソースファイル３４における関数ADDの第６引数「line」は整数型である。よって、呼び出し側と呼び出される側の各々の引数の型が一致せず、コンパイルは成功しない。

このような不都合を回避するために、図３６に示したように、第１の生成部３６が、ニーモニック関数ADDの複数の引数のうちの最初の位置に、ファイル名等の関数情報を記述したコードT18を記述するのが好ましい。

例えば、図４３（ａ）のソースファイル３４においてコードT11、T18の順番を入れ替え、本実施形態のようにコードT11よりも前の位置にコードT18を記述し、かつソースファイル４１に「add(x1, x2, x3)」と記述した場合を考える。この場合は、定義ファイル８２のマクロ「#define add(..) ADD(__FILE__, __LINE__, __func__, __VA_ARGS__)」により、プリプロセッサが上記のコードを「ADD(__FILE__, __LINE__, __func__, x1, x2, x3)」に置換する。コンパイラは、このように６個の引数を持つADD関数の呼び出しを、ソースファイル３４における７個の引数を持つ関数ADDの定義において７個目の引数を省略した呼び出しであることをC++の文法に即して認識できる。

また、省略されていない６個の引数はそれぞれ、文字列型、整数型、文字列型、レジスタ型、レジスタ型、レジスタ型であり、これはソースファイル３４で定義されているADD関数の最初の６個の引数の型に一致している。よって、上記の記述「add(x1, x2, x3)」は、エラーなくコンパイルすることができる。

［処理の流れ］
次に、本実施形態に係る定義ファイルの生成方法について説明する。

図４４は、本実施形態に係る定義ファイルの生成方法について示すフローチャートである。

まず、定義ファイル生成部８１が、命令情報３３（図３０参照）から関数名を取得し（ステップＳ４０）、その関数名に対応したマクロ#defineを生成する（ステップＳ４１）。例えば、定義ファイル生成部８１が命令情報３３の１行目の関数名「ADD」を取得した場合を考える。この場合は、定義ファイル生成部８１は、「#define add(...) ADD(__FILE__, __LINE__, __func__, __VA_ARGS__)」というマクロを生成する。

そして、定義ファイル生成部８１は、命令情報３３（図３０参照）の各行に対してステップＳ４０とステップＳ４１とを繰り返す。なお、上記のマクロ「#define add(...) ADD(__FILE__, __LINE__, __func__, __VA_ARGS__)」は、置換前の関数名「add」と置換後の関数名「ADD」を除き、全ての関数名について同じ書式である。よって、関数名が同一の場合にはマクロも同一となるため、関数名が重複している場合には、定義ファイル生成部８１は、命令情報３３の次の関数名からステップＳ４０とステップＳ４１とを繰り返す。

その後、定義ファイル生成部８１が、命令情報３３における全ての関数名に対応したマクロが記述された定義ファイル８２を記憶部３２に書き出す（ステップＳ４２）。

以上により、本実施形態に係る定義ファイルの生成方法の基本ステップを終了する。

（ハードウェア構成）
次に、第１～第４実施形態に係る情報処理装置３０のハードウェア構成について説明する。

図４５は、第１～第４実施形態に係る情報処理装置３０のハードウェア構成図である。

図４５に示すように、情報処理装置３０は、記憶装置３０ａ、メモリ３０ｂ、プロセッサ３０ｃ、通信インターフェース３０ｄ、表示装置３０ｅ、及び入力装置３０ｆを有する。これらの各部は、バス３０ｇにより相互に接続される。

このうち、記憶装置３０ａは、HDDやSSD(Solid State Drive)等の不揮発性のストレージデバイスであり、本実施形態に係る関数生成プログラム９０を記憶する。

なお、関数生成プログラム９０をコンピュータが読み取り可能な記録媒体３０ｈに記録させておき、プロセッサ３０ｃに記録媒体３０ｈの関数生成プログラム９０を読み取らせるようにしてもよい。

そのような記録媒体３０ｈとしては、例えばCD-ROM(Compact Disc - Read Only Memory)、DVD(Digital Versatile Disc)、及びUSB(Universal Serial Bus)メモリ等の物理的な可搬型記録媒体がある。また、フラッシュメモリ等の半導体メモリやハードディスクドライブを記録媒体３０ｈとして使用してもよい。これらの記録媒体３０ｈは、物理的な形態を持たない搬送波のような一時的な媒体ではない。

更に、公衆回線、インターネット、及びLAN(Local Area Network)等に接続された装置に関数生成プログラム９０を記憶させておき、プロセッサ３０ｃがその関数生成プログラム９０を読み出して実行するようにしてもよい。

一方、メモリ３０ｂは、DRAM等のようにデータを一時的に記憶するハードウェアであって、その上に前述の関数生成プログラム９０が展開される。

プロセッサ３０ｃは、情報処理装置３０の各部を制御したり、メモリ３０ｂと協働して関数生成プログラム９０を実行したりするCPU(Central Processing Unit)やGPU(Graphical Processing Unit)等のハードウェアである。

このようにメモリ３０ｂとプロセッサ３０ｃとが協働して関数生成プログラム９０を実行することにより、図１１の第１の生成部３６、第２の生成部３７、第３の生成部３８、及び出力部３９を備えた制御部３１が実現される。また、図３５の第４の生成部８０と定義ファイル生成部８１も、メモリ３０ｂとプロセッサ３０ｃとが協働して関数生成プログラム９０を実行することにより実現される。また、図１１と図３５の各々の記憶部３２は、記憶装置３０ａとメモリ３０ｂによって実現される。

更に、通信インターフェース３０ｄは、情報処理装置３０をLAN等のネットワークに接続するためのインターフェースである。

そして、表示装置３０ｅは、液晶表示装置等のハードウェアであって、開発者に種々の情報の入力を促すプロンプトや、コンパイル時のエラーメッセージ等を表示する。また、入力装置３０ｆは、キーボードやマウス等のハードウェアである。例えば、開発者は、入力装置３０ｆを操作することにより、情報処理装置３０に対してコンパイルの実行の指示を出すことになる。

１…ターゲットマシン、２…プロセッサ、３…メモリ、４…計算コア、５…レジスタファイル、３０…情報処理装置、３０ａ…記憶装置、３０ｂ…メモリ、３０ｃ…プロセッサ、３０ｄ…通信インターフェース、３０ｅ…表示装置、３０ｆ…入力装置、３０ｇ…バス、３０ｈ…記録媒体、３１…制御部、３２…記憶部、３３…命令情報、３４…ニーモニック関数のソースファイル、３６…第１の生成部、３７…第２の生成部、３８…第３の生成部、３９…出力部、８０…第４の生成部、８１…定義ファイル生成部。

Claims (12)

1. 命令に関する命令情報を記憶した記憶部を参照して、前記命令に対応した関数であって、前記命令のオペランドを表す引数を受け取る第１の関数を生成する処理と、
   前記引数が表す前記オペランドに対して前記命令が行う処理を表す機械語を返す第２の関数を呼び出すコードを前記第１の関数の内部に生成する処理と、
   前記機械語をメモリに書き込むコードを前記第１の関数の内部に生成する処理と、
   をコンピュータに実行させるための関数生成プログラム。
2. 前記命令情報は、前記オペランドの個数と前記命令の名前とを対応付けた情報であり、
   前記記憶部を参照して、前記命令の名前と同じ関数名を前記第１の関数に付ける処理と、
   前記記憶部を参照して、前記個数に等しい個数の前記引数を宣言するコードを生成する処理とを更に有することを特徴とする請求項１に記載の関数生成プログラム。
3. 前記命令情報は、前記オペランドの種類を表す型と前記命令とを対応付けた情報であり、
   前記記憶部を参照して、前記引数の型を前記オペランドの前記型に宣言するコードを生成する処理と、
   前記第１の関数が前記引数として受け取った変数を、前記第２の関数の引数の型に変換して該第２の関数に渡すコードを生成する処理とを更に有することを特徴とする請求項１に記載の関数生成プログラム。
4. 前記命令情報は、前記オペランドの種類を表す型、前記命令、及び前記第１の関数の関数名を対応付けた情報であり、
   前記命令情報に、前記関数名が同一であり、かつ、前記オペランドの型が異なる複数の相異なる前記命令が存在することを特徴とする請求項３に記載の関数生成プログラム。
5. 前記命令情報は、前記オペランドに課された制限を前記命令に対応付けた情報であり、
   前記記憶部を参照して、前記引数に対応する前記オペランドが前記制限を違反している場合に例外を発生させるコードを生成する処理を更に有することを特徴とする請求項１に記載の関数生成プログラム。
6. 前記第１の関数を呼び出すようにソースファイルに記述されたコードに引数を追加して、追加した前記引数に、前記ソースファイルにおける前記第１の関数に関する関数情報を格納する指示をプリプロセッサに与える定義ファイルを生成する処理を更に有することを特徴とする請求項５に記載の関数生成プログラム。
7. 前記命令情報は、前記命令、前記制限、及び前記第１の関数の関数名の各々を対応付けた情報であり、
   前記定義ファイルを生成する処理は、前記命令情報を記憶した前記記憶部を参照して、前記指示を行うマクロを前記関数名ごとに生成することにより行われることを特徴とする請求項６に記載の関数生成プログラム。
8. 前記関数情報が格納される前記引数を、前記第１の関数の複数の引数のうちの最初の位置に生成する処理を更に有することを特徴とする請求項７に記載の関数生成プログラム。
9. 前記関数情報は、前記ソースファイルのファイル名、前記ソースファイルにおいて前記第１の関数を呼び出す前記コードが記述された行番号、及び前記第１の関数の関数名のいずれかであることを特徴とする請求項６に記載の関数生成プログラム。
10. 前記第１の関数を生成する処理において、マクロとして前記第１の関数を生成することを特徴とする請求項１に記載の関数生成プログラム。
11. 命令に関する命令情報を記憶した記憶部を参照して、前記命令に対応した関数であって、前記命令のオペランドを表す引数を受け取る第１の関数を生成する処理と、
    前記引数が表す前記オペランドに対して前記命令が行う処理を表す機械語を返す第２の関数を呼び出すコードを前記第１の関数の内部に生成する処理と、
    前記機械語をメモリに書き込むコードを前記第１の関数の内部に生成する処理と、
    をコンピュータが実行することを特徴とする関数生成方法。
12. 命令に関する命令情報を記憶した記憶部を参照して、前記命令に対応した関数であって、前記命令のオペランドを表す引数を受け取る第１の関数を生成する第１の生成部と、
    前記引数が表す前記オペランドに対して前記命令が行う処理を表す機械語を返す第２の関数を呼び出すコードを前記第１の関数の内部に生成する第２の生成部と、
    前記機械語をメモリに書き込むコードを前記第１の関数の内部に生成する第３の生成部と、
    を有することを特徴とする情報処理装置。
    

Images