(57)【要約】  本明細書に記載したように、ソースコードファイルの中間表現を使用して、ソースコードのオブジェクトコードを生成する前に例外処理制御フローを明示的に表すことができる。さらに本明細書に記載したように、単一組の均一の中間表現の命令を、異なる複数のプログラミング言語に関連する異なる複数の例外処理機構を表すために使用することができる。例外（１０）処理命令の中間形式は、ソースコードファイルの中間言語表現を変換することによって生成することができる。異なる複数の中間言語内のソースコードの表現を、単一組の均一の中間表現の命令に変換することができる。次いで例外処理命令の中間形式を、ソフトウェア開発ツールによってコード生成、コード最適化、コード解析などのタスクに使用することができる。したがって、コード最適化、解析、および生成のための同じ方法を、異なる複数の言語の中間表現に使用することができる。【特許請求の範囲】
【請求項１】
例外処理構成体を備えるソフトウェアの均一の中間表現を処理する方法であって、
例外処理構成体を備えるソフトウェアの前記均一の中間表現を読み取ることであって、前記均一の中間表現は前記ソフトウェアの例外処理制御フローを明示的に表すことと、
前記均一の中間表現に基づいて、前記例外処理制御フローを実行する前記ソフトウェアのコンピュータ読取可能なバージョンを生成することと
を備えることを特徴とする方法。
【請求項２】
前記均一の中間表現は、
終了処理コードブロックへの制御の移行を表す第１の命令と、
前記終了処理コードブロックへの制御の移行の受け入れを表す第２の命令と、
前記終了処理コードブロックからの制御の移行を表す第３の命令と
を備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記終了処理コードブロックは、オブジェクトの解体子に関連するコードを備えることを特徴とする請求項２に記載の方法。
【請求項４】
前記終了処理ブロックは、式の一時オブジェクトの解体子に関連するコードを備えることを特徴とする請求項２に記載の方法。
【請求項５】
前記第２の命令の宛先オペランドは前記第３の命令のソースオペランドと同じであることを特徴とする請求項２に記載の方法。
【請求項６】
前記終了処理コードブロックへの制御の明示的な移行を表す前記第１の命令は、
前記終了処理ブロックへの制御の移行を表すために使用される前記終了処理コードブロックの先頭を示すラベルと、
前記終了処理コードブロックを終了した後の制御の移行の継続を示すラベルと
をさらに備えることを特徴とする請求項２に記載の方法。
【請求項７】
前記終了処理コードブロックへの制御の移行の受け入れを表す前記第２の命令の前に前記終了処理コードブロックの先頭を示すラベルがあり、前記終了処理ブロックへの制御の移行は前記ラベルの使用によって示されることを特徴とする請求項２に記載の方法。
【請求項８】
前記終了処理コードブロックからの制御の移行を表す前記第３の命令は、前記終了処理コードブロックへのエントリが明示的なものであったか、例外に起因するかに基づいて、前記終了処理コードブロックからの制御の移行の異なる継続を示すフィールドを備えることを特徴とする請求項２に記載の方法。
【請求項９】
前記均一の中間表現は、
例外を受け取って、前記例外に関連する例外オブジェクトを戻す第１の命令と、
前記例外オブジェクトの型値に基づいて前記例外のハンドラを指定する第２の命令と
を備えることを特徴とする請求項１に記載の方法。
【請求項１０】
前記ハンドラを指定する前記第２の命令は、
前記例外オブジェクトの前記型値を示す少なくとも１つのブールソースオペランドと、
前記ブールソ―スオペランドが真である場合の制御フローの移る先である前記ハンドラに関連するコードブロックに先行するラベルを示す少なくとも１つのソースオペランドと、
前記ブールソ―スオペランドが偽である場合の制御フローの移る先である継続に関連するコードブロックに先行するラベルを示す少なくとも１つのソースオペランドと
を備えることを特徴とする請求項９に記載の方法。
【請求項１１】
前記均一の中間表現は、
例外に関連する例外オブジェクトの型値に基づいて前記例外のハンドラを指定する命令を含み、前記命令の宛先オペランドは、予め定められた例外オブジェクトを含み、前記命令の第１のソースオペランドは前記ハンドラに関連するコードブロックを示すラベルを含み、第２のソースオペランドは継続に関連するコードブロックを示すラベルを備える
ことを特徴とする請求項１に記載の方法。
【請求項１２】
前記命令は、前記例外オブジェクトの前記型値を前記予め定められた例外オブジェクトの型値と比較し、一致がある場合、前記ハンドララベルに関連する前記コードブロックに制御フローを渡し、一致がない場合、前記継続ラベルに関連する前記コードブロックに制御フローを渡すよう動作可能であることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記均一の中間表現は、
例外試行領域へのエントリを示す第１の命令と、
前記例外に関連する型値に基づいて例外処理の複数の制御フローパスのうちの１つを選択する第２の命令であって、選択に使用可能な前記複数の制御フローパスは前記例外を引き起こす命令の実行の再開に関連するパスを含む第２の命令と
を備えることを特徴とする請求項１に記載の方法。
【請求項１４】
例外処理の前記複数の制御フローのうちの１つを選択する前記第２の命令は、
前記例外の前記型値を示すオペランドと、
ハンドラコードブロックを示すラベルオペランドと、
継続コードブロックを示すラベルオペランドと、
前記例外を引き起こす命令を示すラベルオペランドと
を備えることを特徴とする請求項１３に記載の方法。
【請求項１５】
複数のソースコード言語の均一の例外処理中間表現を実装するシステムであって、
ソースコードファイルの中間言語表現を取得し、前記中間言語表現に基づいて前記ソースコードの例外処理構成体の均一の中間表現を生成する中間言語リーダ
を備え、前記均一の中間表現は、前記ソースコードの例外処理制御フローを明示的に表す
ことを特徴とするシステム。
【請求項１６】
前記均一の中間表現に基づいてオブジェクトコードを生成するコンパイラをさらに備えることを特徴とする請求項１５に記載のシステム。
【請求項１７】
前記例外処理構成体の前記均一の中間表現は、終了処理コードブロックへの制御の明示的な移行を表す第１の命令と、前記終了処理コードブロックへの制御の移行の受け入れを表す第２の命令と、前記終了処理コードブロックからの制御の移行を表す第３の命令とを備えることを特徴とする請求項１５に記載のシステム。
【請求項１８】
前記第２の命令の宛先オペランドは前記第３の命令のソースオペランドと同じであることを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記終了処理コードブロックは、オブジェクトの解体子に関連するコードを備えることを特徴とする請求項１７に記載のシステム。
【請求項２０】
前記終了処理ブロックは、式の一時オブジェクトの解体子に関連するコードを備えることを特徴とする請求項１７に記載のシステム。
【請求項２１】
前記終了処理コードブロックへの制御の明示的な移行を表す前記第１の命令は、前記終了処理コードブロックの前記先頭を示すラベルと、前記終了処理コードブロックを終了した後の制御の移行の継続を示すラベルとをさらに備えることを特徴とする請求項１７に記載のシステム。
【請求項２２】
前記終了処理コードブロックへの制御の移行の受け入れを表す前記第２の命令の前に前記終了処理コードブロックの前記先頭を示すラベルがあり、前記終了処理ブロックへの制御の移行は前記ラベルの使用によって示されることを特徴とする請求項１７に記載のシステム。
【請求項２３】
前記終了処理コードブロックからの制御の移行を表す前記第３の命令は、前記終了処理コードブロックへのエントリが明示的なものであったか、例外に起因するかに基づいて、前記終了処理コードブロックからの制御の移行の異なる継続を示すフィールドを備えることを特徴とする請求項１７に記載のシステム。
【請求項２４】
明示的なエントリの後の前記終了処理コードブロックからの制御の移行の前記継続は、前記第１の命令によって指定された継続に一致することを特徴とする請求項２３に記載のシステム。
【請求項２５】
前記例外処理構成体の前記均一の中間表現は、例外を受け取って、前記例外に関連する例外オブジェクトを戻す第１の命令と、前記例外オブジェクトの型値に基づいて前記例外のハンドラを指定する第２の命令とを備えることを特徴とする請求項１５に記載のシステム。
【請求項２６】
前記ハンドラを指定する前記第２の命令は、
前記例外オブジェクトの前記型値を示す少なくとも１つのブールソースオペランドと、
前記ブールソースオペランドが真である場合の制御フローの移る先である前記ハンドラに関連するコードブロックに先行するラベルを示す少なくとも１つのソースオペランドと、
前記ブールソ―スオペランドが偽である場合の制御フローの移る先である継続に関連するコードブロックに先行するラベルを示す少なくとも１つのソースオペランドと
を備えることを特徴とする請求項２５に記載のシステム。
【請求項２７】
前記例外処理構成体の前記均一の中間表現は、前記例外に関連する例外オブジェクトの型値に基づいて例外のハンドラを指定する少なくとも１つの命令を備え、前記命令の宛先オペランドは予め定められた例外オブジェクトを備え、前記命令の第１のソースオペランドは前記ハンドラに関連するコードブロックを示すラベルを備え、第２のソースオペランドは継続に関連するコードブロックを示すラベルを備えることを特徴とする請求項１５に記載のシステム。
【請求項２８】
前記命令は、前記例外オブジェクトの前記型値を前記予め定められた例外オブジェクトの型値と比較し、一致がある場合、前記ハンドララベルに関連する前記コードブロックに制御フローを渡し、一致がない場合、前記継続ラベルに関連する前記コードブロックに制御フローを渡すよう動作可能であることを特徴とする請求項２７に記載のシステム。
【請求項２９】
前記例外処理構成体の前記均一の中間表現は、例外試行領域へのエントリを示す第１の命令と、前記例外に関連する型値に基づいて例外処理の複数の制御フローパスのうちの１つを選択する第２の命令とを備え、選択に使用可能な前記複数の制御フローパスは、前記例外を引き起こす命令の実行の再開に関連するパスを含むことを特徴とする請求項１５に記載のシステム。
【請求項３０】
例外処理の前記制御フローパスを選択する前記第２の命令は、
前記例外の前記型値を示すオペランドと、
ハンドラコードブロックを示すラベルオペランドと、
継続コードブロックを示すラベルオペランドと、
前記例外を引き起こす命令を示すラベルオペランドと
を備えることを特徴とする請求項２９に記載のシステム。
【請求項３１】
前記例外試行領域へのエントリを示す前記第１の命令のハンドラは、前記例外を引き起こす命令のハンドラと同じであることを特徴とする請求項３０に記載のシステム。
【請求項３２】
ソースコードの例外処理構成体の中間表現を格納するコンピュータ読み取り可能な記録媒体であって、例外処理構成体の前記中間表現は、
終了処理コードブロックへの制御の明示的な移行を表す第１の命令と、
前記終了処理コードブロックへの制御の移行の受け入れを表す第２の命令と、
前記終了処理コードブロックからの制御の移行を表す第３の命令と
を備えることを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項３３】
前記終了処理コードブロックへの制御の明示的な移行を表す前記第１の命令は、前記終了処理コードブロックの前記先頭を示すラベルと、前記終了処理コードブロックを終了した後の制御の移行の継続を示すラベルとをさらに備えることを特徴とする請求項３２に記載のコンピュータ読み取り可能な記録媒体。
【請求項３４】
前記終了処理コードブロックへの制御の移行の受け入れを表す前記第２の命令の前に前記終了処理コードブロックの前記先頭を示すラベルがあり、前記終了処理ブロックへの制御の移行は前記ラベルの使用によって示されることを特徴とする請求項３２に記載のコンピュータ読み取り可能な記録媒体。
【請求項３５】
制御の前記移行は明示的であることを特徴とする請求項３４に記載のコンピュータ可読記憶媒体。
【請求項３６】
制御の前記移行は例外に起因することを特徴とする請求項３４に記載のコンピュータ可読記憶媒体。
【請求項３７】
前記終了処理コードブロックからの制御の移行を表す前記第３の命令は、前記終了処理コードブロックへのエントリが明示的なものであったか、例外に起因するかに基づいて、前記終了処理コードブロックからの制御の移行の異なる継続を示すフィールドを備えることを特徴とする請求項３２に記載のコンピュータ読み取り可能な記録媒体。
【請求項３８】
明示的なエントリの後の前記終了処理コードブロックからの制御の移行の前記継続は、前記第１の命令によって指定された継続に一致することを特徴とする請求項３７に記載のコンピュータ読み取り可能な記録媒体。
【請求項３９】
前記第２の命令の宛先オペランドは前記第３の命令のソースオペランドと同じであることを特徴とする請求項３２に記載のコンピュータ読み取り可能な記録媒体。
【請求項４０】
前記終了処理ブロックへの制御フローは、関連の１組のＦＩＮＡＬ命令、ＦＩＮＡＬＬＹ命令、およびＥＮＤＦＩＮＡＬＬＹ命令によって表されることを特徴とする請求項３２に記載のコンピュータ読み取り可能な記録媒体。
【請求項４１】
前記終了処理コードブロックは、オブジェクトの解体子に関連するコードを備えることを特徴とする請求項３２に記載のコンピュータ読み取り可能な記録媒体。
【請求項４２】
前記終了処理コードブロックは、式の一時オブジェクトの解体子に関連するコードを備えることを特徴とする請求項３２に記載のコンピュータ読み取り可能な記録媒体。
【請求項４３】
前記式の一時オブジェクトは、真の条件で作成され、前記制御は、同じ真の条件で前記終了処理コードブロックに移行されることを特徴とする請求項４２に記載のコンピュータ読み取り可能な記録媒体。
【請求項４４】
ソースコードの例外処理構成体の中間表現を格納するコンピュータ読み取り可能な記録媒体であって、例外処理構成体の前記中間表現は、
例外を受け取って、前記例外に関連する例外オブジェクトを戻す第１の命令と、
前記例外オブジェクトの型値に基づいて前記例外のハンドラを指定する第２の命令と
を備えることを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項４５】
前記ハンドラを指定する前記第２の命令は、
前記例外オブジェクトの前記型値を示す少なくとも１つのブールソースオペランドと、
前記ブールソ―スオペランドが真である場合の制御フローの移る先である前記ハンドラに関連するコードブロックに先行するラベルを示す少なくとも１つのソースオペランドと、
前記ブールソ―スオペランドが偽である場合の制御フローの移る先である継続に関連するコードブロックに先行するラベルを示す少なくとも１つのソースオペランドと
を備えることを特徴とする請求項４４に記載のコンピュータ読み取り可能な記録媒体。
【請求項４６】
前記継続コードブロックは別のフィルタに関連することを特徴とする請求項４５に記載のコンピュータ読み取り可能な記録媒体。
【請求項４７】
前記継続関連のコードブロックはｕｎｗｉｎｄ命令を備えることを特徴とする請求項４５に記載のコンピュータ読み取り可能な記録媒体。
【請求項４８】
ソースコードの例外処理構成体の中間表現を格納するコンピュータ読み取り可能な記録媒体であって、例外処理構成体の前記中間表現は、
例外に関連する例外オブジェクトの型値に基づいて前記例外のハンドラを指定する命令を備え、前記命令の宛先オペランドは予め定められた例外オブジェクトを備え、前記命令の第１のソースオペランドは前記ハンドラに関連するコードブロックを示すラベルを備え、第２のソースオペランドは継続に関連するコードブロックを示すラベルを備える
ことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項４９】
前記命令は、前記例外オブジェクトの前記型値を前記予め定められた例外オブジェクトの型値と比較し、一致がある場合、前記ハンドララベルに関連する前記コードブロックに制御フローを渡し、一致がない場合、前記継続ラベルに関連する前記コードブロックに制御フローを渡すよう動作可能であることを特徴とする請求項４８に記載のコンピュータ読み取り可能な記録媒体。
【請求項５０】
ソースコードの例外処理構成体の中間表現を格納するコンピュータ読み取り可能な記録媒体であって、例外処理構成体の前記中間表現は、
例外試行領域へのエントリを示す第１の命令と、
前記例外に関連する型値に基づいて例外処理の複数の制御フローパスのうちの１つを選択する第２の命令であって、選択に使用可能な前記複数の制御フローパスは前記例外を引き起こす命令の実行の再開に関連するパスを含む第２の命令と
を含むことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項５１】
例外処理の前記制御フローパスを選択する前記第２の命令は、
前記例外の前記型値を示すオペランドと、
ハンドラコードブロックを示すラベルオペランドと、
継続コードブロックを示すラベルオペランドと、
前記例外を引き起こす命令を示すラベルオペランドと
を備えることを特徴とする請求項５０に記載のコンピュータ読み取り可能な記録媒体。
【請求項５２】
前記例外試行領域へのエントリを示す前記第１の命令のハンドラは、前記例外を引き起こす命令のハンドラと同じであることを特徴とする請求項５０に記載のコンピュータ読み取り可能な記録媒体。
【請求項５３】
複数のソースコード言語の均一の例外処理中間表現を実装するシステムであって、
ソースコードファイルの中間言語表現を読み取り、前記中間言語表現に基づいて前記ソースコードの例外処理構成体の均一の中間表現を生成する手段
を備え、前記均一の中間表現は、前記ソースコードの例外処理制御フローを明示的に表す
ことを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術分野は、コンパイラコンピュータプログラムの構成要素に関する。より詳細には、本分野は、プログラムをコンパイルするための例外処理構成体（ｃｏｎｓｔｒｕｃｔ）の中間表現に関する。
【背景技術】
【０００２】
一般的に言えば、変換プログラムは、１つのコンピュータプログラミング言語で書かれたプログラムをその入力として受信し、別のプログラミング言語のプログラムをその出力として生成するコンピュータプログラムである。高水準ソース言語（Ｃ＋＋、ＪＡＶＡ（登録商標）など）を入力として受信し、アセンブリ言語やマシン語などの低水準言語を出力として生成する変換プログラムは、より具体的にはコンパイラと呼ばれることがある。コンパイラプログラム内の変換のプロセスは、一般に複数の段階から成る。図１は、コンパイラの複数の段階のこうした１つの内訳を示すフローチャートを示している。１１０で、ソースコード内のソースプログラム表現が受信される。次いで１２０で、字句解析器（ｌｅｘｉｃａｌ  ａｎａｌｙｚｅｒ）は、ソースコードの文字をトークンと呼ばれる論理グループに分ける。トークンを、ＩＦやＷＨＩＬＥなどソース言語の構文内のキーワード、＋や−などの演算子、識別子および句読記号とすることができる。１３０で、構文解析器は、トークンを式やステートメントなどの統語構造にまとめる。１４０で、例外処理構成体を含むソースコードの中間表現（ＩＲ）が生成されて、１５０でのコード最適化、次いで１６０でのコード生成などのコンパイラバックエンド操作が容易になる。コンパイラプロセス内に複数の中間表現があり得る。１５０のコード最適化段階中、１４０で生成された中間表現を向上させることに様々な技術が向けられ、したがって最終的なオブジェクトコードがより速く稼働し、あまりメモリを使用しないようにすることができる。１６０の最終段階中、コード生成器は、プロセッサによって実行されるようにターゲットプログラム（オブジェクトコード）１７０を生成する。
【０００３】
例外処理は、ソースプログラム内の欠陥が検出されたときに呼び出される。既存のコンパイラフレームワークにおいて、ソースプログラム内の例外処理構成体は、中間表現のメイン制御フローとは別に処理される。従来、例外処理構成体は、中間表現の制御フローにおいて明示的に表されない。よく知られている１つの技術において、例外処理構成体が検出されるソースコード内の領域は、メイン制御フローから区切られており、したがってメイン制御フロートと同じコード最適化技術の対象とならない。さらに別の方法において、例外処理構成体は、メイン制御フローの外部のテーブル内で捕捉され、コンパイラバックエンドは、それらを別々に処理する。したがって、ソースコードの残りと同じコード最適化およびコード生成技術（すなわちコンパイラバックエンド）を利用できるようにするために、こうした構成体をメイン制御フロー内で明示的に表現できるようにする例外処理構成体の中間表現が必要である。
【０００４】
また、従来、中間表現はソース言語に固有であった。したがって、コンパイラは、各表現に関連付けられているソース言語の特定の例外処理モデルを認識していなければならない。我々の目的上、これらの例外処理モデルを、一般に４つの特徴によって特徴付けることができる。第１の特徴は、例外が同期であるか非同期であるかを決定する。同期の例外は、それをスローし、処理する制御のスレッドのアクションに関連付けられている。この状況において、例外は、常にスレッドの命令に関連付けられている。言い換えれば、例外処理アクションは、ある状態が失敗したとき、命令によって呼び出される。しかし、非同期の例外は、それをスローし、処理した可能性のあるスレッド以外の制御のスレッドに注入される。これは、Ｍｉｃｒｏｓｏｆｔ（登録商標）  ＣＬＲ（Ｃｏｍｍｏｎ  Ｌａｎｇｕａｇｅ  Ｒｕｎｔｉｍｅ）では、システムＡＰＩを介してスレッドを中止することによって引き起こされる可能性がある。こうした例外は、特定の命令に関連付けられない。この効果は、同期ポイントと呼ばれるある適したポイントでスレッドにおいて例外を発生させることである。
【０００５】
第２に、ある例外は、例外を引き起こした命令を終了または再開することができる。終了例外（ｔｅｒｍｉｎａｔｉｎｇ  ｅｘｃｅｐｔｉｏｎ）の場合、命令が終了し、フィルタ、ハンドラ、または終了処理（ｆｉｎａｌｉｚａｔｉｏｎ）アクションが開始する。しかし、再開モデルの場合、何らかの処理アクションが実行された後で、違反命令（ｏｆｆｅｎｄｉｎｇ  ｉｎｓｔｒｕｃｔｉｏｎ）を自動的に再開することができる。Ｃ／Ｃ＋＋の構造化例外処理（ＳＥＨ：Ｓｔｒｕｃｔｕｒｅｄ  Ｅｘｃｅｐｔｉｏｎ  Ｈａｎｄｌｉｎｇ）構成体は、このカテゴリに入る。これには一般に、まるですべてのメモリアクセスが揮発性アクセスのように振る舞うかのように、例外を引き起こす命令を含む領域全体が保護されることが必要である。したがって、メモリアクセスのいかなる最適化もできない。
【０００６】
第３に、例外処理モデルは、正確な場合も不正確な場合もある。正確な例外処理モデルにおいて、２つの命令の相対的な順序は、メモリ状態の観察可能な挙動を保持する必要がある。これは、ハンドラまたはコードの他の一部分が変数の異なる値を認識する場合、命令の並べ替えを行うことはできないことを意味する。Ｃ＃、Ｍｉｃｒｏｓｏｆｔ  ＣＬＲ、およびＣ＋＋などの言語は、正確な機構を必要とする。こうしたモデルにおいて、コンパイラは、例外命令を互いに対して並べ替え、その効果がグローバルに見える他の任意の命令を並べ替える必要がある場合がある。不正確なモデルにおいて、例外の効果に対する命令の相対的な順序は不確定であり、コンパイラは、こうした命令を自由に並べ替えることができる。いずれのモデルでも、例外命令とそのハンドラとの間の順序は、常に定義されており、制御依存に基づいている。Ａｄａなど一部の言語は、不正確な例外モデルを有する。
【０００７】
例外処理モデルの第４の特徴は、様々な例外処理モデルにおいてハンドラの関連付けがどのように行われるかである。Ｃ＋＋、Ｃ♯、およびＭｉｃｒｏｓｏｆｔ  ＣＬＲを含むほとんどの言語において、ハンドラの関連付けは、字句であり、静的に行われる。これは、ハンドラコードの先頭を識別することが静的に可能であり、これは一意であることを意味する。後述するように、ハンドラ本体を静的に識別するこの属性を使用して、例外処理命令の中間表現を生成することができる。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
したがって、例外処理を表す複数のモデルにわたって均一であり、上記のこうしたモデルの様々な属性を考慮することができる、例外処理構成体を中間的に表す単一の均一フレームワークが必要である。
【課題を解決するための手段】
【０００９】
本明細書に記載したように、例外処理構成体の均一の中間表現を使用して、様々な言語の例外処理モデルを表すことができる。一態様において、本明細書では、異なる複数の例外処理機構を表すための中間表現に関連する単一組の命令について記載されている。例えば、共通の１組の関連の命令を使用して、ｔｒｙ（試行）領域からｆｉｎａｌｌｙ領域まで、次いでｆｉｎａｌｌｙ領域の外側までの制御フローについて記述することができる。さらに別の態様において、共通の１組の関連の命令を使用してｔｒｙ領域からｃａｔｃｈ領域までの制御フローを表すことができる。さらに、ハンドラまたはｃａｔｃｈ領域を保護するフィルタを表すこともできる。いくつかの条件下で例外を引き起こす領域に制御を戻すためのｔｒｙ領域から「ｅｘｃｅｐｔ（例外）」領域までの制御フローを表すこともできる。例外処理構成体の均一の中間表現を使用して、オブジェクトの解体子（デストラクタ：ｄｅｓｔｒａｃｔｏｒ）に関連する例外処理制御フローを表すこともできる。
【００１０】
別の一態様において、本明細書には、例外処理構成体の制御フローを表す均一の中間表現を生成するための方法およびシステムについて記載している。一態様において、中間表現は、ソースコードファイルの中間言語表現を変換することによって生成することができる。異なる複数の中間言語を使用して、例外処理構成体の中間表現を生成することができる。別の一態様において、例外処理構成体の中間表現は、ソフトウェア開発ツールによって、コード生成、コード最適化、解析などのタスクに使用することができる。
【００１１】
追加の特徴および利点は、添付の図面を参照して進める実施形態の例の以下の詳細な説明から明らかになる。
【発明を実施するための最良の形態】
【００１２】
（例外処理構成体の言語中立中間表現（Ｌａｎｇｕａｇｅ  ｉｎｄｅｐｅｎｄｅｎｔ  ｉｎｔｅｒｍｅｄｉａｔｅ  ｒｅｐｒｅｓｅｎｔａｔｉｏｎ））
図２は、コンパイラバックエンド２４０によるコード最適化のために、複数のソース言語（２０５〜２０８）の均一の例外処理中間表現２３０を実装するシステム２００を示す図である。図２に示すように、システム２００は、複数のＩＬ表現２１０〜２１３を単一の中間表現２３０に変換するＩＬリーダ２２０によって構文解析され、または読み取られる複数のソースコード表現２０５〜２０８のそれぞれの中間言語（ＩＬ）表現２１０〜２１３を含む。ＩＬ表現は、中間表現２３０より高水準の中間表現であり、ＭＳＩＬ（Ｍｉｃｒｏｓｏｆｔ  ＣＬＲ）（Ｃ＃、Ｖｉｓｕａｌ  Ｂａｓｉｃ、ＪＳｃｒｉｐｔ、Ｃ、ＦＯＲＴＲＡＮの場合）およびＣＩＬ（Ｃ＋＋の場合）など任意の数のよく知られている中間言語で表すことができる。複数の言語の均一の例外処理フレームワークを生成するシステム２００は、複数のソース言語の単一のＩＬリーダプロセスを有するものとして示されているが、ＩＬ表現２１０〜２１３のうちの１つまたは複数にそれぞれ対応するこうした複数のリーダを実装することが可能である。
【００１３】
図３Ａは、ＩＬリーダ２２０を使用して、数々の異なるソース言語で表される例外処理構成体の均一の１組の中間表現を生成する全体的な方法を示している。３１０でソフトウェアの中間言語表現（ソースコードファイルの中間言語表現など）がリーダ２２０によって受信され、３１５でファイルが読み取られ、または構文解析されて、ＩＬコードストリーム内の例外処理構成体が識別される（３２０）。次いで３３０で、リーダ２２０（バーチャルマシン（仮想機械）とみなすこともできる）は、３２０で予め識別されていた例外処理構成体の単一かつ均一の中間表現を生成する。次いでこうした例外処理フレームワークを使用して、コード最適化およびコード生成など、コンパイラバックエンドの処理を簡単にすることができる。
【００１４】
例外処理構成体を有するソフトウェアの均一の中間表現は、ソフトウェアの例外処理制御を明示的に表すことができる。図３Ｂは、ソフトウェアの均一の中間表現から実行可能バージョンを生成する方法３５０を示す。こうした方法は、ソフトウェアの実行可能バージョン（マシン固有コードや他のオブジェクトコードなど）を生成するときに、例えばコンパイラまたは他のソフトウェア開発ツールによって使用することができる。
【００１５】
３６０で、（例えばコンパイラや他のソフトウェア開発ツールによって）均一の中間表現が読み取られる。例えば、図３Ａの方法によって生成された均一の中間表現を使用することができる。必要に応じて均一の中間表現への他の変形（ｔｒａｎｓｆｏｒｍａｔｉｏｎ）、変換（ｔｒａｎｓｌａｔｉｏｎ）、または最適化を実行することができる。
【００１６】
３７０で、（例えばコンパイラや他のソフトウェア開発ツールによって）ソフトウェアのコンピュータ実行可能バージョンが生成される。ソフトウェアのコンピュータ実行可能バージョンは、均一の中間表現に基づいてソフトウェアの例外処理制御フローを実行する。
【００１７】
図４は、複数のＩＬ表現の形式で表される複数のソース言語内の例外処理構成体の簡単な均一の中間表現を生成するシステムの別の実施形態を示している。図４に示すように、Ｍｉｃｒｏｓｏｆｔ社の．ＮＥＴ  ｆｒａｍｅｗｏｒｋ内でサポートされるソース言語グループ４１０（Ｃ♯、Ｃ、Ｍｉｃｒｏｓｏｆｔ  Ｖｉｓｕａｌ  Ｂａｓｉｃ、Ｊｓｃｒｉｐｔ、ＦＯＲＴＲＡＮなど）は、まず、ＭＳＩＬ表現４４０に変換される。しかし、Ｃ＋＋は、他のソース言語との違いのため、ＣＩＬ４３０として知られる別の中間言語で表される。ＣＩＬおよびＭＳＩＬ内の制御フローおよび例外処理モデルは、根本的に異なる方法で表され、したがって、ＣＩＬ表現およびＭＳＩＬ表現に個別のＩＬリーダ（４３５および４４５）を提供する必要がある場合がある。
【００１８】
リーダ４３５および４４５は、それぞれのリーダ内に実装されている適切なアルゴリズムを使用して、それぞれの中間言語コードストリームを構文解析し、または読み取って、バックエンド４６０に提供される例外処理命令４５０の均一のフレームワークを使用して中間言語コードストリーム内の例外処理構成体または命令または式を表すことができる。以下、本書の残りの一部では、こうした言語中立例外処理命令の組の様々な構成要素について説明する。さらに、それぞれの言語中立中間表現に変換される、中間言語内の例外処理構成体の例を示す。また、本書は、中間言語を構文解析し、例外処理構成体の中間表現を生成するアルゴリズムおよび方法についても説明する。
（中間表現のメイン制御フロー内で明示的に表される例外を引き起こす命令）
例外を引き起こす命令は、そのハンドラまたはｆｉｎａｌｌｙ領域によって保護される。命令が例外を引き起こすとき、制御フローはハンドラに移動し、時としてハンドラは、フィルタ命令の処理に基づいて条件付きで選択される場合がある。制御は、例外に基づいてまたは直接、コードのｆｉｎａｌｌｙ領域に流れ、いずれにせよ処理され、クリーンアップコードを実施するために使用される。最終的に、領域は、制御が対応するｔｒｙ領域から出る前に必ず実行される。この機構を使用して、ファイルハンドル、ソケット、ロックなどを閉じるなどのクリーンアップコードを実施することができる。図８および図１２は、様々な例外処理関連の命令を表す疑似コードを示している。図１２は、例えば、２つのｃａｔｃｈブロックによって保護されるｔｒｙ領域を示している。２つのｃａｔｃｈブロック（図１２）のどちらを処理すべきかの選択は、フィルタブロックの処理の結果に依存する。さらに別の例として、図８は、ｆｉｎａｌｌｙブロックによって保護されているｔｒｙ領域を示している。
【００１９】
図３を参照して説明したように、例外処理を表す様々なモデルによる中間言語表現を解析して、例外を引き起こす命令と、そのそれぞれのハンドラおよび継続との間の制御フローを決定することができ、この制御フローは次いで、例外を引き起こさない命令の残りと同じ制御フロー内で明示的に表すことができる。これを達成する１つの方法は、命令当たり１単語など、メモリの割り振りの代価が少なめになる命令を使用して制御フロー表現を構築することである。例外を引き起こす命令によって定義することができる例外変数を使用する命令によって、ハンドラを表すことができる。次いでハンドラまたはフィルタの命令は、例外変数をテストし、例外オブジェクトの値または型に基づいて、ハンドラ本体または別のハンドラに分岐することが可能である。同様に、Ｃ＋＋やＣ♯でのｆｉｎａｌｌｙ節によって保護されている命令は、ｆｉｎａｌｌｙ領域からの制御の移行（ｔｒａｎｓｔｅｒ）のターゲットの継続を捕捉する命令への制御フローエッジまたはポインタを有している。ｆｉｎａｌｌｙ領域の先頭で捕捉された継続に制御を移行する命令によって、この場合のｆｉｎａｌｌｙ領域の末尾をモデル化することができる。中間表現のこれらの特徴については、例を参照して以下でさらに詳しく説明する。
（命令の形式）
上述したように、中間言語表現における例外処理構成体の中間表現を、命令レベルで表すことができる。図５は、例外処理構成体をコードの残りの中間表現の制御フロー内で表すことができるようにする命令またはノード（ＩＲノード）のデータ構造のこうした１つの一般的な実装を示している。例外処理命令の固有の中間表現およびそれらの機能については、本書で後述する。一般に、ＩＲ命令は、コンパイラ構成要素の階層内で様々なレベルで実行可能であり得る。これらは、演算子（演算コード）フィールド、１組のソース（または入力）オペランド、１組の宛先（または出力）オペランドを有する。これらのオペランドは、一般に、シンボルノードへの参照である。さらに、ソースオペランドおよび宛先オペランドのそれぞれに型を付け、演算子およびオペランドの型を使用して、どんな不明確さも解決することができる。図５の命令の例において、５０４の演算子は、２つのソースオペランド５０６および５０７、並びに２つの宛先オペランド５０８および５０９を有している。
【００２０】
例外処理セマンティクスは、各命令５０５にその命令５０５のハンドラ５３０の先頭であるラベル命令５２０を指すハンドラフィールド５１０を提供することによって表しても良い。命令が例外をスローできない場合、命令のハンドラフィールド５１０はＮＵＬＬに設定される。命令は例外をスローすることはできるが、ハンドラを有していない場合、コンパイラは、特別なハンドラを構築して、現在のメソッドから制御を伝えても良い。
【００２１】
図５のＩＲ命令５０５を記述するテキスト表記は次の通りである。
【００２２】
【表１】
2007521568.tif 000002
【００２３】
ハンドララベルは、あるとすれば、セミコロンの後に表示される。命令が例外をスローしないとき、ハンドラフィールドはＮＵＬＬに設定される。これは、命令のセマンティクスによって指定されても、最適化またはプログラム解析の結果そうなることがわかっても良い。その場合、命令をテキストで次のように示すことができる。
【００２４】
【表２】
2007521568.tif 000003
【００２５】
命令の宛先オペランドまたは結果がない場合、命令記述内の宛先および「＝」記号は省略される。例えば、条件分岐命令は、明示的な宛先オペランドを何も有しておらず、次のようにテキストで条件分岐命令を表すことができる。
【００２６】
【表３】
2007521568.tif 000004
【００２７】
（例外処理命令）
以下の段落では、その演算、入力、および出力を記述することによって、中間表現の様々な例外処理関連の命令について説明する。例は、この命令セットをどのように使用すると、例外処理に関連のない命令と同じ制御フロー内の様々なモデルの例外処理構成体の中間表現を生成することができるかを示している。
【００２８】
Ｕｎｗｉｎｄ
【００２９】
【表４】
2007521568.tif 000005
【００３０】
ＵＮＷＩＮＤ命令は、例外についての一致するハンドラがないときに、現在のメソッドからの制御フローを表すために使用される。ｕｎｗｉｎｄ命令は、その前にラベルがあり、その後ろにメソッドからの出口がある。ＵＮＷＩＮＤ演算のソースオペランド（ｘ）は、スローされた例外オブジェクトを表す。これによってデータフローが明確になる。メソッド内に１つまたは複数のｕｎｗｉｎｄ命令があり得る。しかし、メソッドごとにＵＮＷＩＮＤを１つだけ有することによって、メソッドごとの中間表現空間の節約が可能になる。また、ＵＮＷＩＮＤ命令のハンドラフィールドは、通常ＮＵＬＬに設定される。
【００３１】
図６および図７は、中間表現におけるＵＮＷＩＮＤ命令の使用を示している。図６は、例外を引き起こし得る保護されていない領域の疑似コードを示している。中間表現に変換するプロセスにおいて、ＩＬ２２０リーダは、疑似コードではなく、中間言語（２１０〜２１３）表現のコードを構文解析する。しかし、疑似コードは、これらの例において、制御フローの例示を簡単にするために使用されている。例えば、図６において、式ｘ＝ａ  ｄｉｖ  ｂは、ゼロ除算演算が試行された場合に例外を引き起こし得る。元のソースコード、またはその中間言語表現（ＭＳＩＬやＣＩＬなど）がこの領域のハンドラを指定できない場合でさえ、中間表現は、通常ＵＮＷＩＮＤ命令であるデフォルトのハンドラを提供することができる。したがって、図６のコードの中間表現は、図７に示されている通りとなることができる。中間表現において、例外を引き起こす命令は、それらのハンドラフィールド７１０が記入されている（ｆｉｌｌ  ｏｕｔ）状態、かつ、ＵＮＷＩＮＤ命令の先頭をマーク付けするラベル＄ＨＡＮＤＬＥＲを備えるハンドラを指す状態、で示される。ここで、例外が引き起こされた場合、ＵＮＷＩＮＤ命令は、制御フローをメソッドから移行させる。
（終了処理（Ｆｉｎａｌｉｚａｔｉｏｎ））
ＦＩＮＡＬ、ＦＩＮＡＬＬＹ、ＥＮＤＦＩＮＡＬＬＹなど、関連のある１組の命令によって、ｆｉｎａｌｌｙ領域への、およびｆｉｎａｌｌｙ領域からの制御フローを中間表現で表すことができる。ＦＩＮＡＬ命令は、一般に、ｆｉｎａｌｌｙ領域への明示的な制御の移行（ｔｒａｎｓｆｅｒ）を処理し、ＦＩＮＡＬＬＹ命令は、ＦＩＮＡＬ命令からの移行、または、ハンドラを備える、例外を引き起こす命令を介した移行を受け入れることができる。ＥＮＤＦＩＮＡＬＬＹ命令は、ｆｉｎａｌｌｙ領域からの制御フローを表す。
【００３２】
【表５】
2007521568.tif 000006
【００３３】
ＦＩＮＡＬ命令は、Ｆｉｎａｌｌｙ命令の先頭への制御の明示的な移行を表す。この命令の第１のソースオペランドは、関連のｆｉｎａｌｌｙ命令の開始ラベルであり、第２のオペランドは、ｆｉｎａｌｌｙ領域が実行された後で制御が移行される継続ラベルである。ＦＩＮＡＬ命令のハンドラフィールドは、通常ＮＵＬＬに設定される。
【００３４】
【表６】
2007521568.tif 000007
【００３５】
ＦＩＮＡＬＬＹ命令は、２つの宛先オペランドを有する。第１のオペランドは、例外変数である。これは、例外オブジェクトのデータフローをモデル化する。第２のオペランドは、捕捉された継続のラベルまたはコードオペランドである。ＦＩＮＡＬＬＹ命令が例外の結果として実行されたとき、捕捉された継続は、字句的に取り囲むハンドラ（ｌｅｘｉｃａｌｌｙ  ｅｎｃｌｏｓｉｎｇ  ｈａｎｄｌｅｒ）のラベル、ＦＩＮＡＬＬＹラベル、またはＵＮＷＩＮＤ命令である。この継続ラベルは、一致するＥＮＤＦＩＮＡＬＬＹ（以下を参照）のハンドラフィールドとして反映される。ＦＩＮＡＬＬＹ命令のハンドラフィールドは、通常ＮＵＬＬに設定される。
【００３６】
【表７】
2007521568.tif 000008
【００３７】
ＥＮＤＦＩＮＡＬＬＹ命令は、２つ以上のオペランドを有する。第１のオペランドは、例外変数である。第２のオペランドは、その型がラベルまたはコードオペランドの型である継続変数である。これは、プログラムにおける明示的なｆｉｎａｌの呼び出しについて考え得る制御の移行を表すために使用されるケースリストも有している。ＥＮＤＦＩＮＡＬＬＹ命令で、そのハンドラフィールドを、字句的に取り囲む外部のｆｉｎａｌｌｙまたはハンドラのラベル（すなわちＦＩＬＴＥＲまたはＵＮＷＩＮＤ命令）に設定する必要がある。一致するｆｉｎａｌｌｙ命令への例外的な制御フローがない場合、ハンドラフィールドはＮＵＬＬとすることができる。さらに、ＦＩＮＡＬＬＹ命令の宛先オペランドＥおよびＲは、ＥＮＤＦＩＮＡＬＬＹ命令のソースオペランドＥおよびＲと同じである。これは、コード最適化中にバックエンド構成要素によって使用することができる２つの命令間のデータ依存を確実にする。
【００３８】
図８および図９は、ＦＩＮＡＬ、ＦＩＮＡＬＬＹ、およびＥＮＤＦＩＮＡＬＬＹ命令を使用して、ｆｉｎａｌｌｙブロックをＩＬ表現から中間表現に実装する一例を示している。図８は、ｔｒｙブロックの疑似コードを示している。ソースコードまたはその中間言語表現においてハンドラが指定されていない。しかし、前の例とは異なり、デフォルトのハンドラを指定する必要はない。というのは、式８１０は、例外を引き起こす命令ではないからである。したがって、制御は、ｆｉｎａｌｌｙ領域のみに明示的に流れる。図８のコードの中間表現を、図９に示されているように表すことができる。式９１０では、ハンドラを指定していない。ＦＩＮＡＬ命令９１５は、制御を、ｆｉｎａｌｌｙブロック９２０を指すラベル＄ＦＩＮＡＬＩＺＥによって示されているｆｉｎａｌｌｙ領域に明示的に移行する。ｆｉｎａｌｌｙブロックが実行されると、制御は、この場合「＄ＥＮＤ」であるＦＩＮＡＬ命令９１５で示される継続ラベルに移行する。
【００３９】
図１０および図１１は、ＦＩＮＡＬ、ＦＩＮＡＬＬＹ、およびＥＮＤＦＩＮＡＬＬＹ命令を含むさらに別のｔｒｙ−ｆｉｎａｌｌｙブロックの中間表現への変換を示している。しかし、この表現において、ハンドラが例外処理命令に追加される。図１０は、ｆｉｎａｌｌｙブロック１０１５によって保護されている例外を引き起こし得る命令１０１０を示す。図１１は、ｔｒｙ  ｆｉｎａｌｌｙブロックの中間表現を例外ハンドラとともに示している。１１１０の例外を引き起こす命令に、１１１５のｆｉｎａｌｌｙ命令の先頭に向けられるハンドララベル＄ＦＩＮＡＬＩＺＥが割り当てられる。この例で、ｆｉｎａｌｌｙ領域を通る２つのタイプの制御フローがモデル化される。まず、ＦＩＮＡＬＬＹ命令およびＥＮＤＦＩＮＡＬＬＹ命令が、１１１０で、例外を引き起こす演算を介して実行される。その場合、ＥＮＤＦＩＮＡＬＬＹ命令１１２０が実行された後、制御は、＄ＰＲＯＰＡＧＡＴＥラベルによってマーク付けされている領域に渡される。これは、事実上、例外パスにおける継続を捕捉する。しかし、ＦＩＮＡＬ命令１１１２を介して、ｆｉｎａｌｌｙ領域へ制御フローを明示的に移行することもできる。その場合、ＥＮＤＦＩＮＡＬＬＹ命令１１２０の末尾において、継続は、ＵＮＷＩＮＤ命令を実施しない＄ＥＮＤ領域によってマーク付けされている領域へのものである。
【００４０】
終了処理制御フローを表すさらに別の組の例外処理中間表現命令は、ＦＡＵＬＴ命令およびＥＮＤＦＡＵＬＴ命令と呼ぶことができる。これらは、ＦＩＮＡＬＬＹ命令、およびＥＮＤＦＩＮＡＬＬＹ命令と似ているが、ＦＩＮＡＬＬＹ命令とは異なり、制御フローをＦＩＮＡＬ命令からＦＡＵＬＴ命令に明示的に渡すことができない。ＦＡＵＬＴ命令への制御は、例外を引き起こす命令を介してのみ分岐される。
【００４１】
【表８】
2007521568.tif 000009
【００４２】
ＥＮＤＦＡＵＬＴ命令は、関連のＦＡＵＬＴハンドラを終了させ、指定されたハンドラに例外をスローする。対応するＦＡＵＬＴ命令へのすべての例外的な制御フローが削除されている場合、ハンドラフィールドをＮＵＬＬとすることができる。その場合、ｆａｕｌｔハンドラに到達できず、そのハンドラを削除することができる。
【００４３】
【表９】
2007521568.tif 000010
【００４４】
（フィルタベースのハンドラ）
一部の中間言語（ＭＳＩＬなど）は、フィルタベースのハンドラを実装し、それによって異なるハンドラは、例外を引き起こすイベントの特徴に基づいて、例外を引き起こすイベントに割り当てられる。（ＦＩＬＴＥＲ、ＥＮＤＦＩＬＴＥＲ、ＴＹＰＥＦＩＬＴＥＲなど）例外を受け取って、フィルタし、次いでハンドラを例外に指定する命令を使用して、こうした制御フローを中間表現で表すことができる。後述するように、ＴＹＰＥＦＩＬＴＥＲ命令を、ＦＩＬＴＥＲ命令およびＥＮＤＦＩＬＴＥＲ命令の簡易形式とすることができる。
【００４５】
【表１０】
2007521568.tif 000011
【００４６】
この命令を使用して、ＭＳＩＬでの汎用フィルタベースのハンドラを実装することができる。これは、任意の例外に一致し、命令の宛先オペランド内の例外オブジェクトを戻すだけである。ｆｉｌｔｅｒ命令はラベル付けされ、例外変数を使用してもしなくても良い任意の命令シーケンスが続く。ｆｉｌｔｅｒ命令は、介在するＦＩＬＴＥＲ命令無しに、最終的にＥＮＤＦＩＬＴＥＲ命令に到達する必要がある。ＦＩＬＴＥＲ命令のハンドラフィールドは、通常ＮＵＬＬである。
【００４７】
【表１１】
2007521568.tif 000012
【００４８】
ＥＮＤＦＩＬＴＥＲ命令は、ブールオペランド（Ｂｏｏｌｅａｎ  ｏｐｅｒａｎｄ）（Ｘ）をテストし、それが１である場合、ハンドララベルに分岐し、そうでない場合、別のｆｉｌｔｅｒまたはｕｎｗｉｎｄを試行する。
【００４９】
【表１２】
2007521568.tif 000013
【００５０】
ＴＹＰＥＦＩＬＴＥＲ命令は、例外オブジェクトの型が（静的に認識される）宛先オペランドの型のサブタイプであるかどうかをテストする。そうである場合、制御は、第１のラベル（ハンドララベル）に移行する。そうでない場合、別のｆｉｌｔｅｒまたはｕｎｗｉｎｄ命令ラベルが試行される。型フィルタが一致すると、宛先オペランドが例外オブジェクトに設定される。ＴＹＰＥＦＩＬＴＥＲ命令のハンドラフィールドは、通常ＮＵＬＬである。
【００５１】
ＴＹＰＥＦＩＬＴＥＲ命令は、簡易形式であり、実際に次のようにＦＩＬＴＥＲおよびＥＮＤＦＩＬＴＥＲの両方の演算の組み合わせとして表すことができることに留意されたい。
【００５２】
【表１３】
2007521568.tif 000014
【００５３】
ＦＩＬＴＥＲ命令は、その型がｅ．Ｔｙｐｅのものであることが確認される例外オブジェクトを戻し、それがｅ．Ｔｙｐｅのものである場合、ｘ．ｃｃがＴＲＵＥ（真）に設定され、そうでない場合、ＦＡＬＳＥ（偽）に設定される。次いでＥＮＤＦＩＬＴＥＲで、ｘ．ｃｃの値に応じて継続が＄ＬＡＢＥＬ１または＄ＬＡＢＥＬ２であることが決定される。同じ表現を、次のようにＴＹＰＥＦＩＬＴＥＲ命令として表すことができる。
【００５４】
【表１４】
2007521568.tif 000015
【００５５】
図１２および図１３は、フィルタベースの例外処理命令を使用したｔｒｙ−ｃａｔｃｈブロックの実装を示している。図１２は、例外を引き起こすｔｒｙ領域１２１０の異なる２つのハンドラ領域１２２０および１２３１による保護を示している。１２１５および１２２５のフィルタは、戻された例外オブジェクトの型に基づいて実装すべきハンドラを決定する。図１３は、中間表現のＴＹＰＥＦＩＬＴＥＲ命令を使用したｔｒｙ−ｃａｔｃｈの対の中間表現を示している。例外を引き起こす命令１３１０のハンドラフィールドは、第１のフィルタ１３１５を指す＄ＨＡＮＤＬＥＲ１に設定される。例外オブジェクトが型ＤｉｖｉｄｅＢｙＺｅｒｏＥｘｃｅｐｔｉｏｎのものである場合、制御は＄ＣＡＴＣＨ１とラベル付けされたｃａｔｃｈブロックに流れる。そうでない場合、制御は、ラベル＄ＨＡＮＤＬＥＲ２によって参照される次のフィルタ１３２５に流れる。例外オブジェクトの型が型Ｅｘｃｅｐｔｉｏｎであるかどうかに基づいて、制御は、ラベル＄ＣＡＴＣＨ２によって識別される第２のｃａｔｃｈブロック１３３０、またはラベル＄ＰＲＯＰＡＧＡＴＥによって識別されるＵＮＷＩＮＤ命令１３３５に流れる。
【００５６】
ＭＡＴＣＨＡＮＹＦＩＬＴＥＲ命令は、フィルタベースの例外処理命令の形式である。
【００５７】
【表１５】
2007521568.tif 000016
【００５８】
このフィルタは、常に無条件に任意の例外に一致し、制御を有効なラベルに移行する。これは、ＥＮＤＦＩＬＴＥＲの第１のオペランドが常に１であり、かつ、第２のラベルは指定されない、ＦＩＬＴＥＲ−ＥＮＤＦＩＬＴＥＲの対に等しい。ＭＡＴＣＨＡＮＹＦＩＬＴＥＲ命令のハンドラフィールドは、ＮＵＬＬでなければならない。ＭＡＴＣＨＡＮＹＦＩＬＴＥＲ命令も簡易形式であり、下記に示すように、ＦＩＬＴＥＲ命令およびＥＮＤＦＩＬＴＥＲ命令を使用して表すことができる。
【００５９】
【表１６】
2007521568.tif 000017
【００６０】
上記のＦＩＬＴＥＲおよびＥＮＤＦＩＬＴＥＲの組み合わせに相当するＭＡＴＣＨＡＮＹＦＩＬＴＥＲ命令は、次の通りである。
【００６１】
【表１７】
2007521568.tif 000018
【００６２】
（フィルタベースのハンドラおよび終了処理によって保護されているｔｒｙブロックを表す）
さらに別の例外処理モデルは、引き起こされる例外の型に基づいてｔｒｙブロックから１つまたは複数のハンドラ領域に流れる制御、次いで１つまたは複数のｆｉｎａｌｌｙ領域に流れる制御を有する。図１４および図１５は、こうした例の１つを示している。図１４は、ハンドラ１４２０および１４３０の対、ならびにｆｉｎａｌｌｙブロック１４４０によって保護されているｔｒｙブロック１４１０の中間言語表現（ＭＳＩＬなど）の疑似コードを示している。フィルタ１４１５および１４２５は、戻された例外オブジェクトの型に基づいて２つのハンドラブロックのいずれが処理されるかを決定する。トラバースされるｃａｔｃｈブロックに関係なく、メソッドを終了する前にｆｉｎａｌｌｙブロックに到達する必要がある。
【００６３】
図１５は、フィルタベースのＴＹＰＦＩＬＴＥＲ命令、ならびにＦＩＮＡＬ、ＦＩＮＡＬＬＹ、およびＥＮＤＦＩＮＡＬＬＹの終了処理命令を使用した図１４に示した制御フローの中間表現を示している。この例は、前の例では起こらないいくつかの興味深いポイントを示している。第１に、各ハンドラ１５２０および１５３０は、それぞれ１５２１および１５３１のｆｉｎａｌｌｙ命令の明示的な呼び出しによって終了する。これは、制御がハンドラ１４２０および１４３０からｆｉｎａｌｌｙブロック１４４０に流れる図１４に示した元のプログラムのセマンティックを反映する。第２に、最後のハンドラ１５３０を制御するフィルタ１５２５は、ｕｎｗｉｎｄ命令１５５０ではなく、ｆｉｎａｌｌｙ命令のラベルを指定する。これによって、最後のフィルタが一致しない場合、制御は確実に適切なｆｉｎａｌｌｙブロックに移行するようになる。このポイントは、例外処理がネストされた場合の例においてもさらに例証される。
【００６４】
図１６および図１７は、ネストされた例外処理を示している。図１６は、ｔｒｙ−ｃａｔｃｈブロックのｔｒｙ部分内でネストされたｔｒｙ−ｃａｔｃｈ−ｆｉｎａｌｌｙブロックの中間言語表現の疑似コードを示している。図１７は、上述したフィルタ、ハンドラ、および終了処理命令を使用した、こうした例外制御フローの中間表現を示している。図１６に示すように、外部のｔｒｙブロック１６１０は、１６２０および１６３０のフィルタを備える２つのハンドラブロックによって保護されている。ネストされているｔｒｙブロック１６１５は、フィルタを備えるｃａｔｃｈブロック１６２５、および１６３５のｆｉｎａｌｌｙブロックによって保護されている。ソースコード内のどこで例外が起こるかを含むいくつかの要因に基づいて、ここで考え得るいくつかの例外パスがある。これらすべての様々な例外パスを、図１７に示す中間表現例外命令を使用して表すことができる。例外を引き起こす命令１７０５は、＄ＨＡＮＤＬＥＲ２とラベル付けされたさらに別のフィルタベースのハンドラブロック１７１５に制御を渡し得る＄ＨＡＮＤＬＥＲ１とラベル付けされた、外部フィルタベースのハンドラブロック１７１０によって保護される。内部のｔｒｙブロック１６１５内にある例外を引き起こす命令１７０６は、＄ＨＡＮＤＬＥＲ３とラベル付けされた内部のフィルタベースのハンドラブロック１７２０によって保護されるだけでなく、その例外パスは、１７１０の＄ＨＡＮＤＬＥＲ１、および／または１７１５の＄ＨＡＮＤＬＥＲ２とラベル付けされたブロックも通過し得る。例えば、ＤｉｖｉｄｅＢｙＺｅｒｏ例外が１７０６の内部ｔｒｙブロック内の式で引き起こされる場合、例外パスは、１７２６のＥＮＤＦＩＮＡＬＬＹブロックのハンドラフィールドを＄ＨＡＮＤＬＥＲ１ラベルに設定することによって、１７２５の終了処理ブロック（終了処理コードブロック）を通って１７１０の適切なハンドラブロックに到達する。このフローは、ｔｒｙブロック１６１５からｆｉｎａｌｌｙブロック１６３５、次いでハンドラ１６２０へのフローを表す。
【００６５】
（例外処理構成体を中間言語コードから低水準の中間表現に変換する方法）
図２に示すように、中間言語のコードを処理してこうした表現を生成するＩＬリーダ２２０によって、上記の命令を使用した例外処理構成体の中間表現を生成することができる。ＩＬリーダ２２０は、任意の数の異なるプロセスまたはアルゴリズムを使用することができ、アルゴリズムの選択または設計は、中間言語自体、およびより詳細には例外処理構成体を表すそのモデルに一部分依存し得る。例えば、図４は、ＭＳＩＬ中間言語のソースコード表現を読み取り、上述した例外処理命令を使用して中間表現を生成するのに適したＩＬリーダ４４５を示している。
【００６６】
図１８は、例外処理命令の中間表現を生成するための考え得る１つの方法を示している。一部の中間言語（ＭＳＩＬなど）において、メインコードストリームとは別のデータ構造内で、例外データを捕捉することができる。こうした言語のＩＬリーダ（変換プログラム）は、例外処理データテーブル１８１０、および中間言語形式のメインコードストリーム１８２０を入力として受信することができる。次いでこうしたデータは、１８３０で、ＩＬリーダによって読み取られ、例外を引き起こす命令と、こうした命令に関連付けられている任意のｃａｔｃｈ、ｆｉｎａｌｌｙ、またはｆｉｌｔｅｒのブロックとの間の関係を決定し、１８４０で中間表現を生成することができる。
【００６７】
例えば、図１９Ａは、ソースコードの中間言語表現の一部として使用可能な例外処理データを含むデータテーブルを示している。図１９Ａに示したデータは、図１２および図１３に示したコードセグメントに対応する。上述したように、簡潔にするために、図１２は、中間言語表現の疑似コードのみを示している。しかし、ＩＬリーダは、実際には、ＭＳＩＬなどの中間言語コードを構文解析し、または読み取る。様々な命令に対するオフセット１２４０を、図１２に示したように表すことができる。ＩＬリーダは、区別可能なコードのブロックを囲むオフセットの対を認識する。例えば、図１９Ａの例外処理データは、１９１０でｔｒｙブロック１２１０のオフセットエントリ、１９１５で（ｔｒｙ−ｃａｔｃｈ、ｔｒｙ−ｆｉｎａｌｌｙ、ｔｒｙ−ｃａｔｃｈ−ｆｉｎａｌｌｙなど）ブロックの型、および１９２０でそのハンドラブロックのオフセットエントリを示している。同様に、終了処理ブロック、フィルタブロック、継続ブロック、および命令の例外パス上の他のブロックのオフセットエントリ、および互いのその関係を、図１９Ａに示すように、オフセットエントリの形で示すことができる。
【００６８】
しかし、上述したように、中間表現の例外命令は、ラベルを使用して様々なまとまりのあるコードのブロックをマーク付けまたは識別し、これらのラベルは、制御フローとともに中間表現を構築するために使用される。したがって、ＩＬリーダは、図１９Ａに示したものなどの例外処理データテーブルを使用して、中間表現を構築するためのラベルを生成する。図２０は、中間表現を生成するために使用される捕捉された例外処理データを含む中間言語コードの形の入力を処理する方法の一例である。２０１０で、構文解析し、または読み取るべきメソッドがコ―ド内にそれ以上ない場合、変換プロセスは、２０１５で停止する。そうでない場合、２０２０で、現在のメソッドおよびその関連の例外処理データテーブルが読み取られる。２０３０で、コードのブロックごとのオフセット範囲を含む例外処理データを使用して、保護することができるコードのブロックと、そのハンドラ、フィルタ、終了処理、継続などのブロックを形成するコードのブロックとの間の包含関係（ｃｏｎｔａｉｎｍｅｎｔ  ｒｅｌａｔｉｏｎｓｈｉｐ）を確立する。
【００６９】
例えば、図２１は、ツリーデータ構造を構築して、図１２に示す様々なコードのブロック間の包含関係をマッピングすることを示している。第１に、メソッド全体２１１０に属するオフセットに、ツリー上のノードが割り当てられる。次いで、例外処理データ（図１９Ａ）の各オフセット範囲が読み取られるとき、例外処理データによって提供される情報に基づいてどのハンドラによってどの範囲が保護されるかなど他の関係にオフセット範囲が割り当てられる。例えば、Ｔｒｙ−Ｃａｔｃｈオフセット範囲２１２０は、２つのハンドラ、２１４０の第１のＣａｔｃｈおよび２１５０の第２のＣａｔｃｈによって保護されるＴｒｙ範囲２１３０を含むものとして示されている。この例は、メソッド内のｔｒｙ−ｃａｔｃｈブロックの単一の場合を示しているが、複数のコードのブロックが互いの中でネストされており、ツリー構造によってこうした複数の包含関係を表すのに適した方法が提供されるので、ツリー構造がはるかに大きくなる場合がある。
【００７０】
次に図２０に戻って、様々なコードの間の包含関係が確立されると（２０３０）、２０４０で、それらのオフセット範囲によってのみ識別することができるハンドラブロックおよび宛先ブロックのそれぞれ（ｆｉｎａｌｌｙや継続など）に、特有のラベルを割り当てることができる。例えば、図１９Ｂは、ラベル＄ＨＡＮＤＬＥＲ１および＄ＨＡＮＤＬＥＲ２が図１２のコードで識別された２つのハンドラブロックに割り当てられることを示している。再度図２０に戻って、２０５０で、様々なコードのブロックの包含関係を使用して、保護されているブロックに、図１９Ｃに示すようなハンドラおよび宛先ブロックへのラベルが割り当てられる。これによって、保護されているブロックと、その関連のハンドラおよび宛先ブロックとの間の関係を、上述した中間表現式のラベルの形で表すことが可能になる。２０６０で、保護されているブロックがその適切なハンドラおよび他の宛先ブロックにマッピングされると、コードを再度構文解析することによってメソッドの中間表現が構築される。このパスで、各命令が読み取られ、それが例外を引き起こす命令である場合、そのハンドラは、前に構築された範囲のツリーデータ構造を使用して識別される。このプロセスを、プログラム内のすべてのメソッドがその中間表現に変換されるまで繰り返すことができる。
【００７１】
（オブジェクトの構成および破棄のｔｒｙ−ｆｉｎａｌｌｙブロックとしての中間表現）
Ｃ＋＋などの一部の言語によって、プログラマは、それらが宣言されるブロックまたは式内にローカルな寿命を有するオブジェクト（クラス）変数を宣言することができる。ブロック範囲または式範囲から出るとき、言語セマンティクスは、対応するオブジェクト解体子が呼び出されることを必要とする。これらの演算は、中間表現内で１組または複数組のｔｒｙ−ｆｉｎａｌｌｙブロックとして表すことができる。例えば、図２２は、ローカルオブジェクトを使用したプログラムを示している。ステートメントＳ１およびＳ３は、それぞれｃｌａｓｓ１およびｃｌａｓｓ２のコンストラクタへの呼び出しを生成する。これらのクラスのコンストラクタおよびこれらのオブジェクトを呼び出すステートメントＳ２およびＳ４は、例外をスローし得る。その場合、適切なクリーンアップが必要となる場合がある。ステートメントＳ１が例外をスローする場合、例外が伝えられる。というのは、オブジェクトはまだ正常に作成されていないからである。Ｓ２またはＳ３が例外をスローする場合、ｃｌａｓｓ１の解体子を呼び出す必要がある。しかし、Ｓ４が例外をスローする場合、ｃｌａｓｓ２の解体子が呼び出された後で、ｃｌａｓｓ１の解体子を呼び出す必要がある。この例ではハンドラがないため、例外は、メソッドの呼び出し元に伝えられる。これらの演算を、概念上、図２３に示したネストされたｔｒｙ−ｆｉｎａｌｌｙ構成体によって表すことができる。ｏｂｊ１  ２３１０のコンストラクタは、任意のｔｒｙブロックの外側にある。したがって、コンストラクタ２３１０中に例外がスローされる場合、メソッドを終了する前にオブジェクトを破棄する必要はない。しかし、ｏｂｊ１は、２３１０で正常に構築された場合、２３２０のｆｉｎａｌｌｙブロックを通過して破棄される必要がある。しかし、制御が２３３０の内部ｔｒｙブロックに到達した場合、ｏｂｊ１およびｏｂｊ２の両方は、ｆｉｎａｌｌｙブロック２３２０および２３４０の両方を通過することによって破棄される必要がある。これらの演算のＦＩＮＡＬ、ＦＩＮＡＬＬＹ、およびＥＮＤＦＩＮＡＬＬＹの命令を使用した中間表現を、図２４のように示すことができる。２つのＦＩＮＡＬ命令２４１０および２４２０は、それぞれ２４３０および２４４０で表される２組のＦＩＮＡＬＬＹ命令およびＥＮＤＦＩＮＡＬＬＹ命令に明示的なエントリを提供する。制御フローは、第２のオブジェクトの破棄中に例外が引き起こされる場合も例外を通ってこれらの命令に到達することができる。２４３５での第２のオブジェクトの解体子命令は、２４４５での第１のオブジェクトの解体子を含むＦＩＮＡＬＬＹ命令およびＥＮＤＦＩＮＡＬＬＹ命令２４４０を指すハンドララベル（＄ＤＴＯＲ１）を有する。これは、制御フローが第２のオブジェクトの解体子２４３０に到達した場合、第１のオブジェクトは必ず構築されなければならず、そのため、メソッドが終了する前に破棄される必要があるためである。第２のオブジェクトを破棄するときにスローされる例外がない場合でさえ、第１のオブジェクトは、メソッドを終了する前に２４４０（＄ＤＴＯＲ１）で依然として破棄される。
【００７２】
（式の一時オブジェクト（ｅｘｐｒｅｓｓｉｏｎ  ｔｅｍｐｏｒａｒｙ  ｏｂｊｅｃｔｓ）の中間表現）
Ｃ＋＋などの一部の言語は、式の一時オブジェクトの作成を可能にする。これらのオブジェクトは、式の評価中に作成され、式の評価後、一般に式を含むステートメントの評価の後に、破棄される。式が条件式である場合、作成されたオブジェクトは、条件付きで破棄される必要がある。例えば、図２５は、式の一時  ｏｂｊ１（ｘ）およびｏｂｊ２（ｘ＋１）を示している。これらのオブジェクトの解体子は、ｆｏｏ（）への呼び出し後に呼び出される必要がある。しかし、変数「ｘ」の値に応じてこれらのオブジェクトの作成が条件付きで行われることに留意されたい。したがって、これらのオブジェクトの解体子命令も、同じ条件によって保護される必要がある。これは、図２６の疑似コードで示されている１組のネストされたｔｒｙ−ｆｉｎａｌｌｙブロックとして表すことができる。「ｘ」の値に応じて、ｏｂｊ１またはｏｂｊ２は、それぞれ２６１０および２６２０で作成される。したがって、同じ条件に基づいて、ｏｂｊ１およびｏｂｊ２は、それぞれ２６３０および２６４０で破棄される必要がある。前の例とは異なり、ここでは、所与の時に１つのオブジェクトだけが作成される。図２７は、上述した複数の組のＦＩＮＡＬ、ＦＩＮＡＬＬＹ、およびＥＮＤＦＩＮＡＬＬＹの命令を使用した、この構成体の１つの中間表現を示している。「ｘ」の値に応じて、ｂｒａｎｃｈ命令２７１０は、２７２０でのｏｂｊ１のコンストラクタのコード、または２７３０でのｏｂｊ２のコンストラクタのコードを指す。また、２７２０または２７３０でのオブジェクトのいずれかの作成中に例外がスローされた場合、ハンドララベルは、メソッドの外に制御を渡すＵＮＷＩＮＤ命令をマーク付けする＄ＰＲＯＰＡＧＡＴＥ（２７２１および２７３１）に設定されることにも留意されたい。次いで、この場合もまた、作成されたオブジェクトに応じて、２７４０でｏｂｊ１が破棄されるか、２７５０でｏｂｊ２が破棄され、こうした解体子は、ＦＩＮＡＬＬＹおよびＥＮＤＦＩＮＡＬＬＹの命令の対内に含まれる。このように、式の一時オブジェクトの条件付きの作成および破棄を、中間表現命令を使用して表すことができる。
【００７３】
（値によるオブジェクト（ｏｂｊｅｃｔｓ  ｂｙ  ｖａｌｕｅ）の戻りの中間表現）
Ｃ＋＋などの一部の言語は、値によってオブジェクトを戻すことができる。オブジェクトを戻す前に、ローカルに作成されたオブジェクト上で解体子が呼び出される。例えば、図２８において、２８１０でオブジェクトａおよびｂがローカルに作成される。これらのローカルオブジェクトのいずれかの解体子が例外をスローする場合、２８２０での戻りオブジェクトｒ１、および２８３０でのｒ２は、メソッドを終了する前に破棄される必要がある。図２９Ａおよび図２９Ｂに示したように、図２８のコードの例外処理制御フローを中間表現で表すことができる。２９１０でオブジェクトｒ１を戻す前に、メソッドは、２９２０および２９３０でそれぞれローカルに作成されたオブジェクトａおよびｂの解体子を呼び出す必要がある。しかし、これらの解体子２９２０または２９３０のいずれかが例外をスローする場合、戻りオブジェクト２９４０の解体子が呼び出される必要がある。こうした制御フローを、適切な組のＦＩＮＡＬ、ＦＩＮＡＬＬＹ、ＥＮＤＦＩＮＡＬＬＹ命令を使用して図２９で示されるように表すことができる。例えば、２９３０でのオブジェクトｂの解体子のハンドララベル（＄ｆｉｎａｌ＿ａ１）は、２９２０でのオブジェクトａの解体子のラベルを指し、そのハンドララベル（＄ｆｉｎａｌ＿ｒ１）が２９４０の戻りオブジェクトｒ１の解体子を指す。これは、オブジェクトａまたはｂまたは両方の解体子の最中に引き起こされた例外がある場合、戻りオブジェクトｒ１も、メソッドを終了する前に確実に破棄されるようにする。フラグ＄Ｆ１が、２９５０で「１」に設定されており、オブジェクトａまたはｂのいずれかが正常に破棄できなかった場合は「１」に設定されたままであり、２９４０で「１」に等しい場合は、ｒ１の解体子が呼び出されることに留意されたい。このように、オブジェクトａまたはｂの破棄が成功しない場合、戻りオブジェクトｒ１は破棄される。戻りオブジェクトｒ２の条件付き破棄も同じように処理される。
【００７４】
（値によるオブジェクトのスローの中間表現）
Ｃ＋＋などの一部の言語では、値によるオブジェクト、すなわちスタック上に割り振られた値をスローし、受け取ることができる。「ｉｎｔ」型など簡単なプリミティブ値は、どんな問題ももたらさない。しかし、スタック上に割り振られた構造体（ｓｔｒｕｃｔ）およびクラスのスローは、コンストラクタおよび解体子に対する呼び出しを必要とする場合がある。図３０は、値によるオブジェクトをスローするためのソースコードを示している。概念上、演算を、図３１に示すように、疑似コードで表すことができる。この例では、ローカル値がコピーされ、コピーコンストラクタ３１１０がコピー上で呼び出される。３１２０で値がスローされると、値を受信するメソッドが後で解体子を呼び出すことができるように、ローカル値の新しいコピーの解体子が渡される必要がある。ｆｉｎａｌｌｙブロック３１３０は、すべての例外を保護し、解体子を呼び出す責任がある。
【００７５】
ｔｒｙ−ｆｉｎａｌｌｙブロックを、中間表現で１組のＦＩＮＡＬ、ＦＩＮＡＬＬＹ、およびＥＮＤＦＩＮＡＬＬＹ命令として表すことができ、以下の命令を使用して、ｃｏｐｙ命令内でコピーコンストラクタおよび解体子を定義する値型のスローを表すことができる。
【００７６】
【表１８】
2007521568.tif 000019
【００７７】
これは、コピーコンストラクタまたは解体子を定義する値型をスローするために使用されるスローの特別な形である。これは２つのオペランドを有する。第１のオペランドは、スローされる値を有する位置へのポインタであり、第２のオペランドは、破棄を実行する関数ポインタである。このセマンティクスは、ハンドラが見つかったときにスローされたオブジェクトが破棄されることである。これは、本質的に、ローカルの値型の位置を実行時に生かしておく。これを使用して、値型のＣ＋＋例外セマンティクスをモデル化することができる。ＴＨＲＯＷ命令のハンドラフィールドは、通常ＮＵＬＬに設定されない。図３２は、図３０および図３１のコードの中間表現を示している。ＴＨＲＯＷＶＡＬ命令３２１０を使用して値のスローを表しており、この例では、ＴＨＲＯＷＶＡＬ命令３２１０は、スローされたオブジェクトを受信するメソッドによって後で使用される、スローされる値の位置へのポインタ３２２０およびその解体子へのポインタ３２３０を受信することを示している。
【００７８】
（例外試行（ｔｒｙ−ｅｘｃｅｐｔ）構成体の中間表現）
ＣやＣ＋＋などの言語への構造化例外処理（ＳＥＨ；Ｓｔｒｕｃｔｕｒｅｄ  Ｅｘｃｅｐｔｉｏｎ  Ｈａｎｄｌｉｎｇ）の拡張は、例外試行（ｔｒｙ−ｅｘｃｅｐｔ）ブロックとして表される例外処理構成体を提供する。図３３は、例外試行ブロックを示している。フィルタを備えたｃａｔｃｈブロック同様、ｅｘｃｅｐｔブロックは、引き起こされた例外の型に基づいて例外を引き起こす命令のハンドラへのポインタを指定する。しかし、ｅｘｃｅｐｔブロックは、例外を引き起こした命令の実行を再開する可能性をも考慮する。以下の２つの中間表現の式を使用して、こうした例外制御フローを表すことができる。
【００７９】
【表１９】
2007521568.tif 000020
【００８０】
ＳＥＨＥＮＴＥＲ命令は、例外試行領域へのエントリをマーク付けする。そのハンドラは、ハンドラおよび保護された領域の本体への制御依存を指定する。
【００８１】
【表２０】
2007521568.tif 000021
【００８２】
ＥＮＤＲＥＳＵＭＥＦＩＬＴＥＲは、ソースオペランドが−１の値を有しているとき、例外を引き起こす命令の実行を再開させることができることを除いて、ＥＮＤＦＩＬＴＥＲと同じである。図３４は、上述したＳＥＨＥＮＴＥＲ、ＦＩＬＴＥＲ、およびＥＮＤＲＥＳＵＭＥＦＩＬＴＥＲの式を使用した図３３の例外試行構成体の中間表現を示している。３４１０で、ＳＥＨＥＮＴＥＲ命令を使用して、ｔｒｙの本体への呼び出し３４２０を前置している。また、例外試行領域内の演算間の適切な制御依存を確実にするために、ＳＥＨＥＮＴＥＲ式へのハンドラは、ＦＩＬＴＥＲ命令３４３０に設定され、これは、３４２０での例外を引き起こす命令ｆｏｏ（）への呼び出しも同様である。ＥＮＤＲＥＳＵＭＥ命令を使用して、フィルタ関数３４５０によって戻される値に基づいた例外パスの継続を示す。値「ｔ」が１の場合、制御はハンドラ本体（＄ＨＡＮＤＬＥＲＢＯＤＹ）に移行する。値が「０」である場合、メソッドは終了する。しかし、戻されたｔの値が「−１」である場合、制御は＄ＬＡＢＥＬに戻されて、第１の場所での例外を引き起こした演算の実行を再開する。また、図３４の表現は、１つの例外パスを提供する。これは、ＳＥＨＥＮＴＥＲ命令３４１０からの直接の出口を有する。これにより、確実に安全なコード移動のみが行われる。しかし、同じ表現において、３４５０のフィルタ関数への呼び出しはハンドラを有していないが、ｆｉｌｔｅｒ（）関数が例外を引き起こしそうである場合、ｕｎｗｉｎｄ命令（図示せず）などのハンドラを設定することができる。
【００８３】
（例外処理構成体の中間言語表現を中間言語コードから低水準の中間表現に変換する代替の方法）
図４に示すように、その特定の言語に固有の例外処理モデルに従うように、異なる中間言語（ＣＩＬやＭＳＩＬなど）から中間表現を生成するのに、個別のＩＬリーダが必要である場合がある。以下のセクションでは、ＣＩＬのように後置記法（ｐｏｓｔ  ｆｉｘ  ｎｏｔａｔｉｏｎ）の形で演算を表す言語から例外処理構成体の中間表現を生成する方法について説明する。
【００８４】
一般に、後置記法の式では、演算のオペランドは、演算子が表される前に表される。例えば、Ｔ＝５＋３などのＡＤＤ演算子のコードにおいて、リーダは、演算子「＋」（すなわちＡＤＤ）のコードに遭遇する前にオペランド５および３のコードに遭遇する。こうしたコードの変換プログラムは、後置記法形式、より具体的には、１つのパスにおいてこうしたコードを変換することができるものを使用し、最初にオペランドのコードを変換し、次いで、そのオペランドまたはその子ノード（式の副式とも呼ばれる）のコードに基づいて演算全体の変換されたコードを構築する。
【００８５】
図３５は、ＣＩＬなどの後置記法を使用する中間言語から例外処理構成体の中間表現を生成する１つの全体的な方法を示している。３５１０で、入力コードがノードごとに（すなわち式ごとに）読み取られる。次いで３５２０で、後置記法形式の再帰性のため、コードストリームの残りの中の現在のノードのコンテキストが決定される。このコンテキストは、その後、３５３０で、その子ノードのコードに基づいて親ノードのコードをひとまとめにするために、コンテキストを使用することができる。
【００８６】
後置記法の言語は、選択された演算子を使用して演算の形で例外情報を表すことができ、これは、図３５のやり方でＩＬリーダによって処理され、（ＦＩＮＡＬ、ＦＩＮＡＬＬＹ、ＥＮＤＦＩＮＡＬＬＹなど）命令の均一のフレームワークの形で中間表現を生成することができる。図３６は、図３４のメソッドの実装の１つの方法を示している。図３６は、その後結合してメソッドなどのコードセクションの中間表現形式を完了させることができる、変換された中間表現コードを含むための基礎的要素として働くいくつかのデータ構造（３６１０、３６２０、３６３０など）を示している。データ構造３６１０および３６３０を、各自のノードが各自のデータ構造を有している状態の概念上のスタックとして実装することができる。中間言語形式（ＣＩＬなど）のコードが読み取られ、変換されるとき、各サブ演算、副式、子ノードなどに関連する中間表現コードを、データ構造（３６１０、３６２０、３６３０など）内に格納することができる。次いで、各演算のコンテキストや包含関係が確立されたとき、または他の適切なときに、変換されたすべての中間コードが足されて、完全な変換が生成される。
【００８７】
こうした１つの方法において、中間言語入力から読み取られたノードは、評価スタック３６１０にプッシュされ、そこでそれらを評価することができる。入力から読み取られたノードの評価は、評価スタックまたはＥＨスタックからの一部のノードのポップ、および評価スタックまたはＥＨスタックへの新しいノードのプッシュを必要とする場合がある。一般に、評価スタック３６１０は、メインコードストリームのほとんどに関連する中間コードを含み得る。次いで、親ノードおよび子ノードのコンテキストまたは包含関係が確立されるにつれて、評価スタックからの一部のノードをスタックからポップし、他のノードのコードを構築することができる。例えば、簡単な加算式Ｔ＝５＋３に戻って、５および３が「＋」演算のオペランドであると決定されると、定数５および３に関連する評価スタック３６１０のノードがポップされ、加算演算のコードは、その子のノード、つまり５および３を表すノードを構成することによって統合することができる。変換アルゴリズムは、評価スタック上のノードですべての属性を計算するという不変式を使用し、維持する。
【００８８】
ＤＴＯＲコードデータ構造３６２０は、メソッドの本体に表れるすべてのオブジェクト解体子、ｃａｔｃｈブロック、およびｆｉｎａｌｌｙブロックの変換された中間表現コードシーケンスをカプセル化する構造と考えることができる。したがって、例外処理（ＥＨ）スタック３６３０は、コードシーケンスを含むために使用されるのではなく、ラベルを構築することによって様々なコードのシーケンス間の関係を確立するために使用される継続のスタックと考えることができる。ＥＨスタックは、ｔｒｙ、ｃａｔｃｈ、およびｆｉｎａｌｌｙの領域間のネスト関係を確立する。各領域は、領域に関連付けられているラベルによって識別することができる。ＥＨスタックの各ノードは、状態と呼ばれる一意のＩＤを有する。状態の概念を使用して、式の評価で割り振られたオブジェクトの数を計算する。この情報は、変換されたコードに追加する必要がある解体子の数、およびコードの残りとのそれらの関係を決定することなどのために、後で使用することができる。
【００８９】
評価スタック３６１０上のノードのそれぞれのデータ構造は、以下の通りとすることができる。
【００９０】
【表２１】
2007521568.tif 000022
【００９１】
コンパイラのフロントエンドは「Ｏｐｃｏｄｅ」フィールドおよび「ＩＬ  Ｔｙｐｅ」フィールドのみを提供することができ、フィールドの残りは、中間表現コードが生成されるときに変換プロセス中に埋められる。ＦｉｒｓｔＩｎｓｔｒフィールドおよびＬａｓｔＩｎｓｔｒフィールドによって、コードの連結およびプリペンディングが可能になる。ＤＴＯＲコードデータ構造３６２０全体を、評価スタック３６１０の１つのノードのデータ構造と同じように実装することができる。
【００９２】
ＥＨスタックノードは、例外パス上の継続を表す以下のデータ構造を有し得る。
【００９３】
【表２２】
2007521568.tif 000023
【００９４】
ｌａｂｅｌフィールドは、Ｆｉｎａｌｌｙ命令またはＴｙｐｅＦｉｌｔｅｒ命令に先行し得るｌａｂｅｌ命令を指す。ｆｌａｇフィールドを使用して、実行される例外処理操作の特徴を識別することができる。例えば、これを使用して、変換される解体子コードが式の一時などの一時オブジェクトのものであるか、それが構成される式の外側で破棄することができるオブジェクトのものであるかを識別することができる。
【００９５】
評価スタック３６１０、ＤＴＯＲコード３６２０およびＥＨスタック３６３０のノードのデータ構造のコンテキスト内で、図３５に示すような中間表現を生成する方法を、図３７に示すようにさらに詳しく説明することができる。図３７の方法は、変換される中間言語ストリーム内のメソッドごとに実施される。３７１０で、図３６に示した変換データ構造（３６１０、３６２０、３６３０など）が初期化される。例えば、評価スタック３６１０およびＥＨスタック３６３０は、空になるように初期化される。また、ＵＮＷＩＮＤノードも、ＥＨスタックにプッシュすることができる。というのは、すべてのメソッドは、少なくとも、メソッドの外側への１つの例外パスの継続を有しており、ＥＨスタックの現在の状態を初期化することもできるからである。その後、３７２０で、中間言語コードからのノードが読み取られ、そのＥＨ状態がＣｕｒｒｅｎｔＥＨＳｔａｔｅに初期化される。この場合もまた、状態を使用して、再帰的に読み取られるコードのコンテキストを維持する。その後、３７４０で、評価スタックおよびＥＨスタックの既存のコンテキスト内でノードが評価される。評価の結果、ノードのＯｐｎｄフィールド、ＦｉｒｓｔＩｎｓｔｒフィールド、およびＬａｓｔＩｎｓｔｒフィールドが定義され、コンテキストが変更される（すなわち評価スタックまたはＥＨ  Ｓｔａｃｋのノードをプッシュまたはポップすることができ、ＣｕｒｒｅｎｔＥＨＳｔａｔｅの値を変更することができる）。評価スタック上のノードは、評価されたノードを表す。ノードは、各フィールドを完全に埋める。次いで３７５０で、評価される演算が出口（ｅｘｉｔ）ではない場合、次のノードが読み取られる。しかし、それがメソッドの出口である場合、３７６０で、評価スタック３６１０上のすべての評価されたノード内に含まれる変換されたコードが先頭に付加され、ＤＴＯＲコードデータ構造３６２０内のコードがこの結果に連結されて、完全な中間表現コードが得られる。
【００９６】
（後置記法の中間言語コードの低水準の中間表現への変換例）
評価３７４０の方法は、中間言語コードの読み取りのプロセス中に異なる演算に遭遇するごとに異なる可能性がある。次の例は、中間言語コードのこうした一部の演算を評価する方法を示している。図２２および図２３は、Ｃ＋＋などの言語でのオブジェクトコンストラクタおよび解体子の疑似ソースコードを示している。図２４は、ＦＩＮＡＬ、ＦＩＮＡＬＬＹ、ＥＮＤＦＩＮＡＬＬＹなどの命令を使用した中間表現に変換された図２２および図２３のコードを示している。ＩＬリーダ（すなわち変換プログラム）によって処理される後置記法の中間言語コードは、図３８Ａ、図３８Ｂ、図３８Ｃに示した形式とすることができる。こうしたコードを読み取って、図３６および図３７を参照しながら上述した方法を使用して、中間表現（図２４）に変換することができる。
【００９７】
図３９は、変換データ構造（３９０５、３９１５、３９２５など）を使用してオブジェクトコンストラクタおよび解体子を含む図３８Ａ、図３８Ｂ、図３８Ｃの中間言語コードを変換するプロセスを示す。まず、すべてのデータ構造は、空になるように初期化される。次いで、図３８Ａ、図３８Ｂ、図３８Ｃのコードが読み取られるにつれて、各演算が評価され、ノードは評価スタック３９０５上にプッシュされるか、ポップされ、ＤＴＯＲコードデータ構造３９２５内にコードが生成され、ＥＨスタック３９１５を処理する。この例では、オブジェクト１のコンストラクタは、まず、３８１０で識別され、これは、３９１０で評価スタックにノードとしてプッシュされる。その後、３８２０で、オブジェクト１の解体子のコードに遭遇し、これもまた、評価スタックに一時的にプッシュされる。３８３０でリーダがＯｐｐｕｓｈｓｔａｔｅ演算子に遭遇したとき、解体子３８２０およびコンストラクタ３８１０はＯｐｐｕｓｈｓｔａｔｅ演算子３８３０のオペランドであったことがわかっている。また、解体子コードは、ハンドラであるため、ＤＴＯＲコードデータ構造３９２５内に配置する必要があることもわかっている。したがって、オブジェクト１の解体子に関連する評価スタック３９０５上の上部ノードは、ポップされ、最終的に、ブロックを識別するラベルとともにＤＴＯＲコードデータ構造３９２５に追加される。また、ＤＴＯＲコードデータ構造３９２５には、図３９に示すような適切な継続を備えるＦＩＮＡＬＬＹ命令およびＥＮＦＩＮＡＬＬＹ命令も追加される。ＥＨスタック３９１５は、ＵＮＷＩＮＤ命令の前に、ラベルがあるノード３９２０を有するように初期化されているが、ここで新しいノード３９４０がＥＨスタックに追加され、そのラベルは、ＦＩＮＡＬＬＹ命令およびＥＮＤＦＩＮＡＬＬＹ命令を含むコードのブロックに追加されるラベルに設定される。この時点までに、例外パスに関連する中間コードおよび継続が決定されている。オブジェクト２のコードは、同じように評価される。その後、３８４０で、Ｏｐｄｔｏｒａｃｔｉｏｎ演算子に遭遇したとき、ｆｉｎａｌｌｙ領域への明示的なエントリ（すなわちＦＩＮＡＬ命令）に関連する中間コードが２４１０および２４２０で示すように構築される。図３９は、図３８の中間言語コードの後からＯＰｐｕｓｈｓｔａｔｅ命令３８３０が評価された時点までの評価スタック３９０５、ＤＴＯＲコードデータ構造３９２５、およびＥＨスタック３９１５の状態を示している。したがって、中間表現のコードをまとめるのに必要なすべてのコードがデ―タ構造３９０５、３９２５、およびその様々なノード内に含まれており、これらが追加されて完全な変換コードを形成することができる。様々な演算子のコードを評価し、まとめる方法は異なり得るが、上述した様々なデータ構造を個々の演算子のコンテキスト、ならびにその関数および形式内で使用して、所望の中間表現を生成することができる。
【００９８】
（代替）
本発明の原理を、実施形態の例を参照して記載し、示してきたが、実施形態の例は、こうした原理から逸脱することなく、構成および詳細について変更できることは理解されよう。本明細書に記載した技術はコンパイラを使用した例を介して示しているが、任意の技術により、他のソフトウェア開発ツール（デバッガ、最適化プログラム、シミュレータ、ソフトウェア解析ツールなど）が使用可能である。また、本明細書に記載したプログラム、プロセス、または方法は、任意の特定の種類のコンピュータ装置に関連付けられたり、限定されたりしてはいないことを理解されたい。様々な種類の汎用または専用のコンピュータ装置を、本明細書に記載した教示とともに使用したり、本明細書に記載した教示に従って操作を行ったりすることができる。本明細書に記載した動作は、こうした動作を実行するコンピュータ実行可能命令を含むコンピュータ読み取り可能媒体によって達成することができる。ソフトウェアで示した実施形態の要素は、ハードウェアに実装することもでき、またその逆も可能である。本発明の原理を適用できる多くの可能な実施形態を鑑み、詳細な説明は、例示的なものにすぎず、本発明の範囲を限定するものとみなされるべきではないことを理解されたい。むしろ、頭記の特許請求の範囲、およびその均等物の範囲および意図内に含まれ得るすべての実施形態を本発明として主張する。
【図面の簡単な説明】
【００９９】
【図１】一般のコンパイラおよびその構成要素の様々な処理段階を表すフローチャートである。
【図２】複数言語固有の例外処理モデルを表すことができる均一の例外処理フレームワークを使用して例外処理命令の中間表現を生成するシステムを示すブロック図である。
【図３Ａ】複数言語固有の例外処理モデルを表すことができる均一の例外処理フレームワークを使用して例外処理命令の中間表現を生成する方法を示すフローチャートである。
【図３Ｂ】ソフトウェアの中間表現を読み取り、実行可能なバージョンをそれから生成する方法を示すフローチャートである。
【図４】ＣＩＬ言語およびＭＳＩＬ言語の複数のＩＬリーダを示す図２のシステムの一実施形態を示すブロック図である。
【図５】中間表現での命令のデータ構造の一実施形態を示す図である。
【図６】保護されていない例外を引き起こす命令の疑似コード表現を示すリストである。
【図７】図６のコードの中間表現を示すリストである。
【図８】ｆｉｎａｌｌｙブロックによって保護されている、例外を引き起こさない命令を含むｔｒｙコードセクションの疑似コード表現を示すリストである。
【図９】図８のコードの中間表現を示すリストである。
【図１０】ｆｉｎａｌｌｙブロックによって保護されている、例外を引き起こす命令を含むｔｒｙコードセクションの疑似コード表現を示すリストである。
【図１１】図１０のコードの中間表現を適切なハンドララベルとともに示すリストである。
【図１２】２つのフィルタおよび２つのｃａｔｃｈブロックによって保護されている、例外を引き起こす命令を含むｔｒｙコードセクションの疑似コード表現を示すリストである。
【図１３】図１２のコードの中間表現を、ｃａｔｃｈブロックに関連する適切なハンドララベルおよびフィルタとともに示すリストである。
【図１４】２つのフィルタ、２つのｃａｔｃｈブロック、および終了処理コードブロックによって保護されている、例外を引き起こす命令を含むｔｒｙコードセクションの疑似コード表現を示すリストである。
【図１５】図１４のコードの中間表現を、ｃａｔｃｈブロックおよび終了処理ブロックに関連する適切なハンドララベルおよびフィルタとともに示すリストである。
【図１６】ｃａｔｃｈブロックによって保護されているネストされたｔｒｙコードセクションの疑似コード表現を示すリストである。
【図１７】図１６のコードの中間表現を、ネストされた、および外部のｃａｔｃｈブロックおよび終了処理ブロックに関連する適切なハンドララベルおよびフィルタとともに示すリストである。
【図１８】例外処理構成体を中間言語から別の中間表現に変換する１つの方法を示すブロック図である。
【図１９Ａ】例外処理データテーブルのデータ構造を示す図である。
【図１９Ｂ】オフセットをそのラベルにマッピングするラベルマップを示す一例である。
【図１９Ｃ】保護されたブロックがそれぞれのオフセットにマッピングされた後のラベルマップを示す別の例である。
【図２０】例外処理データテーブル、並びに保護されているブロックとそのハンドラおよび宛先ブロックとの間の包含情報を使用して中間表現を生成する１つの方法を示すフローチャートである。
【図２１】保護されているブロックとそのハンドラおよび宛先ブロックとの間の包含関係を決定する範囲ツリーマップの一例を示す図である。
【図２２】ローカルオブジェクトの構築および破棄を示すＣ＋＋プログラムのリストである。
【図２３】オブジェクトの構築および破棄中の考え得る例外処理パスを表す疑似コード表現を示すリストである。
【図２４】図２２および図２３のコードの中間表現を示すリストである。
【図２５】式の一時オブジェクトの従来の構築を示すＣ＋＋プログラムのリストである。
【図２６】式の一時オブジェクトの従来の構築および破棄の考え得る例外パスを表す疑似表現を示すリストである。
【図２７】図２６のコードの中間表現を示すリストである。
【図２８】値によるオブジェクトを戻すＣ＋＋プログラムのリストである。
【図２９Ａ】図２８に示した値によるオブジェクトの破棄の考え得る例外パスの中間表現を示すリストである。
【図２９Ｂ】図２９Ａのリストの続きを示すリストである。
【図３０】値によるオブジェクトをスローするＣ＋＋プログラムのリストである。
【図３１】図３０に示した値型オブジェクトをスローする考え得る例外パスを表す疑似コード表現を示すリストである。
【図３２】図３１の中間表現を示すリストである。
【図３３】ｅｘｃｅｐｔコードブロックによって保護されているｔｒｙコードセクションの疑似コード表現を示すリストである。
【図３４】図３３のコードの中間表現を示すリストである。
【図３５】後置記法形式で表される中間言語を別の中間表現に変換するための方法例を示すフローチャートである。
【図３６】後置記法形式で表されるコードの読み取りから中間表現を構築するためのデータ構成の一実装形態を示す図である。
【図３７】図３６のデータ構造を使用して、後置記法形式で表されるコードを読み取ることによって中間表現を構築する方法例を示すフローチャートである。
【図３８Ａ】後置記法を使用して実施される図２２のコードセクション例を示すリストである。
【図３８Ｂ】図３８Ａの続きを示すリストである。
【図３８Ｃ】図３８Ａおよび図３８Ｂのさらに続きを示すリストである。
【図３９】図３８のコードの中間表現への変換中における図３６のデータ構造の状態を示すブロック図である。
【図１】
2007521568.tif 000024
【図２】
2007521568.tif 000025
【図３Ａ】
2007521568.tif 000026
【図３Ｂ】
2007521568.tif 000027
【図４】
2007521568.tif 000028
【図５】
2007521568.tif 000029
【図６】
2007521568.tif 000030
【図７】
2007521568.tif 000031
【図８】
2007521568.tif 000032
【図９】
2007521568.tif 000033
【図１０】
2007521568.tif 000034
【図１１】
2007521568.tif 000035
【図１２】
2007521568.tif 000036
【図１３】
2007521568.tif 000037
【図１４】
2007521568.tif 000038
【図１５】
2007521568.tif 000039
【図１６】
2007521568.tif 000040
【図１７】
2007521568.tif 000041
【図１８】
2007521568.tif 000042
【図１９Ａ】
2007521568.tif 000043
【図１９Ｂ】
2007521568.tif 000044
【図１９Ｃ】
2007521568.tif 000045
【図２０】
2007521568.tif 000046
【図２１】
2007521568.tif 000047
【図２２】
2007521568.tif 000048
【図２３】
2007521568.tif 000049
【図２４】
2007521568.tif 000050
【図２５】
2007521568.tif 000051
【図２６】
2007521568.tif 000052
【図２７】
2007521568.tif 000053
【図２８】
2007521568.tif 000054
【図２９Ａ】
2007521568.tif 000055
【図２９Ｂ】
2007521568.tif 000056
【図３０】
2007521568.tif 000057
【図３１】
2007521568.tif 000058
【図３２】
2007521568.tif 000059
【図３３】
2007521568.tif 000060
【図３４】
2007521568.tif 000061
【図３５】
2007521568.tif 000062
【図３６】
2007521568.tif 000063
【図３７】
2007521568.tif 000064
【図３８Ａ】
2007521568.tif 000065
【図３８Ｂ】
2007521568.tif 000066
【図３８Ｃ】
2007521568.tif 000067
【図３９】
2007521568.tif 000068
【手続補正書】
【提出日】平成19年5月21日(2007.5.21)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
例外処理構成体を含むソフトウェアのソース言語中立中間表現を処理するコンピューティング装置が少なくとも一部分を実行する方法であって、
前記ソフトウェアの例外処理制御フローを明示的に表し、前記例外処理構成体を含むソフトウェアの前記ソース言語中立中間表現を読み取るステップと、
有形の構成要素を有するコンピュータ読み取り可能媒体において、前記ソース言語中立中間表現に基づいて、前記ソフトウェアの前記例外処理制御フローを実行するコンピュータ読み取り可能バージョンを生成するステップと
を備えたことを特徴とする方法。
【請求項２】
前記ソース言語中立中間表現は、
終了処理コードブロックへの制御の移行を表す第１の命令と、
前記終了処理コードブロックへの制御の移行の受け入れを表す第２の命令と、
前記終了処理コードブロックからの制御の移行を表す第３の命令と
を備えたことを特徴とする請求項１に記載の方法。
【請求項３】
前記終了処理コードブロックは、オブジェクトの解体子に関連するコードを含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記終了処理コードブロックは、式の一時オブジェクトの解体子に関連するコードを含むことを特徴とする請求項２に記載の方法。
【請求項５】
前記第２の命令の宛先オペランドは前記第３の命令のソースオペランドと同じであることを特徴とする請求項２に記載の方法。
【請求項６】
前記終了処理コードブロックへの制御の移行を表す前記第１の命令は、
前記終了処理コードブロックへの制御の移行を表すために使用される前記終了処理コードブロックの先頭を示すラベルと、
前記終了処理コードブロックを終了した後の制御の移行の継続を示すラベルと
をさらに含むことを特徴とする請求項２に記載の方法。
【請求項７】
前記終了処理コードブロックへの制御の移行の受け入れを表す前記第２の命令の前に前記終了処理コードブロックの先頭を示すラベルがあり、前記終了処理コードブロックへの制御の移行は前記ラベルを使用することによって示されることを特徴とする請求項２に記載の方法。
【請求項８】
前記終了処理コードブロックからの制御の移行を表す第３の命令は、前記終了処理コードブロックへのエントリが明示的なものであったか、例外に起因するかに基づいて、異なるように前記終了処理コードブロックからの制御の移行を継続することを示すフィールドを含むことを特徴とする請求項２に記載の方法。
【請求項９】
前記ソース言語中立中間表現は、
例外を受け取って、前記例外に関連する例外オブジェクトを戻す第１の命令と、
前記例外オブジェクトの型値に基づいて前記例外を処理するハンドラを指定する第２の命令と
を含むことを特徴とする請求項１に記載の方法。
【請求項１０】
前記ハンドラを指定する第２の命令は、
前記例外オブジェクトの型値を示す少なくとも１つのブールソースオペランドと、
前記ブールソ―スオペランドが真である場合の制御フローの移る先である前記ハンドラに関連するコードブロックに先行するラベルを示す少なくとも１つのソースオペランドと、
前記ブールソ―スオペランドが偽である場合の制御フローの移る先である継続に関連するコードブロックに先行するラベルを示す少なくとも１つのソースオペランドと
を含むことを特徴とする請求項９に記載の方法。
【請求項１１】
前記ソース言語中立中間表現は、
前記例外に関連する例外オブジェクトの型値に基づいて例外のハンドラを指定する命令を含み、前記命令の宛先オペランドは、予め定められた例外オブジェクトを含み、前記命令の第１のソースオペランドは前記ハンドラに関連するコードブロックを示すラベルを含み、第２のソースオペランドは継続に関連するコードブロックを示すラベルを含む
ことを特徴とする請求項１に記載の方法。
【請求項１２】
前記命令は、前記例外オブジェクトの型値を前記予め定められた例外オブジェクトの型値と比較して、一致がある場合、前記ハンドララベルに関連する前記コードブロックに制御フローを渡し、一致がない場合、前記継続ラベルに関連する前記コードブロックに制御フローを渡すよう動作可能であることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記ソース言語中立中間表現は、
例外試行領域へのエントリを示す第１の命令と、
前記例外に関連する型値に基づく例外処理の複数の制御フローパスであって、前記例外を引き起こす命令の実行の再開に関連するパスを含む複数の制御フローパスのうちの１つを選択する第２の命令と
を含み、
前記例外処理の複数の制御フローのうちの１つを選択する第２の命令は、
前記例外の型値を示すオペランドと、
ハンドラコードブロックを示すラベルオペランドと、
継続コードブロックを示すラベルオペランドと、
前記例外を引き起こす命令を示すラベルオペランドと
を含むことを特徴とする請求項１に記載の方法。
【請求項１４】
複数のソースコード言語のソース言語中立例外処理中間表現を実装するシステムであって、
ソースコードファイルの中間言語表現を取得し、および、前記中間言語表現に基づいて前記ソースコードの例外処理構成体のソース言語中立中間表現を生成するコンピューティング装置によって、少なくとも一部分が実行される中間言語リーダ
を備え、前記ソース言語中立中間表現は前記ソースコードの例外処理制御フローを明示的に表すことを特徴とするシステム。
【請求項１５】
前記ソース言語中立中間表現に基づいてオブジェクトコードを生成するコンパイラをさらに備えたことを特徴とする請求項１４に記載のシステム。
【請求項１６】
前記例外処理構成体の前記ソース言語中立中間表現は、終了処理コードブロックへの制御の明示的な移行を表す第１の命令と、前記終了処理コードブロックへの制御の移行の受け入れを表す第２の命令と、前記終了処理コードブロックからの制御の移行を表す第３の命令とを含むことを特徴とする請求項１４に記載のシステム。
【請求項１７】
前記第２の命令の宛先オペランドは、前記第３の命令のソースオペランドと同じであることを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記終了処理コードブロックは、オブジェクトの解体子に関連するコードを含むことを特徴とする請求項１６に記載のシステム。
【請求項１９】
前記終了処理コードブロックは、式の一時オブジェクトの解体子に関連するコードを含むことを特徴とする請求項１６に記載のシステム。
【請求項２０】
前記終了処理コードブロックへの制御の明示的な移行を表す第１の命令は、前記終了処理コードブロックの前記先頭を示すラベルと、前記終了処理コードブロックを終了した後の制御の移行の継続を示すラベルとをさらに含むことを特徴とする請求項１６に記載のシステム。
【請求項２１】
前記終了処理コードブロックへの制御の移行の受け入れを表す第２の命令の前に前記終了処理コードブロックの前記先頭を示すラベルがあり、前記終了処理コードブロックへの制御の移行は前記ラベルを使用することによって示されることを特徴とする請求項１６に記載のシステム。
【請求項２２】
前記終了処理コードブロックからの制御の移行を表す前記第３の命令は、前記終了処理コードブロックへのエントリが明示的なものであったか、例外に起因するかに基づいて、異なるように前記終了処理コードブロックからの制御の移行を継続することを示すフィールドを含み、
明示的なエントリの後の前記終了処理コードブロックからの前記制御の移行の継続は、前記第１の命令によって指定された継続に一致することを特徴とする請求項１６に記載のシステム。
【請求項２３】
前記例外処理構成体のソース言語中立中間表現は、例外を受け取って、前記例外に関連する例外オブジェクトを戻す第１の命令と、前記例外オブジェクトの型値に基づいて前記例外を処理するハンドラを指定する第２の命令とを含むことを特徴とする請求項１４に記載のシステム。
【請求項２４】
前記ハンドラを指定する第２の命令は、
前記例外オブジェクトの型値を示す少なくとも１つのブールソースオペランドと、
前記ブールソースオペランドが真である場合の制御フローの移る先である前記ハンドラに関連するコードブロックに先行するラベルを示す少なくとも１つのソースオペランドと、
前記ブールソ―スオペランドが偽である場合の制御フローの移る先である継続に関連するコードブロックに先行するラベルを示す少なくとも１つのソースオペランドと
を含むことを特徴とする請求項２３に記載のシステム。
【請求項２５】
前記例外処理構成体の前記ソース言語中立中間表現は、例外に関連する例外オブジェクトの型値に基づいて前記例外のハンドラを指定する少なくとも１つの命令を含み、前記命令の宛先オペランドは予め定められた例外オブジェクトを含み、前記命令の第１のソースオペランドは前記ハンドラに関連するコードブロックを示すラベルを含み、第２のソースオペランドは継続に関連するコードブロックを示すラベルを含むことを特徴とする請求項１４に記載のシステム。
【請求項２６】
前記命令は、前記例外オブジェクトの前記型値を前記予め定められた例外オブジェクトの型値と比較して、一致がある場合、前記ハンドララベルに関連する前記コードブロックに制御フローを渡し、一致がない場合、前記継続ラベルに関連する前記コードブロックに制御フローを渡すよう動作可能であることを特徴とする請求項２５に記載のシステム。
【請求項２７】
前記例外処理構成体のソース言語中立中間表現は、例外試行領域へのエントリを示す第１の命令と、前記例外に関連する型値に基づく例外処理の複数の制御フローパスであって、前記例外を引き起こす命令の実行の再開に関連するパスを含む複数の制御フローパスのうちの１つを選択する第２の命令とを含むことを特徴とする請求項１４に記載のシステム。
【請求項２８】
前記例外処理の制御フローパスを選択する第２の命令は、
前記例外の型値を示すオペランドと、
ハンドラコードブロックを示すラベルオペランドと、
継続コードブロックを示すラベルオペランドと、
前記例外を引き起こす命令を示すラベルオペランドと
を含むことを特徴とする請求項２７に記載のシステム。
【請求項２９】
前記例外試行領域へのエントリを示す第１の命令を処理するハンドラは、前記例外を引き起こす命令を処理するハンドラと同じであることを特徴とする請求項２８に記載のシステム。
【請求項３０】
有形の構成要素を有し、ソースコードの例外処理構成体のソース言語中立中間表現を格納するコンピュータ読み取り可能な記録媒体であって、前記例外処理構成体のソース言語中立中間表現は、
終了処理コードブロックへの制御の明示的な移行を表す第１の命令と、
前記終了処理コードブロックへの制御の移行の受け入れを表す第２の命令と、
前記終了処理コードブロックからの制御の移行を表す第３の命令と
を備えたことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項３１】
前記終了処理コードブロックへの制御の明示的な移行を表す前記第１の命令は、前記終了処理コードブロックの前記先頭を示すラベルと、前記終了処理コードブロックを終了した後の制御の移行の継続を示すラベルとをさらに含むことを特徴とする請求項３０に記載のコンピュータ読み取り可能な記録媒体。
【請求項３２】
前記終了処理コードブロックへの制御の移行の受け入れを表す第２の命令の前に前記終了処理コードブロックの先頭を示すラベルがあり、前記終了処理コードブロックへの制御の移行は前記ラベルの使用によって示されることを特徴とする請求項３０に記載のコンピュータ読み取り可能な記録媒体。
【請求項３３】
前記制御の移行は明示的であることを特徴とする請求項３２に記載のコンピュータ読み取り可能な記録媒体。
【請求項３４】
前記制御の移行は、例外に起因することを特徴とする請求項３２に記載のコンピュータ読み取り可能な記録媒体。
【請求項３５】
前記終了処理コードブロックからの制御の移行を表す前記第３の命令は、前記終了処理コードブロックへのエントリが明示的なものであったか、例外に起因するかに基づいて、異なるように前記終了処理コードブロックからの制御の移行を継続することを示すフィールドを含むことを特徴とする請求項３０に記載のコンピュータ読み取り可能な記録媒体。
【請求項３６】
明示的なエントリの後の前記終了処理コードブロックからの前記制御移行の継続は、前記第１の命令によって指定された継続に一致することを特徴とする請求項３５に記載のコンピュータ読み取り可能な記録媒体。
【請求項３７】
前記第２の命令の宛先オペランドは、前記第３の命令のソースオペランドと同じであることを特徴とする請求項３０に記載のコンピュータ読み取り可能な記録媒体。
【請求項３８】
前記終了処理コードブロックへの制御フローは、関連する１組のＦＩＮＡＬ命令、ＦＩＮＡＬＬＹ命令、およびＥＮＤＦＩＮＡＬＬＹ命令によって表されることを特徴とする請求項３２に記載のコンピュータ読み取り可能な記録媒体。
【請求項３９】
前記終了処理コードブロックは、オブジェクトの解体子に関連するコードを含むことを特徴とする請求項３０に記載のコンピュータ読み取り可能な記録媒体。
【請求項４０】
前記終了処理コードブロックは、式の一時オブジェクトの解体子に関連するコードを含むことを特徴とする請求項３０に記載のコンピュータ読み取り可能な記録媒体。
【請求項４１】
前記式の一時オブジェクトは、真の条件で作成され、前記制御は、同じ真の条件で前記終了処理コードブロックに移行することを特徴とする請求項４０に記載のコンピュータ読み取り可能な記録媒体。
【請求項４２】
有形の構成要素を含み、ソースコードの例外処理構成体のソース言語中立中間表現を格納するコンピュータ読み取り可能な記録媒体であって、前記例外処理構成体のソース言語中立中間表現は、
例外を受け取って、前記例外に関連する例外オブジェクトを戻す第１の命令と、
前記例外オブジェクトの型値に基づいて前記例外を処理するハンドラを指定する第２の命令と
を備えたことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項４３】
前記ハンドラを指定する前記第２の命令は、
前記例外オブジェクトの前記型値を示す少なくとも１つのブールソースオペランドと、
前記ブールソ―スオペランドが真である場合の制御フローの移る先である前記ハンドラに関連するコードブロックに先行するラベルを示す少なくとも１つのソースオペランドと、
前記ブールソ―スオペランドが偽である場合の制御フローの移る先である継続に関連するコードブロックに先行するラベルを示す少なくとも１つのソースオペランドと
を含むことを特徴とする請求項４２に記載のコンピュータ読み取り可能な記録媒体。
【請求項４４】
前記継続に関連する前記コードブロックは、フィルタに関連することを特徴とする請求項４３に記載のコンピュータ読み取り可能な記録媒体。
【請求項４５】
前記継続に関連するコードブロックは、ｕｎｗｉｎｄ命令を含むことを特徴とする請求項４３に記載のコンピュータ読み取り可能な記録媒体。
【請求項４６】
有形の構成要素を有し、ソースコードの例外処理構成体のソース言語中立中間表現を格納するコンピュータ可読記憶媒体であって、前記例外処理構成体のソース言語中立中間表現は、
例外に関連する例外オブジェクトの型値に基づいて前記例外を処理するハンドラを指定する命令を含み、前記命令の宛先オペランドは予め定められた例外オブジェクトを含み、前記命令の第１のソースオペランドは前記ハンドラに関連するコードブロックを示すラベルを含み、第２のソースオペランドは継続に関連するコードブロックを示すラベルを含む
ことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項４７】
前記命令は、前記例外オブジェクトの型値を前記予め定められた例外オブジェクトの型値と比較して、一致がある場合、前記ハンドララベルに関連する前記コードブロックに制御フローを渡し、一致がない場合、前記継続ラベルに関連する前記コードブロックに制御フローを渡すよう動作可能であることを特徴とする請求項４６に記載のコンピュータ読み取り可能な記録媒体。
【請求項４８】
有形の構成要素を含み、ソースコードの例外処理構成体のソース言語中立中間表現を格納するコンピュータ可読記憶媒体であって、前記例外処理構成体のソース言語中立中間表現は、
例外試行領域へのエントリを示す第１の命令と、
前記例外に関連する型値に基づく例外処理の複数の制御フローパスであって、前記例外を引き起こす命令の実行の再開に関連するパスを含む複数の制御フローパスのうちの１つを選択する第２の命令と
を備えたことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項４９】
前記例外処理の制御フローパスを選択する第２の命令は、
前記例外の型値を示すオペランドと、
ハンドラコードブロックを示すラベルオペランドと、
継続コードブロックを示すラベルオペランドと、
前記例外を引き起こす命令を示すラベルオペランドと
を含むことを特徴とする請求項４８に記載のコンピュータ読み取り可能な記録媒体。
【請求項５０】
前記例外試行領域へのエントリを示す第１の命令を処理するハンドラは、前記例外を引き起こす命令を処理するハンドラと同じであることを特徴とする請求項４８に記載のコンピュータ読み取り可能な記録媒体。
【請求項５１】
複数のソースコード言語の均一の例外処理中間表現を実装するシステムであって、
少なくとも一部分が前記コンピューティング装置によって実行されて、ソースコードファイルの中間言語表現を読み取り、前記中間言語表現に基づいて前記ソースコードの例外処理構成体の均一の中間表現を生成する手段
を備え、前記均一の中間表現は、前記ソースコードの例外処理制御フローを明示的に表すことを特徴とするシステム。
【請求項５２】
前記ソース言語中立中間表現は、例外を引き起こす命令を、関連するハンドラを表すラベルに関連付けることによって前記ソフトウェアの例外処理制御フローを明示的に表し、前記ソース言語中立中間表現の各命令はハンドラフィールドを含むことを特徴とする請求項１に記載の方法。
【請求項５３】
前記生成するステップは、
前記ソースコードファイルの前記中間言語表現から中間言語コードストリームおよび関連する例外処理節を読み取り、
少なくとも一部分前記例外処理節に基づいて、保護されているコードブロックと、その関連の例外ハンドラブロックとの間の包含関係を決定し、
前記包含関係に基づいて、特有のラベルを前記例外ハンドラブロックに割り当て、
前記割当に基づいて、前記特有のラベルをその関連する保護されているコードブロックおよび例外ハンドラブロックにマッピングし、および、
１組のソース言語中立例外処理命令および前記マッピングを少なくとも一部分使用して前記ソース言語中立中間表現を構築することを特徴とする請求項１４に記載のシステム。
【国際調査報告】
2007521568.tif 000069
2007521568.tif 000070