JP4841118B2

JP4841118B2 - ソフトウェア開発インフラストラクチャ

Info

Publication number: JP4841118B2
Application number: JP2004178869A
Authority: JP
Inventors: ブイ．エス．サストリーアケーラ; エドワードエアーズアンドリュー; ジェームズエドワーズアンドリュー; エル．ミッチェルチャールズ; ミットフォードギリースデビッド; リードタルディティジュニアデビッド; バーガージュリアン; レスリーロバーツマーク; ロナルドプレスコマーク; ケー．グローバービノド
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2003-06-26
Filing date: 2004-06-16
Publication date: 2011-12-21
Anticipated expiration: 2024-06-16
Also published as: EP1491999A3; CN1664779B; US7707566B2; EP1491999A2; KR101150003B1; JP2005050312A; US20040268309A1; KR20050001472A; CN1664779A

Description

技術分野は、ソフトウェア開発に関し、特に、ソフトウェア開発ツールの作成を容易にするためのアーキテクチャに関する。

多くのプログラミング言語が、各言語に特有のプログラミングにおける利点をプログラマに提供するために利用可能である。同様に、数多くのプロセッサが、各プロセッサに特有のタスクを実行する利点を提供するために利用可能である。例えば、組込みプロセッサは、電子デバイス内の明確なタスクを処理するのに特に適している一方、Ｉｎｔｅｌ（登録商標）Ｐｅｎｔｉｕｍ（登録商標）プロセッサのような汎用プロセッサはよりフレキシブルであり、複雑なタスクを処理することができる。さらに、ソフトウェアの信頼性、セキュリティ、および高い性能に対するますます増大する需要にプログラマが対処するのを助けるために作成されたさまざまなツールタイプがある。このように、コンピューティング環境、コンフィギュレーション（構成）、およびデバイスにおける多様性がますます増大している。したがって、ソフトウェア開発者は、一連の目まぐるしく多様なソフトウェア開発シナリオの中で適応し作業することに直面している。

このような多様性に対処することの必要性は、既に非常に複雑になっているソフトウェア開発ツール構築の分野を複雑にしている。このようなソフトウェア開発ツールは、アセンブラ、逆アセンブラ、デコーダ、エンコーダ、命令選択コンポーネント、および命令合法化(instruction legalization)コンポーネント等の種々のコンポーネントを含み得る。多くの場合、このようなコンポーネントは重複する要求を有し、それらのコンポーネント自体が複数の開発ツールに（例えばコンパイラとデバッガに）現れることがある。
BACON, "Fast and Effective Optimization of Statically Typed, Object-Oriented Languages", PhD thesis, Computer Science Division, University of California, Berkeley, 3 pages of introduction and pp. i-141, 1997. DEAN et al., "Optimizations of Object-Oriented Programs Using Static Class Hierachy Analysis", European Conference on Object-Oriented Programming, pp. 77-101, 1995. GAY et al., "Fast Escape Analysis and Stack Allocation for Object-Based Programs", Proceedings of the 2000 International Conference on Compiler Construction, 12 pages, 2000. MUELLER et al., "Avoiding Unconditional Jumps by Code Replications", Proceedings of the SIGPLAN '92 Conference on Programming Language Design and Implementation, pp. 322-330, June 1992. RUF, "Effective Synchronization Removal for Java", ACM SIGPLAN Conference on Programming Language Design and Implementation, pp.208-218, BC, Canada, 2000. KNOOP et al., "Partial Dead Code Elimination," In Proceedings of the ACM SIGPLAN '94 Conference on Programming Language Design and Implementation, 12 pages, June 1994.

類似のコンポーネント機能が広く必要とされているにもかかわらず、特に一連のプログラミング言語やその他のプログラム表現の間で設計および実装を共有するツールコンポーネントを開発することはこれまで困難であった。多くの場合、各ツールの各コンポーネントは固有の実装を有するため、冗長な作業や重複したコードが多い。また、同一ソースベース内でさえ、アーキテクチャ間に統一性がほとんどないことがある。したがって、あるコンポーネントのコードでなされた改良は特定の実装を改善するが、その改良は、同じ機能を実装する他のツールやアーキテクチャに自動的には伝わらない。最後に、特定のソフトウェア開発シナリオ（筋書き）に対処するために努力を費やしても、異なるシナリオに対処するためには通常はやり直しをしなければならない。

ソフトウェア開発ツールのさまざまなコンポーネントを構築するためのソフトウェア開発アーキテクチャ（ＳＤＡ）が提供される。コンポーネントは、１つまたは複数のソース言語またはバイナリ実行可能ファイルのようなコンピュータ可読入力で書かれたプログラムに対して使用可能である。そして、これらのコンポーネントは、ソフトウェア開発ツールを作成するために組み合わせることができる。ＳＤＡは種々の態様を含む。種々の態様を別個独立に使用してもよく、あるいは、種々の態様を種々のコンビネーション（結合）またはサブコンビネーション（副結合）で使用してもよい。

一態様では、ＳＤＡは、複数のプログラミング言語およびバイナリ実行可能ファイルのような他のコンピュータ可読プログラムフォーマット（書式）を表現することが可能な中間表現と、複数のプログラミング言語または他のコンピュータ可読プログラムフォーマットをサポートすることが可能な１つまたは複数の例外処理モデルと、複数のソース言語または他のコンピュータ可読プログラムフォーマットの型表現（type representation）を表現することが可能な型システム(型体系)とを使用する。また、中間表現は、複数の実行アーキテクチャのためのバイナリ実行ファイルを表現することができる。したがって、この中間表現を用いて書かれたコンポーネントは、さまざまなプログラミング言語で書かれたプログラム、バイナリ実行可能ファイルまたはオブジェクトファイルのようなプログラムのコンピュータ可読表現、および特定のターゲットアーキテクチャのためのプログラムに適用可能である。こうして、コンポーネントの共有を可能にすることにより、ソフトウェアツールの開発コストが低減される。また、異種コンポーネントからなるプログラムの解析および最適化を改善することが容易になる。コンポーネントは、データフロー解析、制御フロー解析、プログラム変換、データ表現最適化、レジスタ割付け、および命令スケジューラを含むことができる。

一態様では、ソフトウェア開発シナリオに機能仕様を実装するための仕様をソフトウェア開発シナリオ非依存フレームワークに統合することによって、ソフトウェア開発ツールのコンポーネントを作成する方法が提供される。このようなソフトウェア開発シナリオは、プログラミング言語、ターゲット実行アーキテクチャ、中間表現のレベル等に関係し得る。

さらにもう１つの態様では、中間表現および共有コンポーネントの拡張バージョンからなるソフトウェア開発ツールを生成するためのコンピュータ実行可能ソフトウェアが提供される。このソフトウェアは、ターゲットソフトウェア開発ツールを記述するソフトウェアのための複数のコンフィギュレーションの１つの選択を受け取り、ターゲットソフトウェア開発ツールにデータ仕様を中間表現に組み込むことが可能であり、コンフィギュレーションおよびデータと整合したターゲットソフトウェア開発ツールを備えたコンポーネントを生成することができる。このようにして、コンポーネントおよび中間表現は、既存のツールに対する新たな要求、新規なタイプのツール、新しい、または改良されたプログラミング言語、および新しいコンピュータアーキテクチャのような、新規の予期しない状況で使用されるように拡張することができる。

これらおよびその他の態様は、添付図面を参照する以下の詳細な説明から明らかとなるであろう。

さまざまなソフトウェア開発ツールのコンポーネントを構築し、それらのコンポーネントを結合することによりツールを形成するためのＳＤＡ（ソフトウエア開発アーキテクチャ）が提供される。ＳＤＡは、任意個数のターゲット実行アーキテクチャの入力および出力コードとして任意個数のプログラミング言語をとり得る、さまざまなソフトウェア開発ツールを構築することが可能である。

例示的なターゲット実行アーキテクチャ
本明細書に記載のターゲット実行アーキテクチャは、さまざまなハードウェアマシンまたは仮想マシンのいずれも含み得る。ターゲット実行アーキテクチャは、コードを実行するためのいかなる環境も含み得る。このようなターゲット実行アーキテクチャとしては、Ｉｎｔｅｌ（登録商標）ｘ８６、ＡＭＤ、ＩＰＦ、ＡＲＭおよびＭＩＰＳアーキテクチャ、ならびに以下で実装されるものを含む他のアーキテクチャが挙げられる。

Ｉｎｔｅｌ（登録商標）ｘ８６アーキテクチャには、以下のものに限定されないが、ＩｎｔｅｌＣｏｒｐｏｒａｔｉｏｎから入手可能な８０ｘ８６、８０ｘ８８、Ｉｎｔｅｌ１８６、Ｉｎｔｅｌ２８６、Ｉｎｔｅｌ３８６、Ｉｎｔｅｌ４８６、およびＰｅｎｔｉｕｍ(登録商標)プロセッサのようなＩｎｔｅｌ（登録商標）ｘ８６アーキテクチャに基づくいずれのプロセッサも含まれる。ＡＭＤアーキテクチャとしては、以下のものに限定されないが、ＡｄｖａｎｃｅｄＭｉｃｒｏＤｅｖｉｃｅｓ（ＡＭＤ），Ｉｎｃ．から入手可能なＡＭＤ６４およびＡＭＤ３２アーキテクチャがある。ＩＰＦ（Itanium processor family）アーキテクチャとしては、以下のものに限定されないが、ＩｎｔｅｌＣｏｒｐｏｒａｔｉｏｎから入手可能なＩＡ６４アーキテクチャがある。ＡＲＭアーキテクチャとしては、ＡＲＭＬｔｄ．から入手可能な数多くの１６ビットおよび３２ビット組込みＲＩＳＣマイクロプロセッサがある。ＭＩＰＳアーキテクチャとしては、以下のものに限定されないが、ＭＩＰＳＴｅｃｈｎｏｌｏｇｉｅｓＩｎｃ．から入手可能なＭＩＰＳ６４（商標）およびＭＩＰＳ３２（商標）アーキテクチャがある。

例示的なソフトウェア開発ツール
本明細書に記載のソフトウェア開発ツールは、ソフトウェアを開発するために有用なさまざまなツールのいずれも含み得る。このようなツールとしては、ネイティブコードコンパイラ、ジャストインタイム（ＪＩＴ）コンパイラ、デバッガ、シミュレータ、解析ツール、欠陥検出ツール、コンパイラ開発キット（ＣＤＫ）およびオプティマイザが挙げられる。

このようなソフトウェア開発ツールは、プログラム変換コンポーネント、プログラム解析コンポーネント、アセンブラ、逆アセンブラ、デコーダ、エンコーダ、命令選択コンポーネント、命令合法化コンポーネント等のコンポーネントを含み得る。場合によっては、コンポーネント自体がツールとして作用することもある。

例示的なソフトウェア開発シナリオ
数多くのソフトウェア開発シナリオのいずれも、ＳＤＡの機能に影響を及ぼし得る。例えば、特定のソフトウェア開発ツールに対するソフトウェア開発シナリオとしては、そのソフトウェア開発ツールがターゲットとされる種々のターゲット実行アーキテクチャ（例えば、ＩＰＦ、Ｘ８６、ＡＭＤ、ＡＲＭ等）が挙げられる。また、ソフトウェア開発シナリオは、実行されるコンパイルのタイプ（例えば、ＪＩＴまたはネイティブ最適化コンパイラ）にも関係し得る。ソフトウェア開発シナリオは、解析、最適化、シミュレーション、デバッグ、コード生成等のタイプのような、ソフトウェア開発ツールによって実行される他の機能のタイプにも関係し得る。さらにもう１つのソフトウェア開発シナリオとして、ソフトウェア開発ツールが特別に設定され得る特定のプログラミング言語（例えば、ＪＡＶＡ(登録商標)、Ｃ＋＋、Ｃ＃等）に関係し得るものがある。このような言語は、異なる例外処理モデルを有することがある。さらに、ソフトウェア開発シナリオは、ツールがマネージド実行環境（例えば、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴＦｒａｍｅｗｏｒｋによって提供されるＭｉｃｒｏｓｏｆｔＣＬＲの環境）で使用されるかどうかにも関係し得る。他のシナリオも可能である。

ＳＤＡは、任意の１つまたは複数のソフトウェア開発シナリオに対処するツールのコンポーネントを作成するために使用可能である。例えば、ＳＤＡは、任意の１つまたは複数のプログラミング言語を受け付け、複数のターゲット実行アーキテクチャのいずれかのためのコードを生成する等のように動作可能なツールのコンポーネントを作成するために使用可能である。

ソフトウェア開発アーキテクチャ
図１は、ＳＤＡを用いて複数のコンフィギュレーションのうちのいずれかにおける任意個数のコンポーネントを構築することにより、さまざまなソフトウェア開発ツールを構築するための基礎として使用されるＳＤＡのブロック図を示している。コンポーネントのセット１００は、任意のコンフィギュレーションにより使用可能なモジュールを表す。これらのモジュールは、ＳＤＡにより提供されるコア機能を用いて構築される。ＳＤＡコア１００は、オブジェクトファイルまたはソースコードのセットとして提供されてもよい。ＳＤＡコア１００は、複数のマネージドおよび／またはネイティブアプリケーションプログラムインタフェース１０２（ＡＰＩ）を提示する。ＳＤＡコアおよびＡＰＩ１０２を取り囲む各ブロックは、ＳＤＡを用いて構築される可能なソフトウェア開発ツールを表す。これらのツールとしては、ネイティブコンパイラ１０４、Ｐｒｅ−ＪＩＴコンパイラ１０６、ＪＩＴコンパイラ１０８、最適化ツール１１０、欠陥検出ツール１１２、解析ツール１１４、およびコンパイラ開発キット（ＣＤＫ）１１６が挙げられる。

ネイティブコンパイラ１０４は、複数のターゲット実行アーキテクチャおよび複数のソース言語のための、ネイティブマシンコードの１つまたは複数のコンパイラを表す。例えば、ＳＤＡを用いて構築されたネイティブコンパイラ１０４は、Ｃ＋＋プログラミング言語で書かれたプログラムを、ｘ８６ターゲット実行アーキテクチャ上で実行するためのネイティブコードにコンパイルすることができる。

Ｐｒｅ−ＪＩＴコンパイラ１０６は、任意個数のターゲット実行アーキテクチャでアプリケーションを実行する前に、Ｍｉｃｒｏｓｏｆｔの．ＮＥＴプラットフォームの共通中間言語（ＣＩＬ）のようなアーキテクチャ非依存のプログラム表現からネイティブコードを最適化し生成することができる。Ｐｒｅ−ＪＩＴコンパイラは、サーバ上でインストール時にキャッシュされて動作することも、クライアント上でロード時にオンザフライで（またはバックグラウンドで）動作することも可能である。例えば、ＳＤＡのＰｒｅ−ＪＩＴの使用法１０６としては、ＣＩＬをｘ８６ターゲット実行アーキテクチャ上で実行するためのネイティブコードにコンパイルするように設計されたＰｒｅ−ＪＩＴコンパイラを作成することがある。

ＪＩＴコンパイラ１０８は、必要に応じてランタイム時（ジャストインタイム）に、ターゲット実行アーキテクチャ上でＣＩＬのようなアーキテクチャ非依存表現からコードをコンパイルすることができる。例えば、ＳＤＡからのインタフェースを用いて構築されるＪＩＴコンパイラ１０８としては、ＡＭＤターゲット実行アーキテクチャ上でランタイム時にＣＩＬをネイティブコードにコンパイルするように設計してもよい。

欠陥検出ツール１１０は、１つまたは複数の言語で書かれたコードにおいて静的に（プログラムが実行される前に）欠陥を検出することができる。欠陥検出ツールは、任意個数のターゲット実行アーキテクチャ上で動作するように構築することができる。例えば、ＳＤＡの欠陥検出の使用法１１０としては、Ｃ＋＋プログラミング言語で書かれたコードを入力として取り、そのコード内の欠陥を検出するように設計された欠陥検出ツールを作成することがある。欠陥検出ツールは、例えばｘ８６ターゲット実行アーキテクチャ上で実行されるように設計することが可能である。

解析ツール１１２は、１つまたは複数の言語で書かれたコードを解析する。解析ツールは、任意個数のターゲット実行アーキテクチャ上で動作するように構築することができる。例えば、ＳＤＡの解析ツールの使用法１１２としては、Ｃ＃プログラミング言語で書かれたコードを受け取り、１つの特定のモジュールにおける変化によりソースコードのどのモジュールまたは行が影響を受ける可能性があるかを判断することがある。これは、プログラムスライシングとして知られており、大規模なシステムを修正する場合に有益である。

オプティマイザツール１１４は、複数の言語で書かれたコードを最適化する。例えば、ＳＤＡの最適化ツールの使用法１１４としては、Ｃ＋＋プログラミング言語で書かれたコードを受け取り、プロファイルデータに基づいてフィールドのレイアウトを最適化するように設計された最適化ツールを作成するために使用するものがある。別法として、マネージドＣ＋＋のようなＭｉｃｒｏｓｏｆｔ．ＮＥＴ言語からのＣＩＬを最適化するように設計された最適化ツールを作成することも可能である。

ＣＤＫの使用１１６により、サードパーティが独立にコンパイラを開発することができる。ＣＤＫとしては、ＳＤＡのコンポーネントの一部または全部のバイナリ、ＳＤＡのコンポーネントの一部または全部のライブラリ、およびサードパーティがシステムの特定の側面を修正することを可能にするためのコンポーネントの一部または全部のソースコードが挙げられる。例えば、ＳＤＡを用いて構築されるＣＤＫツール１１６としては、ＷｉｎＣＥを使用するデバイスのためのコンパイラを高い費用効果で迅速に作成することに関心のあるチップベンダによるものがある。

本明細書に記載のツールは、ＳＤＡコア１００の要素の全部または一部を使用する。さらに、本明細書に記載のツールは、ＳＤＡコアに存在しない追加的コンポーネントを含むことができる。スループット、フットプリント、ホスト、ターゲット、およびコード品質要求に基づいて、コンフィギュレーションに対するフェーズおよびコンポーネントの追加または削除をすることができる。

例えば、ネイティブコンパイラ１０４は、コンパイル時間およびメモリフットプリント（メモリ設置面積）において最高のバジェット（経費、予算）を有し、最良のコード品質を生成することが期待されるかもしれない。したがって、このコンフィギュレーションツールでは、コードの最適化が改善されるかもしれない。これに対して、ＪＩＴコンパイラ１０８は、依然としてある程度最適化されたコードを生成しながら、より高速なコンパイル時間、およびより小さいメモリフットプリントのコンフィギュレーションを要求するかもしれない。したがって、このツールは、フローグラフ、ループグラフおよびＳＳＡグラフのようなデータ構造をできるだけ維持し、コストのかかる再構築を避けるかもしれない。さらに、中間表現を処理するパス数を最小にすることができる。

図２Ａは、ＳＤＡを用いてソフトウェア開発ツールを作成する方法のフローチャートである。ブロック２００は、ＳＤＡが受け取る１つまたは複数の仕様を示している。ブロック２０２で、仕様から（例えばソースコードを生成してからコンパイルすることによって）ソフトウェア開発コンポーネントを作成する。ブロック２０４で、コンポーネントをＳＤＡにリンクすることにより、カスタマイズされたソフトウェア開発ツールを作成する。別法として、追加的機能を提供するカスタムコードを仕様に追加し、コンポーネントに統合することも可能である。その場合、ソフトウェア開発ツールは、ＳＤＡとコンポーネントの組合せから作成することができる。

別法として、図２Ｂは、ＳＤＡの実行可能バージョンを用いてソフトウェア開発ツールを作成する方法のもう１つのフローチャートを示している。ブロック２０６で、ソフトウェア開発コンポーネントが提供される。ブロック２０８で、コンポーネントをＳＤＡにリンクすることにより、カスタマイズされたソフトウェア開発ツールを（例えばランタイム時に動的に、ソースコードへのアクセスなしに）作成する。

仕様は、１つまたは複数のソフトウェア開発シナリオに機能仕様を実装するための情報を指定するのに適したいかなるコンピュータ可読言語あるいは形式（例えば、オブジェクトもしくは実行可能コード、ソースコード、またはカスタム言語）であってもよい。

図３は、ＳＤＡ３００を用いてソフトウェア開発ツールのコンポーネントを作成するシステムのハイレベルブロック図である。ソフトウェア開発シナリオのターゲット仕様の詳細を記述するために、１つまたは複数の仕様３０２が作成される。例えば、仕様３０２は、ターゲットツールがどのプログラミング言語（例えば、ＶｉｓｕａｌＢａｓｉｃ、Ｃ＃、ＣＩＬ等のＮＥＴ(ネットワーク)言語、またはＣ＋＋）を入力としてとり得るかを指示するかもしれない。同様に、仕様は、ターゲットソフトウェア開発ツールのターゲット実行アーキテクチャ（例えば、ｘ８６、ＡＭＤ、ＭＩＰＳ、またはＩＰＦアーキテクチャ）を指示するかもしれない。さらに、仕様は、入力言語を型チェック(型検査)するためのルールセットや、ＳＤＡコアデータ構造を拡張可能なように構成するためのクラス拡張宣言のセット等の他の情報を含んでもよい。そして、仕様３０２を用いて、ＳＤＡ３００にリンクすることが可能なソフトウェア開発コンポーネントが作成される。リンクされるコンポーネント３０４およびＳＤＡ３００を組み合わせて用いて、ＪＩＴコンパイラ、Ｐｒｅ−ＪＩＴコンパイラ、ネイティブコンパイラ等のソフトウェア開発ツールのような任意個数のツール３０６を作成することができる。別法として、ターゲットソフトウェア開発ツール３０４に対する追加的機能を実装するために、カスタムコードを追加してもよい。

こうして、特定のコンフィギュレーションにおけるＳＤＡのような単一のソースベースから、１つまたは複数のソフトウェア開発シナリオのターゲットソフトウェア開発ツールをカスタマイズするために、単にターゲット仕様データ（target specific data）を供給するだけで、ソフトウェア開発ツールの任意個数のコンポーネントを作成することができる。したがって、ソフトウェア開発ツールは、ターゲット仕様(target specific)モジュールおよびターゲット不問(target agnostic)モジュールの両方に区分されるとみなすことができる。図４はこの概念を例示している。図４は、図３に示されているようなシステムを用いて作成された３つのターゲット実行アーキテクチャ（ｘ８６、ＡＭＤ、ＭＩＰＳ）のそれぞれに対するＪＩＴ、Ｐｒｅ−ＪＩＴ、Ｍｉｃｒｏｓｏｆｔ（登録商標）ＶｉｓｕａｌＣ＋＋（登録商標）ネイティブコンパイラ、デバッガ、およびオプティマイザのブロック図である。実行アーキテクチャのための種々のツールが共通ＳＤＡおよび仕様から構築されるので、仕様またはカスタムコードによって供給されるソフトウェア開発ツールのターゲット仕様コードは、共通ＳＤＡによって供給することができるターゲット不問コードから区分される。したがって、ターゲット実行アーキテクチャのコンポーネントは、同一の仕様から作成されるので、異なるタイプのソフトウェア開発ツールで同一とすることができる。

ソフトウェア開発ツールは、ターゲット仕様コンポーネントのみを変更すればよいので、異なる実行アーキテクチャ間で容易にリターゲットすることができる。また、ターゲット仕様コードまたはターゲット不問コードのいずれで発見されるバグも、大規模に修正することができる。

例えば、開発者が、Ｉｎｔｅｌ（登録商標）ｘ８６アーキテクチャ用のＪＩＴコンパイラ４００を、ＡＭＤまたはＭＩＰＳアーキテクチャで機能するようにリターゲットしたいとする。開発者は、ＡＭＤまたはＭＩＰＳ実行アーキテクチャにデータ仕様を含む適切な仕様を書くだけでよい。そして、そのターゲット仕様データを、Ｉｎｔｅｌ（登録商標）ｘ８６アーキテクチャ用のＪＩＴコンパイラ４００を作成するために使用したのと同一または類似の共通ＳＤＡに統合する。そして、統合されたＳＤＡおよび仕様を用いて、ＡＭＤアーキテクチャ用のＪＩＴコンパイラ４０２、またはＭＩＰＳアーキテクチャ用のＪＩＴコンパイラ４０４を作成する。

次に、開発者がＩｎｔｅｌ（登録商標）ｘ８６アーキテクチャ用に書かれた仕様を用いて構築されたオプティマイザ４０６でソフトウェア欠陥を見つけたとする。ソフトウェア欠陥がターゲット不問コードに見つかった場合、そのコードは共通ＳＤＡの一部である可能性が最も高い。したがって、そのソフトウェア欠陥は、図４に示されているツール全体にわたって現れる可能性がある。

共通ＳＤＡを用いて構築されたコンポーネントまたは共通ＳＤＡ自体における改良がいったん構築された後は、１つのソースコードベース（コンポーネントまたは共通ＳＤＡ）において修正を実装することにより、図示されている１５個のツール（３つの異なるアーキテクチャのそれぞれについて３個のコンパイラ、２個のツール）の改良を同時に開始することができる。１５個のツールの更新された訂正バージョンは、各ターゲット実行アーキテクチャの仕様を更新されたＳＤＡで単に再コンパイルすることによって、またはＳＤＡおよびコンポーネントの新たなバイナリを配布することによってのいずれかにより、作成することができる。

同様に、ソフトウェア欠陥がＩｎｔｅｌ（登録商標）ｘ８６実行アーキテクチャのオプティマイザ４０６のターゲット仕様コードに見つかった場合、そのソフトウェア欠陥は、Ｉｎｔｅｌ（登録商標）ｘ８６実行アーキテクチャ用に書かれた仕様にある可能性が最も高い。この場合も、Ｉｎｔｅｌ（登録商標）ｘ８６実行アーキテクチャ用のツール全体にわたるソフトウェア欠陥を修正するには、１つのソースコード（Ｉｎｔｅｌ（登録商標）ｘ８６仕様）を訂正し、更新された仕様を共通ＳＤＡで再コンパイルするだけでよい。

代替実行アーキテクチャへの迅速なリターゲティング（再対象化、新しい目標に向けること）を可能にすることに加えて、図４に示されているソフトウェア開発ツールは、別のプログラミング言語を入力として受け付けるように迅速に再設計することができる。例えば、この例の目的上、デバッガ４０８がＣ＋＋を入力としＭＩＰＳ実行アーキテクチャをターゲットとすることを指示する仕様から、デバッガ４０８が作成されたとする。Ｃ＃を入力としながら依然としてＭＩＰＳアーキテクチャで実行されるようにデバッガ４０８を再設計することは、異なる入力言語を指示するように仕様を書き直すのと同程度に簡単である。そして、新しい仕様を同一または類似のＳＤＡに統合することができ、Ｃ＃を入力とする新しいデバッガが生成される。

ＳＤＡコアデータ構造およびアブストラクション
マシンモデル − アブストラクション（抽象化）のリターゲティング
本明細書に記載のＳＤＡを用いて作成されたソフトウェア開発ツールの迅速なリターゲティングをサポートするため、ＳＤＡコアはターゲット不問部分とターゲット仕様部分に分割される。可能な限り、共通のターゲット仕様コードをターゲット不問ＳＤＡに組み入れるとともに、情報を取得し、または変換を実行するためのターゲット仕様コードへの呼出しを設ける。単なる一例であるが、以下のセクションでは、ＳＤＡコアの一実施形態の実装の詳細を説明する。代替的なＳＤＡコアとして、以下の、または他の特徴のいかなる組合せを使用するものもあり得る。

レジスタ
マシンレジスタファイルにＡＰＩ経由でアクセスすることにより、レジスタファイル（例えば、汎用、浮動小数点、プレディケート）の個数を問い合わせ、どのマシンタイプ（例えば、ｉｎｔ３２，ｆｌｏａｔ６４、ＭＭＸ）を処理することができるかを判定し、マシンレジスタ（例えば、ＥＡＸ、ｒ０、ｐ３）を表すオブジェクトを取得することができる。レジスタオブジェクトは、レイアウト(Layout)クラスから導出され、以下の情報を追加することができる：データフロー等の内部列挙番号；テキスト文字列によるレジスタ名；アトリビュート；バイナリエンコーディング；拡張性オブジェクト。

マシン依存オペコード
マシンオペコードテーブルにＡＰＩ経由でアクセスすることにより、オペコード（オペラーションコード）の個数を問い合わせ、オペコード（例えば、ＡＤＤ、ＭＯＶＺＸ）を表すオブジェクトを取得することができる。オペコードオブジェクトは、以下の情報をカプセル化することができる：内部オペコード列挙、テキスト文字列によるオペコード名、アトリビュート、および拡張性オブジェクト。

呼出し規約
呼出し規約は、ローレベル化(lowering)フェーズ（相、段階）によって明示的にすることができ、ターゲット不問フレームワークにおけるアプリケーションバイナリインタフェース（ＡＢＩ）仕様のコールバックを通じて実装することができる。このフレームワークは、パラメータをレジスタに割り付けることや、レジスタオペランドをメモリオペランドに降格（demote）させること（スタック渡しのために）等のような共通のアクションのためのサブルーチンを含むことができる。

各呼出し命令に、その呼出しで使用される呼出し規約のタイプを記述するターゲット仕様のアトリビュート(属性)を注釈付けすることによって、複数の呼出し規約をサポートすることができる。このアトリビュートは、ハイレベルおよびマシン非依存の最適化フェーズによって維持し伝搬させることができる。

例外処理モデル
種々の例外処理（ＥＨ）モデルをターゲット不問な形で実装することができる。ただし、マシンモデルの問合せおよびコールバックをターゲット仕様コードに組み込むことが必要である。例外処理については、後で別のセクションでさらに詳細に説明する。

コード生成
本実施形態では、コード生成は、命令選択／ローレベル化、intrinsic（組み込み）/switch(切り替え)/question(問合せ) ｏｐ展開、および命令合法化からなる。レジスタ割付けおよびスケジューリングは、別個のフェーズとみなすことができる。コード生成については、後で別のセクションでさらに詳細に説明する。

エンコード
エンコーディングは、コンパイラＩＲ(中間表現)をバイナリマシンコードに翻訳するプロセスである。作り出されたターゲット仕様コードで生じる大量の仕事を伴うエンコーディングのためのマシン不問フレームワークがあり得る。

スケジューリングテーブル
スケジューリングテーブルは、大域（グローバル）および局所（ローカル）スケジューリングにおいて使用可能である。マシンスケジューリングテーブルは、各マシン命令によって要求される命令レイテンシ（待ち時間、呼び出し時間）および機能ユニットを含むことができる。テーブルは、コード生成で使用されるリターゲティングツールにより生成することができる。

逆アセンブラ
逆アセンブリは、コード生成ファイルによって駆動されることが可能である。逆アセンブリは、共通インタフェースを用いたリンカー（linker）およびデバッガにより共有されるＤＬＬ(動的リンクライブラリ)として実装することができる。

プロローグ／エピローグ
関数プロローグ（序文）およびエピローグ（結び文）は、ターゲット不問フレームワークにおいてターゲット仕様コールバックを用いて生成することができる。プロローグは以下の項目の一部または全部を含み得る：フレームポインタ初期化；スタックアラインメント；スタック割付け；不揮発性レジスタセーブ；例外処理構造体初期化；ランタイムチェックおよび初期化。エピローグは以下の項目の一部または全部を含み得る：不揮発性レジスタリストア；スタック割付け解除；フレームポインタ復元；ランタイムチェック。関数ごとに、局所ポインタおよびパラメータポインタという２つのフレームポインタが存在する可能性がある。これらはマシン依存および関数依存であり得る。

エンディアンサポート
クロスターゲティングシナリオでは、ＳＤＡがエンディアンネス（edianness:バイトの並び順の種類）を認識している必要がある。仕様は、ターゲット実行アーキテクチャのエンディアンネスを記述することができる。それに応じて、エミッションルーチン(emission routine)は、このエンディアンネスを守るように設計することができる。

スタック割付け
仕様は、スタックのアラインメントおよび伸長方向の情報を含むことができる。スタック割付けパッケージは、最大所要局所アラインメントおよび使用される全スタック空間の計算を担当することができる。さらに、スタックパッキング最適化を使用しない場合、スタックオフセットを局所変数に割り付けることができる。

型システム
ＩＲに対する型システム（型体系）は多くの重要な目的に役立つ。これについては、後で別のセクションでさらに詳細に説明する。

関数
関数(Function)またはメソッド(Method)オブジェクトは、単一の手続きを構成するコードを記述することができる。以下の属性が、関数オブジェクトを記述する際に考慮され得る：
１）関数ＩＤ：メソッドの一意的識別子。
２）関数名
３）返値の型
４）呼出し規約
５）関数シグネチャまたは引数リスト
６）例外情報
関数は、不連続にレイアウトされる項目を含むことができる。それに従って、例外情報や、関数のレイアウトに従う情報を有するその他のデータ構造を修正することができる。

関数が種々のコンパイラ段階を通っていく時、関数は、後の段階にとって重要なほとんどの情報を含む唯一のエンティティ(構成要素、実体)であり得る。また、関数オブジェクトは、ほとんどの変換、すなわち、コード分離、インライン化、ループ展開等に耐えて持続するオブジェクトであり得る。したがって、各関数に関連する情報は、それらの変換に合わせていく意識的な努力がなければ、たちまち古くなってしまうかもしれない。

データフロー解析が関数全体にわたって成功するためには、たとえ関数全体がもはや物理的に連続していなくても、関数全体を表現できることが望ましい。

関数とメソッド
本実施形態では、関数とメソッドを区別することは必要でないかもしれない。これは単に、クラス階層が導入される場合の用語の相違であり得る。

クラス
クラス(Class)オブジェクトは、そのクラスに属するすべての関数またはメソッドのためのコンテナであり得る。以下の属性が、クラスオブジェクトを記述することができる：
１）クラス名
２）サイズ
３）関数のリスト
４）仮想呼出しテーブルを含むデータメンバに対する型／レイアウト情報

本実施形態では、クラス定義が複数のモジュールに分解されないこともあるので、最適化の目的上、クラス内部表現を並べ替えることができることが重要である。そのようなクラス並べ替えの一例は、クラスオブジェクトに関係する多くのデータ構造が存在することに起因して、ワーキングセット縮小に関与する。それらのデータ構造もまた、クラス内部レイアウトに従うために並べ替えなければならないことがある。

フェーズ制御
本明細書に記載のＳＤＡの構成可能性および拡張性と、コンポーネントを結合するための統一的メカニズムを提供することが望ましいことから、ハードコーディングよりもデータによってフェーズ制御を提供することができる。フェーズ順序は、フェーズオブジェクトのリストを生成することによって指定することができる。フェーズリストは、コンフィギュレーション、マシンターゲット、およびユーザ拡張性によって変更され得る。

各フェーズオブジェクトは、デバッグ事前条件（実行されるべきデバッグチェック）、実行事前条件（フェーズの実行を制御するコンパイルフラグ、例えば、大域最適化のための−Ｏｄ）、プレフェーズ拡張性、フェーズエントリポイント、ポストフェーズ拡張性、デバッグ事後条件、テキスト形式のフェーズ名、ならびに次フェーズおよび前フェーズへのポインタをカプセル化することができる。

個別のフェーズは、関数が「ビック」（大きい）であることを認識し、変換を適切に抑制することを担当することができる。例えば、関数がｎ個より多くのＩＲノードを有する場合、干渉パッケージ(interference package)は、正確さを保証するために控え目(conservative)に動作し、徹底的な解析をあきらめることに決めるかもしれない。あるいは、最適化は、関数全体に対して実行するのは高くつきすぎるので、代わりに各領域に作用するか、または完全に停止することに決めるかもしれない。

メインドライバ
メインドライバは、ＳＤＡおよびアタッチされている拡張性モジュールを初期化することを担当する。起動時に、（主としてフェーズリストを設定する）コンパイラコンフィギュレーションに従って、種々のシステムパッケージを初期化することができる。次に、ターゲット仕様の初期化を実行することができる（これは、拡張性機能を提供してもよい）。次に、拡張性モジュールを初期化することができる（これは、フェーズリストを変更し、種々のデータ構造にアタッチすること等が可能である）。この時点で、コマンドラインプロセッサを呼び出してもよい。最後に、エラーが生じなかった場合、コンパイルマネージャ（これはコンフィギュレーション依存であってもよい）が制御をとることができる。

中間表現（ＩＲ）
本明細書に記載のツールのコンポーネントを作成するためのＳＤＡの一実施形態では、ツールの実行全体の期間中におけるメモリ内のユーザプログラムを表現するための、単一の共通ＩＲフォーマットが提供される。ＩＲフォーマットは、ハイレベルのマシン非依存オペレーションから、ローレベルのターゲットマシンコードまでのさまざまなコードを、単一の統一された形式を用いて表すことができる。図５は、ＳＤＡを用いて作成されたコンパイラにおける例示的なコンパイルプロセスのブロック図を示している。このコンパイラは、複数の言語を入力とし、複数の言語を出力とし、複数の実行アーキテクチャをターゲットとすることができる。

ソースコード５００〜５０６は、４つの異なるソース言語で書かれている。例えば、ソースコード５００はＣ＃で書かれている一方、ソースコード５０６はＣ＋＋で書かれている。さらに、ＰＥバイナリ等の実行可能フォーマットも入力として受け付けることができる。まず、ソースコードをリーダ５０８で処理しシステムに入力する。次に、ソース言語をハイレベルＩＲ（ＨＩＲ）に翻訳する。次に、ブロック５１０で、随意に、ＨＩＲを解析し最適化することができる。次に、ＨＩＲを中間レベルＩＲ（ＭＩＲ）に翻訳する。この表現は、ＨＩＲよりローレベルであるが、依然としてマシン非依存である。この時点で、ブロック５１２で、随意に、ＭＩＲを解析し最適化することができる。次に、ブロック５１４のコード生成により、ＭＩＲをマシン依存ローレベルＩＲ（ＬＩＲ）に翻訳する。次に、ブロック５１６で、随意に、ＬＩＲを解析し最適化することができ、ブロック５１８で、エミッタに供給することができる。エミッタは、システムに読み込まれた原ソースコードを表現する多くのフォーマット５２０〜５２６の１つでコードを出力する。このプロセス全体を通じて、プロセスを完了するのに必要なデータは、何らかの形式の永続的メモリ５２８に格納される。

このように、コンパイルプロセスは、あるレベルまたは表現から別のレベルまたは表現へ命令を変換することを伴う。一実施形態では、ＩＲをハイレベルオペレーションからマシンコードに翻訳するプロセスは、基本的な形式を全く変えずに、ＩＲにますます多くの情報を単に帰属させる一連の最適化およびコード生成パスであり得る。例えば、図６Ａ〜図６Ｄは、ソースの読み込みからハイレベルマシン非依存ＩＲを経てローレベルマシン依存ＩＲまでのＩＲ変換を順を追って示している。これらの図が示しているように、ＩＲは単に、レジスタや実マシンオペコードのようなターゲットマシンの詳細によって拡大し、それらの属性が付与される。しかし、形式は実質的に同一のままにとどまる。

また、ＩＲは、異なるＳＤＡコンフィギュレーションにおいて使用するためにスケーリング（拡大・縮小）されることも可能である。例えば、ジャストインタイム（ＪＩＴ）コンパイラコンフィギュレーションは速度およびメモリの制約があるので、ＳＤＡのＪＩＴコンフィギュレーションを用いて作成されるＪＩＴコンパイラで使用されるＩＲの形式は、コンパイル速度を低下させ、またはメモリフットプリントを増大させる傾向がある性質を追加または削除することにより構成されることが可能である。これに対して、ハイエンドの、全プログラムを最適化するネイティブコンパイラは、非常に大量のリソースを消費し、高いコード品質を要求する傾向がある。したがって、ＳＤＡのネイティブコンパイラコンフィギュレーションを用いて作成されるネイティブコンパイラで使用されるＩＲの形式は、コンパイル速度を制限し、またはコンパイラに利用可能なメモリの量を減少させる傾向のある性質を追加または削除することにより構成されることが可能である。

本実施形態では、ＳＤＡで使用されるＩＲは、演算子によって表現されるデータフローオペレーションの線形ストリーム、データフローソースのセットおよびデータフローデスティネーションのセットとして編成されたグラフデータ構造であり得る。データフロー情報および副作用は、データフローセットに明示的に含まれることが可能である。ＩＲは、ロバスト（頑健）なコード生成および型チェックを可能にするために、ソースレベルの型情報によって強く型付けされてもよい。また、ＩＲは、プログラムを完全に記述するのに必要なデータフローおよび制御フローのリンクの一部または全部を含んでもよい。すなわち、すべての必要なリンクが存在する場合、フローグラフや例外処理ツリー／グラフのような他のデータ構造は不要である。

さらに、オペレーションによって使用または定義されるいずれのリソースも、明示的か暗黙的かを問わず、オペレーションのソースまたはデスティネーション（目的）のリストに現れ得る。データフロー解析およびコンパイラ構築は一般的に単純化される。というのは、オペレーションの完全な副作用を決定するために解析する必要があるのはオペランドだけだからである。したがって、新しいオペレーションは、同一の小さいオペランドのセットを新たな方法で単に結合し直すだけで実装されるので、追加するのが容易である。

ＩＲは、メモリの曖昧性を解消しオペランドに関連する単一の「タグ」を通じて別名（alias）解析を決定するための単一のモデルを含むことができる。タグは、控え目であってもよく、あるいは、広範な解析を通じて非常に厳密にされてもよい。コンパイラのすべてのフェーズは単にタグに従い、オペレーションの副作用についての「オラクル（oracle）」を問い合わせることができるだけである。

以下のセクションでは、本明細書に記載のＳＤＡの実施形態における使用に適したＩＲの一実施形態の実装の詳細について説明する。

例示的なＩＲ
ＳＤＡの実施形態の例示的なＩＲは、型付きのタプルの線形ストリームとして実装することができる。各タプルは、入力オペランドのセット（ソースリスト）、演算子、および出力オペランドのセット（デスティネーションリスト）を有することができる。副作用（例えばすべての副作用）は、実または暗黙のレジスタｕｓｅ／ｄｅｆおよびシンボルｕｓｅ／ｄｅｆの情報を含めて、命令に対して明示的であり得る。間接演算子(indirection)には干渉情報がアタッチされる。

ＩＲは、フローグラフの有無を問わず存在し得るが、大域最適化はフローグラフを必要とすることがある。例外処理領域グラフおよび最適化領域グラフもまた、ＩＲ情報を増強するために使用可能である。ＩＲは、フローグラフ、ループグラフを構築し、例外処理領域グラフへのマッピングを再確立するための十分な情報を有していなければならない。フローグラフ（ならびにそれほどではないがループおよび例外処理領域グラフ）はほとんど常に存在し得るので、これらのグラフがコアＩＲの一部であるシステムの場合と同様に、設計はこれらのグラフへの容易なアクセスを提供することができる。

ＩＲは、ツリーベースおよびＳＳＡベースの最適化を直接サポートするように設計することができる。これは、リーフタプル(leaf tuple)にｄｅｆフィールドを追加することによって行うことができる。その最も単純な形式では、式一時変数(expression temp)をつなぎ合わせて式ツリーを形成することができる。これは、あらかじめローレベル化された(pre-lowered)コードに対して不変であり得る。この式スレッド化は、式ビューを使用する必要のない解析では無視することができる。変換は、それらを正しい状態のままにすることができ、クリーンアップのために式オプティマイザを使用してもよい。本格的なＳＳＡは、同じｄｅｆフィールドを使用し、ＰＨＩ命令のような特別のオペレーションを含むことができる。ＳＳＡの下では、式一時変数は単にＳＳＡグラフ全体のサブセットとなり得る。

インラインの_codeをサポートするため、コンパイラの初期フェーズは、_asmシーケンスのデータフロー効果を要約する「outline」命令を見ることができる。実際の_asm命令シーケンスは、ローレベル化の非常に後の段階がシーケンスをインライン化するまで、サイドリストとして置いておくことができる。

ＩＲの種々の例がローレベル化プロセスを示しているが、ＩＲは高レベル化(raising)プロセスでも使用可能である。例えば、ツールは、バイナリを入力として取り、そのバイナリに対するＩＲを構築することができる。

オペランド
オペランドは、命令のリーフノード（leaf node）であること、ならびに、命令のソースリストおよびデスティネーションリストに現れることが可能である。すべての副作用を命令に対して明示的にすることができるので、オペランドは、即値、レジスタ、メモリ、および条件コードを含む、一部または全部の、実際のまたは潜在的な、リソース使用を記述するために存在する。各リーフノードは、その抽象型を表す関連する型を有することができる。これはさらに、ローレベル化された命令に対するマシンタイプにマッピングされる。

レジスタ
レジスタオペランドは、実際の物理レジスタまたは仮想レジスタのいずれかを指定することができる。

一時レジスタ
一時オペランドは次の２つの形式の一方をとり得る：１）式一時変数（すなわちtemp reg）は、式中で使用される単一ｄｅｆ、単一ｕｓｅの一時変数であり得る；または２）一般一時変数（すなわちtemp var）は、questionOp、ＣＳＥ、スカラー置換、およびインダクション変数等のためにコンパイラによって導入されることが可能であり、複数のｄｅｆおよびｕｓｅを有することができる。

式一時変数はレジスタ内にのみ存続することが可能であり、基本ブロック境界を越えて存続することはない。一般一時変数は、レジスタまたはメモリ内に存続することができ、基本ブロック境界を越えて存続することができる。いずれも、アドレスが取られることはない。

物理レジスタ
物理レジスタは、実際のマシンレジスタである。これには、整数、浮動小数点、マルチメディア、ベクトル、および専用レジスタがある。

名前付きレジスタ
名前付きレジスタは、物理マシンレジスタの候補であるか、または物理マシンレジスタに割り付けられたユーザ変数であり得る。

メモリ
メモリオペランドは、メモリまたは抽象メモリに格納される値を指定することができる。抽象メモリは、明示的な干渉計算のために使用可能である。

名前付きメモリ
名前付きメモリは、メモリに格納されているユーザ変数を指定することができる。

ベクトルメモリ
ベクトルメモリは、ベクトル演算のベクトルオペランドにおいて使用され得る。

間接メモリ
メモリ間接演算は、任意のターゲットマシン上で最も強力なアドレスモードを表すことが可能である。間接演算は、干渉情報を含んでもよい。

抽象メモリ
抽象メモリは、直接参照による以外の、明示的なメモリｕｓｅ／ｄｅｆ副作用の注釈（すなわち干渉情報）を命令に付けるために使用され得る。

アドレス
アドレスオペランドは、コードまたはデータの位置を指定することができる。

有効アドレス
有効メモリアドレスオペランドは、任意のターゲットマシン上で最も強力なアドレスモードを表すことが可能である。

データアドレス
データアドレスは、データにアクセスするために使用される有効アドレスの単純な形式であり得る。

コードアドレス
コードアドレスは、非局所コードのために使用される有効アドレスの単純な形式であり得る。

ラベル
ラベルは、局所コードのために使用される有効アドレスの単純な形式であり得る。

条件コード
ＩＲは、条件コードのための抽象概念を使用することができる。

レジスタセット
レジスタセットは、killセットおよび副作用を表現するために使用可能である。

即値
即値オペランドは、命令に現れ得る既知の値を指定することができる。この値は、常にコンパイラに既知であることもあり、あるいは、ローレベル化、リンク、およびロード状態を含む後の段階でのみ決定されることもある。

整数即値
整数即値は、最大整数サイズに正規化され得る。

浮動小数点即値
浮動小数点即値は、内部／ポータブル形式に正規化され得る。

シンボリック即値
シンボリック即値は、コンパイラによって計算され、あるいはおそらくはリンカーによって／ランタイム時に修正される定数値を表現するシンボルであり得る。

演算（マシン非依存オペコード）
演算はいくつかのカテゴリに分けることができる。これらのカテゴリは、以下のように、異なる可変サイズの種類の命令にグループ分けあるいは分解することができる：
・算術演算
・オーバーフロー付き算術演算
・論理演算
・ポインタ演算
・構造体演算
・オブジェクト演算
○割付け
○呼出し（仮想、インスタンス）
○フィールドアクセス／更新
・配列演算
○割付け
○読み書き
○境界チェックなしの読み書き
○長さ演算
・ベクトル演算
・分岐演算
・呼出し演算
・組み込み (intrinsic)呼出し演算
・復帰演算
・スイッチ（switch）演算
・例外演算
・型変換（動的／静的キャスト）
・型テスト演算
・セキュリティ演算
・スレッド化（threading）演算
・同期演算
・チェック演算
○ヌルポインタ(null pointer)チェック演算
○境界チェック演算
○型テスト演算
・アウトライン擬似演算
・データ演算

ブロック
フローグラフが存在する場合、特別のブロック擬似命令が、基本ブロックの開始および終了を表すことができる。

ラベル
ラベルは、ユーザが定義しても、コンパイラが生成してもよい。

プラグマ
プラグマ(pragma)は、ユーザが定義しても、コンパイラが生成してもよい。

注釈
注釈は、ユーザが定義しても、コンパイラが生成してもよい。通常、注釈は、ネイティブコンパイラおよびＪＩＴコンパイラがコード品質を改善するために使用可能な追加的な意味情報を伝える。

リスト
リストＩＲノードは、制御命令によって指定されるフロー内のリンクを作成するために使用される補助ノードであり得る。

分岐リスト
分岐リストノードは、ラベルにアタッチされ、すべての到達する分岐を表すことができる。

ケースリスト
ケース（case）リストノードは、スイッチ演算にアタッチされ、すべてのケース値および分岐を表すことができる。

デバッグ情報（行およびカラム）
あらゆる命令が、ソース行およびカラム情報を記述するデバッグ情報を持つことができる。コードを展開／ローレベル化する場合または最適化を行う場合、この情報は、デバッグ目的で維持されることが可能である。

型システム
ＩＲは、ＩＲの種々の形式における一貫性をチェックするための型の表現も含むことができる。具体的には、型付き言語および型なし言語、ゆるく型付けされた言語および強く型付けされた言語、ならびにガーベジコレクション(メモリ整理)のある言語およびガーベジコレクションのない言語等の複数のソース言語で書かれたプログラムを表現する際に使用するのに適した、型付けされた中間言語を提供することができる。さらに、プログラムコンポーネントのためのソース言語および／またはコンパイル段階に応じて、異なる型および型チェックルールの使用を可能にする型チェッカアーキテクチャをＳＤＡにおいて提供することができる。

例えば、さまざまな言語で書かれたプログラムに適用されるハイレベルオプティマイザがあれば望ましいであろう。これらの言語は、異なるプリミティブ（基本）型およびプリミティブ演算を有し得る。ある言語は、例えば複素算術のための型および演算を含むかもしれない一方で、別の言語は、コンピュータグラフィックスに対する型仕様および演算仕様を含むかもしれない。中間表現が異なる型システムによってパラメトライズされることを可能にすることにより、オプティマイザは、異なるプリミティブ型およびプリミティブ演算を有する言語に使用することが可能となる。

もう１つの例として、ある特定のコンポーネントは言語の強く型付けされたサブセットで書かれ、他のコンポーネントは、型安全(type-safe)でないフル言語で書かれているというプログラムがあり得る。前者のセットのコンポーネントに対して、より多くのエラーチェックがあれば望ましい。これは、異なるコンポーネントに対して異なる型チェックルールを使用することによって達成することができる。

さらにもう１つの例として、コンパイル中に型情報を落とすことがある。型チェッカおよびコンパイラは、初期段階では厳密な情報が維持されることを強制する一方で、後の段階で型情報が落ちることを許容することがある。これは、異なるコンパイル段階に対して異なる型チェックルールとともに未知(unknown)型を使用することによって達成することがある。

ＳＤＡの一実施形態では、型付きＩＲによって種々の言語の型システムを表現することができるように、いくつかの型表現を型クラス階層において定義することができる。すべての型に対して、抽象基本クラスを「Phx::Type」として定義することができる。基本クラスは、例えば、実型、シンボリック型または未知（すなわち可変）型のような種々の型に対するサイズ情報「sizekind」を含むことができる。また、基本クラスは、型分類を指定するために「typekind」も含むことができる。さらに、型付きＩＲから原ソースコードへの逆マッピングを提供するために、外部的に定義された型をラップする抽象型として外部(external)型を提供することができる。

基本クラスの下で、「Phx::PtrType」として定義されるクラスが、ポインタ型を表現することができる。種々のポインタを同様に定義することができる。例えば、ガーベジコレクトされるマネージドポインタ（ガーベジコレクトされるオブジェクト内の位置を指す）、ガーベジコレクトされないマネージドポインタ（ガーベジコレクトされないオブジェクト内の位置を指す）、アンマネージドポインタ（例えば、Ｃ＋＋で書かれたコードに見られるもの等）、参照ポインタ（ガーベジコレクトされるオブジェクトのベースを指す）、およびヌルがある。

階層内の同一レベルにおいて、「Phx::ContainerType」として定義されるクラスは、内部メンバを含む型のようなコンテナ型を表現することができる。内部メンバは、フィールド、メソッド等の型を有することができる。「Phx::FuncType」として定義されるクラスは、関数型を表現し、必要な呼出し規約、引数リストおよび返値型リストを含む。また、「Phx::UnmgdArrayType」として定義されるクラスは、アンマネージド（unmanaged）配列型を表現することができる。階層内の「Phx::ContainerType」の下には、さらに４つのクラスを定義することができる。「Phx::ClassType」として定義されるクラスはクラス型を表現し、「Phx::StructType」として定義されるクラスは構造体(struct)型を表現し、「Phx::InterfaceType」として定義されるクラスはインタフェース型を表現し、「Phx::EnumType」として定義されるクラスは列挙型を表現することができる。階層内の「Phx::ClassType」の下で、「Phx::MgdArrayType」として定義されるもう１つのクラスは、マネージド配列型を表現することができる。

クラス「primtype」は、構造体型の特別のインスタンスとして定義することができる。「primtype」は、int、float、unknown、void、条件コード、unsigned int、xint等のような種々の型を含むことができる。これらの表現は、型付きＩＲのＨＩＲまたはＬＩＲの両方で使用可能である。

さらに、ターゲット仕様プリミティブ型を型表現に含めることができる。いくつかの言語は、型システムが複素算術型を認識すれば効率的に処理することが可能な複素算術型を有する。例えば、「ＭＭＸ」命令を考える。このような命令は、マルチメディアおよび通信データ型に対する単一命令／複数データ演算をサポートするためにｘ８６プロセッサのいくつかのバージョンに組み込まれた追加命令セットの１命令である。型システムは、型表現の最小限の変更で、これらの命令を認識し使用するようにカスタマイズすることができる。

上記の型の型表現の実施形態は、「未知(unknown)」型も含むことができる。これは、任意の型を表現することができ、随意に、それに関連するサイズを有する。サイズは、値のマシン表現のサイズであってもよい。未知型は、型情報を特定の型から未知型に変更することによって、コンパイラが制御された形で型情報を落とすことを可能にする。これにより、コンパイラは、型が未知である場合であっても、操作されている値のサイズに依存するコードを生成することができる。他の型が未知型を使用するかもしれないので、未知型は、部分的な型情報の表現（その場合、全部ではないが一部の情報が既知である）も可能にする。

例えば、int型へのポインタを考える。ローレベル化のある段階で、その型情報、すなわちintを落とすことが望ましい場合がある。unknown型は、コンパイラがint型をunknown型で置き換えることを可能にする。その場合、型チェッカは、当該ポインタが正しい型を指していることをチェックする必要がない。これは本質的に、指されている値がランタイム時にプログラム機能に悪影響を及ぼさないように渡されると見込むことである。

unknown型を使用するもう１つの例として、関数の型を定義する場合がある。引数の型がunknownである関数が呼び出され、その引数の型は前にintへのポインタであった場合、コンパイラは、正しい型が渡されていることを信頼しなければならない。そのポインタを逆参照した結果がintであることが分かる場合も分からない場合もあるが、それはintとして使用される。もっと複雑な例として、仮想関数呼出しのハイレベルからローレベルへの中間表現の変換中に、中間一時変数を導入する場合がある。オブジェクト指向言語において仮想呼出しを実装するために、仮想テーブル（ｖｔａｂｌｅ）が広く使用されている。ローレベル中間表現において仮想関数呼出しを行う場合の最初のステップは、メモリのオブジェクトの最初のフィールドをフェッチ(fetch)することである。最初のフィールドは、ｖｔａｂｌｅへのポインタを含む。次に、フェッチの結果を一時変数に代入する。一時変数の型（ｖｔａｂｌｅへのポインタを表現する型であって、ここでｖｔａｂｌｅは多くのフィールドを有し得る）を構築することは複雑であり表現が面倒な場合がある。その代わりに、コンパイラは単に、中間一時変数に「pointer to unknown」を代入することができる。こうして、詳細な型情報を保持することが不要な場合やコンパイラ開発者（implementer）にとって多大な負担となる場合に、unknown型を使用することにより、後のコンパイル段階が単純化される。

図７は、コンパイルの種々の段階でＩＲを型チェックし、したがってローレベル化の種々のレベルで型付きＩＲを型チェックするコンパイラシステムの一実施形態を示している。ソースコード７００は、さまざまなソース言語のいずれか１つを表す。ソースコード７００は、型付きＩＲのＨＩＲ７０２に翻訳される。その際、ソース言語の型表現が、型付きＩＲの内部の型表現に翻訳される。

ＨＩＲは、コンパイルプロセス全体を通じてローレベル化される。この説明の目的上、高（ＨＩＲ）７０２、中（ＭＩＲ）７０４、および低（ＬＩＲ）７０６の各レベルの表現が示されている。しかし、本実施形態はそのようには限定されない。任意個数のコンパイル段階で型チェックが可能である。

表現の各レベルにおけるＩＲは、型チェッカ７０８によって型チェックされ得る。型チェッカ７０８は、コンパイルプロセスの各段階に、したがってＩＲの各表現に、１つまたは複数のルールセット７１０を適用するためのアルゴリズムまたは手続きを実装する。ルールセット７１０は、ソース言語、コンパイル段階、型付けの強さの程度等のようなさまざまな性質に基づいて選択される。

例えば、ソースコード７００が、Ｃ＋＋プログラミング言語で作成されたコードを含むと仮定する。Ｃ＋＋ソースコード７００は、まず、型付きＩＲのＨＩＲ７０２に翻訳される。必要であれば、この時点で、型チェッカ７０８が、任意個数の性質を判定するためにＨＩＲ７０２と対話することができる。そのような性質としては、コンパイル段階（ＨＩＲ）、与えられたソースコードのタイプ（Ｃ＋＋）、その言語が型付きかどうか（ｙｅｓ）、それがゆるく型付けされているかそれとも強く型付けされているか（ゆるく型付けされている）等が挙げられる。これらの性質に基づいて、型チェッカは、適切なルールのセットを選択することができる。ルールセットを選択した後、型チェッカは、そのルールセットに従ってＨＩＲを型チェックする。ＨＩＲがＭＩＲまたはＬＩＲにローレベル化された後は、それらの性質が再びアクセスされ、同一のルールセットが適切な場合も、異なるルールセットが適切な場合もある。

一実施形態では、型チェックルールの３つのセットを型チェッカに供給することができる。１つのセットは、Ｃ＃やＣＩＬを型チェックするために望ましい「強い」型チェックに対応し得る。もう１つのセットは、「強い」(strong)型チェックよりもゆるい(looser)型チェックである「弱い」(weak)型チェックに対応し得る。例えば、弱い型チェックルールセットは型キャストを許容することができる。型キャストとは、ある型の変数を、一度限りの使用のために別の型のようにふるまうようにする場合のことである。例えば、型intの変数は、char（文字）のようにふるまうようにすることができる。次のコードは、文字「Ｐ」を印字するために型キャストを使用している。

int a;
a = 80;
cout << (char)a;

このように、たとえ「ａ」が型intとして定義され、値８０が代入されていても、cout文は、型キャストにより変数「ａ」を型charとして扱うので、８０ではなく「Ｐ」（ＡＳＣＩＩ値８０）を表示することになる。

最後に、第３のセットは「表現」(representation)チェックに対応し得る。「表現」チェックは、unknown型の使用等により中間プログラム表現の一部で型情報を落とすことを可能にし、このような型情報をいつ落とすことができるか、あるいはunknown型を別の型でいつ置き換えることができるかを規定するルールを含むことができる。例えば、型Voidの値を返す関数の結果は、unknown型の変数に代入されることが禁止されてもよい。

さらに、単一のコンパイル段階で複数のルールセットを使用することができる。例えば、ソースコード７００は単一の言語を含むが、強く型付けされたセクションと、ゆるく型付けされたいくつかのセクションとを含むと仮定する。型チェッカは、ある特定の強く型付けされたセクションのＨＩＲに対してあるルールセットを使用し、ゆるく型付けされたコードセクションに対しては別のルールセットを使用することができる。

図８は、本明細書に記載のＩＲとともに使用するための型チェッカのブロック図である。型チェッカ８００は、異なるソース言語および／または異なるコンパイル段階に対応する任意個数のルールセットを入力として受け付けることができる。図８では、４個のルールセット８０２〜８０８が型チェッカ８００に提供されている。ルールセット８０２は、強い型付けを有する言語のＨＩＲに対するルールセットを表し、ルールセット８０４は、弱い型付けを有する言語のＨＩＲに対するルールセットを表し、ルールセット８０６は、型付けのない言語のＨＩＲに対するルールセットを表し、ルールセット８０８は、ＬＩＲに対するルールセットを表す。プログラムモジュール８１０は、ＨＩＲにおける強い型付けを有する言語を表し、プログラムモジュール８１２は、ＬＩＲにローレベル化された後のプログラムモジュール８１０を表す。

型チェッカ８００は、型チェックされるプログラムモジュールの性質に基づいて適切なルールセットを選択し、組み込まれている手続きまたはアルゴリズムを用いてプログラムモジュールに選択したルールセットを適用する。例えば、型チェッカ８００は、プログラムモジュール８１０（ＨＩＲにおける強い型付けを有する言語を表す）を型チェックするためにルールセット８０２（強い型付けを有する言語のＨＩＲに対するルールセットを表す）を選択することができる。その後、型チェッカ８００は、プログラムモジュール８１２（ＬＩＲにおける強い型付けを有する言語を表す）を型チェックするためにルールセット８０８（ＬＩＲに対するルールセットを表す）を選択することができる。

本明細書に記載の型チェックシステムのルールセットは、全く新しい言語に容易に拡張されるとともに、既存の言語の新しい特徴にも容易に拡張される。例えば、新しい言語が導入される場合、その新しい言語に対して新しいルールセットが単に作成される。ルールセットは型チェッカやコンパイラシステム自体とは別個であり、別個のエンティティとしてルールセットを受け付けるように設計されるので、新しい言語に対する新しいルールセットは、既存の型チェックシステムやコンパイラを再配布または更新することを必要とせずに配布することができる。同様に、例えばＸＭＬサポートをＣ＋＋に追加する場合のように、新しい特徴が既存の言語に追加される場合、種々のコンパイル段階におけるＣ＋＋に対応するルールセットは、その新しい特徴を処理するように動的に容易に再構成することができる。この場合も、新たなコアシステムを更新したり配布したりする必要はない。

ルールセットは、型に対する制約も可能にする。例えば、クラスが別のクラスを継承する場合に特定の型に対するサブタイピング(部分型化)が許容されるかどうかは、そのルールに記述される制約であり得る。もう１つの制約として、データがそのデータを含む仮想テーブルに変換可能かどうかを示すことが望ましい場合のような、ボックス(囲み)制約(boxed constraint)があり得る。他の制約として、サイズ制約や、同一型のプリミティブの必要性を示すプリミティブ型制約が挙げられる。ルールセットの他の部分と同様、新しい制約を必要に応じて追加することができる。

型チェッカによって使用されるルールセットは、ルールセットを作成するためのアプリケーションへのプログラミングインタフェースを通じて構築することができる。そのアプリケーションは、型付きＩＲの個別の命令に割り当てられたルールを用いてルールセットが型プリミティブの階層において表現されるように、ルールを構築することができる。この階層は、特定のプログラムモジュールまたはコンパイル単位に関連する型の種々の要素を明示的に表す型グラフの形式で提供することができる。シンボルや演算のようなＩＲ要素は、型システムの要素に関連づけられる。型グラフノードは、コンポーネント、ネストされた型、関数シグネチャ、インタフェース型、階層の要素およびその他の情報（例えば、ソース名およびモジュール／アセンブリ外部型要素への参照）のような、プリミティブ型および構築された型ならびにそれらの関係を記述する。

例外処理
ＳＤＡとともに使用するための本明細書に記載のＩＲは、Ｃ＋＋、ＭｉｃｒｏｓｏｆｔＣＬＲ、およびＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓ(登録商標)の構造化例外処理（ＳＥＨ）のような、さまざまな言語固有の例外処理モデルをサポートすることができる。

図９は、コンパイラバックエンド９４０によって、複数のソース言語（９０５〜９０８）に対しＩＲ(言語費依存中間表現)９３０において統一的例外処理を実装するシステム９００を示している。図９に示すように、システム９００は、複数のソースコード表現９０５〜９０８のそれぞれに対する中間言語（ＩＬ）表現９１０〜９１３を含む。中間言語（ＩＬ）表現９１０〜９１３は、ＩＬリーダ９２０によって構文解析すなわち読み取りが行われる。ＩＬリーダ９２０は、複数のＩＬ表現９１０〜９１３を単一のＩＲ９３０に翻訳する。ＩＬ表現は、ＩＲ９３０よりも高いレベルの中間表現であり、ＣＩＬ（ＭｉｃｒｏｓｏｆｔＣＬＲ）（Ｃ＃、ＶｉｓｕａｌＢａｓｉｃ、ＪＳｃｒｉｐｔ、Ｃ、およびＦＯＲＴＲＡＮの場合）およびＣ＋＋ＩＬ（Ｃ＋＋の場合）のような任意個数の周知の中間言語で表され得る。複数の言語に対する統一的な例外処理フレームワークを生成するシステム９００は、複数のソース言語に対する単一のＩＲリーダプロセスを有するように示されているが、このようなリーダを複数実装し、それぞれが１つまたは複数のＩＬ表現９１０〜９１３に対応するようにすることも可能である。

図１０Ａは、複数の異なるソース言語で表された例外処理コンストラクトに対する統一的な中間表現のセットを生成するためにＩＬリーダ９２０を使用する一般的な全体的方法１０００を示している。１０１０で、リーダ９２０がソフトウェアの中間言語表現（例えば、ソースコードファイルの中間言語表現）を受け取る。１０１５で、ファイルの読み取りすなわち構文解析を行い、ＩＬコードストリーム内の例外処理コンストラクトを識別する（１０２０）。次に、１０３０で、リーダ９２０（これは仮想マシンとみなすこともできる）が、前に１０２０で識別された例外処理コンストラクトの単一の統一的ＩＲを生成する。その後、このような例外処理フレームワークを使用することにより、コード最適化やコード生成のようなコンパイラバックエンドのプロセスを単純化することができる。

例外処理コンストラクトを有するソフトウェアの統一的ＩＲは、ソフトウェアの例外処理制御を明示的に表すことができる。図１０Ｂは、ソフトウェアの統一的ＩＲから実行ファイルを生成する方法１０５０を示している。このような方法は、例えば、コンパイラ等のソフトウェア開発ツールがソフトウェアの実行可能バージョン（例えば、マシン仕様コード等のオブジェクトコード）を生成する際に使用可能である。

１０６０で、統一的ＩＲを（例えばコンパイラ等のソフトウェア開発ツールにより）読み取る。例えば、図１０Ａの方法によって生成された統一的ＩＲを使用することができる。統一的中間表現への他の変換、翻訳、または最適化を必要に応じて実行することができる。

１０７０で、ソフトウェアのコンピュータ実行可能バージョンを（例えばコンパイラ等のソフトウェア開発ツールにより）生成する。ソフトウェアのコンピュータ実行可能バージョンは、統一的ＩＲに基づいて、ソフトウェアの例外処理制御フローを実装する。

図１１は、複数のＩＬ表現の形式で表された複数のソース言語内の例外処理コンストラクトの単純で統一的なＩＲを生成するシステムのもう１つの実施形態を示している。図１１に示すように、まず、Ｍｉｃｒｏｓｏｆｔの．ＮＥＴフレームワーク内でサポートされるソース言語グループ１１１０（例えば、Ｃ＃、Ｃ、ＭｉｃｒｏｓｏｆｔＶｉｓｕａｌＢａｓｉｃ、Ｊｓｃｒｉｐｔ、およびＦＯＲＴＲＡＮ）をＣＩＬ表現１１４０に変換する。しかし、他のソース言語との差異のため、Ｃ＋＋はＣＩＬ１１３０として知られる別の中間言語で表される。Ｃ＋＋ＩＬおよびＣＩＬ内の制御フローおよび例外処理モデルは基本的に異なる方法で表されるため、Ｃ＋＋ＩＬおよびＣＩＬ表現に対して別個のＩＬリーダ（１１３５および１１４５）を提供する必要があるかもしれない。

リーダ１１３５および１１４５はいずれも、それぞれのリーダ内に実装された適切なアルゴリズムを用いてそれぞれの中間言語コードストリームの構文解析すなわち読み取りを行う。これにより、例外処理命令の統一的フレームワークを用いて中間言語コードストリーム内の例外処理コンストラクトまたは命令または表現１１５０を表し、これがコンパイラバックエンド１１６０に提供される。

コード生成
ＳＤＡを用いて任意個数の実行アーキテクチャに対するソフトウェア開発ツールを生成するために、ＳＤＡは、共通ＩＲから任意個数のマシン依存表現を生成することが可能なコードジェネレータを含むことができる。図１２に、このようなコード生成のためのシステムの一実施形態を示す。この例では、ターゲット仕様データを有するターゲット実行アーキテクチャ仕様１２００がリターゲティングツール１２０２に供給される。別法として、仕様１２００、およびターゲット不問データを有する第２の仕様１２０４が、リターゲティングツール１２０２に供給されることも可能である。

リターゲティングツール１２０２は、１つまたは複数のコード生成コンポーネントに関係するデータについて仕様１２００／１２０４を構文解析するソフトウェアである。仕様１２００／１２０４内のデータに基づいて、リターゲティングツールは１つまたは複数のコンポーネントを作成する。各コンポーネントは、コード生成コンポーネントを作成するデータを提供する。

例えば、図１２の実施形態では、（例えばｌｅｘフォーマットの）トークン化(文字列などの分割)文法１２０６、および（例えばｙａｃｃフォーマットの）パーサ（構文解析）文法１２０８、ならびに一連のＣソースおよびヘッダファイル１２１０が生成される。

ｌｅｘを使用する例では、トークン化文法１２０６が、コンパイラの字句（lexical）解析コンポーネントを生成するのに必要なソースコードおよびヘッダファイル１２１４を作成するためにｌｅｘコンパイラ１２１２に提供される。ｌｅｘは、特にコンパイラ字句解析コンポーネントを作成するために設計された言語である。

ｙａｃｃを使用する例では、パーサ文法１２０８が、コンパイラの構文解析コンポーネントを生成するのに必要なソースコードおよびヘッダファイル１２１４を作成するためにｙａｃｃコンパイラ１２１６に提供される。ｙａｃｃは、ソースコード入力の構造と、そのような各構造が認識される時に呼び出されるべきコードとを指定する一般的ツールを提供する。

ソフトウェア開発ツールを構築するのに必要なコンポーネントを生成することを最終的に担当するソースコードは、リターゲティングツールによって生成される一連のＣソースおよびヘッダファイル１２１０／１２１４を、ＳＤＡのコンフィギュレーション内に含まれる共通フレームワーク１２１８と統合することによって生成される。例えば、字句および構文解析コンポーネントは、一連のＣソースおよびヘッダファイル１２１４を、共通フレームワークのソースコードおよびヘッダファイル１２１８と統合したものをコンパイルすることによって生成される。同様に、一連のＣソースおよびヘッダファイル１２１０を、共通フレームワークのソースコードおよびヘッダファイル１２１８と統合したものをコンパイルすることによって、他のソフトウェア開発ツールコンポーネントを生成することができる。

このように、Ｃソースおよびヘッダファイル１２１０／１２１４と共通フレームワークのソースコードおよびヘッダファイル１２１８を統合したものを表すソースコード１２２０をコンパイラ１２２２に提供することにより、ＳＤＡ内の共通フレームワークに準拠する仕様１２００に記述されたターゲット実行アーキテクチャをターゲットとするコンパイラ１２２４が生成される。

上記のように、ソフトウェア開発ツールコンポーネントは合法化テーブルを含む。このようなテーブルは、特定の形式のターゲット命令を識別するのに十分な情報を含む。合法化フレームワークは、命令選択、命令合法化、エンコーディング、およびリスティングコンポーネントによって使用される書式指標(form index)を提供することができる。

図１３は、本明細書に記載の技術とともに使用するのに適したコード生成のためのソフトウェアに実装される方法の一実施形態のフローチャートである。１３０２で、ターゲット実行アーキテクチャ仕様を処理することにより、ソースコードによって表現されるいくつかのコンポーネントを作成する。次に、１３０４で、ソースコンポーネントを統合して、ソースコードにより表現されるフレームワークを形成する。フレームワークは、ＳＤＡコアによって提供されること、またはＳＤＡコアとともに含まれることが可能である。必要であれば、ブロック１３０６で、カスタムコードも含めることができる。その後、ブロック１３０８で、統合されたソースコードをコンパイルすることにより、コード生成コンポーネントからソフトウェア開発ツールを作成する。

コアデータ構造の拡張
ＳＤＡのもう１つの実施形態では、ＳＤＡコアデータ構造を拡張可能なように構成する方法およびシステムが提供される。ＳＤＡコアデータ構造の拡張フィールドは、ソフトウェア開発シナリオ、ＳＤＡのどのコンフィギュレーションが構築されているか、あるいはターゲットソフトウェア開発ツールの個別の所望の特性に応じたその他の要因に依存してもよい。図１４Ａは、コアフレームワークを拡張することによってツールを構築するためにコアクラス定義を拡張する全体的プロセスを示している。まず、１４０２で、拡張（エクステンション）を指示するデータを受け取り、１４０４で、エクステンションによって指示されるように、ソフトウェア開発ツールのクラスを拡張する。

図１４Ｂは、ＳＤＡコアフレームワークを拡張するためにソフトウェアシナリオ依存エクステンションを使用することによってソフトウェア開発ツールを構築する全体的プロセスを示している。１４１０で、単純化されたオブジェクト定義言語（ＯＤＬ）を用いてコアクラスを定義することができる。次に、１４２０で、ソフトウェア開発シナリオ等の任意個数の要因に基づいて、特定のＳＤＡに対するコンフィギュレーションを決定することができる。ソフトウェア開発シナリオは、作成されているソフトウェア開発ツールのタイプ、ターゲット実行アーキテクチャ、ターゲット入力言語等を指示してもよい。次に、１４３０で、考慮されている要因の一部または全部に基づいて、オブジェクト記述言語を用いてエクステンションを定義することにより、コアクラスを拡張するのに必要な追加の、または異なるクラスメンバを表現する。

１４４０で、エクステンションをコアクラスに関連づけることにより、コアクラス定義を適切に拡張することができる。オブジェクト記述言語の構文は、コアクラスが拡張可能かどうかを定義するとともに、拡張クラスメンバの特定のセットを選択されたコアクラスのエクステンションとして関連づけるように図るべきである。さらに、プリプロセッサ翻訳プログラムを用いて、データまたはオブジェクト記述言語をプログラミング言語に翻訳することができる。このような前処理の後、１４５０で、拡張されたクラス定義をさらにコンパイルし、それを用いることにより、コアフレームワークを拡張することによって特定のコンフィギュレーションの他のソフトウェア開発ツールを実装することができる。

上記のプロセスを用いて、エクステンションの複数の異なる定義を別個に提供することができる。各エクステンションは、複雑な継承関係を維持することを必要とせずに、必要に応じてコアまたは基本クラスを単に拡張することができる。コアクラスの特定のエクステンションを提供するプログラマは、コアクラスの他のエクステンションについて知っている必要はない。これは、エクステンションを定義する作業を単純化するだけでなく、拡張されたコアクラスのユーザは、拡張されたコアクラスを使用するためにコアクラス名を知っているだけでよい。したがって、プログラマは、拡張されたクラス定義を使用する時に、クラス定義の間の複雑な階層関係を記憶する作業から解放されることが可能となる。

コアフレームワークプログラムを拡張するための１つの手法として、コアプログラムのソースコードファイルへのアクセスを取得し、オブジェクト記述言語を用いてエクステンションを定義することにより必要に応じてコアクラスを静的に拡張するというものがあり得る。その後、このエクステンションを処理することにより、エクステンションをコアクラスに自動注入し、拡張されたクラスを生成することができる。別法として、ソースコード言語によるソースコードに直接、エクステンションを手で追加することによって、拡張されたクラスを生成してもよい。図１５Ａは、この手法により、コアフレームワークファイル１５１０を拡張するためにコアフレームワークファイル１５１０にエクステンション１５２０、１５３０および１５４０を追加し、こうして拡張されたコアフレームワークファイル１５１０の一部としてエクステンション１５２０、１５３０および１５４０をコンパイルする様子を示している。

しかし、この手法はすべての目的に適しているとは限らない。というのは、１５２０、１５３０および１５４０のようなエクステンションの定義を提供するプログラマは、コアフレームワーク１５１０のソースコードにアクセス可能であることが必要となるからである。これは、コアフレームワーク１５１０のプロバイダがコアフレームワークのソースコードを秘密に保ちたいという状況では望ましくないことがある。その場合、図１５Ｂに示す第２の手法を使用することができる。これによれば、コアコンパイラフレームワーク１５５０は、エクステンション１５６０、１５７０、および１５８０とは別個のファイルとしてコンパイルされる。

この第２の手法では、エクステンション１５６０、１５７０および１５８０とコアフレームワーク１５５０が互いへのリンクを有するように適応させることにより、ランタイム時に、エクステンションがコアフレームワークにリンクされて、コアフレームワークを適切に拡張することができる。リンクは、特定のコアクラスを拡張するためにどのエクステンションを使用すべきかを指定する単純なリンクリストとして実装されてもよい。これは、必要な場合にコアクラスにエクステンションを適切に関係づける単純な名前付け規約を使用することによっても達成することができる。第１の手法と比べると、この第２の手法は、ランタイム時にリンクを行うという側面（aspect）に関連する追加的なオーバーヘッド処理を必要とすることがあるため、より低速の実装となる可能性がある。他方、この第２の手法は、コアフレームワークのソースコードにアクセスできない開発者によるコアクラスの拡張を可能にするというフレキシビリティを提供する。

図１６は、上記で図１５Ａを参照して示したように、コンパイル時の前にコアフレームワークプログラムに関係するクラスを静的に拡張する方法を示している。コアクラスおよびそのエクステンションは、オブジェクト記述言語を用いて定義することができる。コアクラスおよびエクステンションの定義は、同時に、あるいは一緒に生成される必要はない。しかし、エクステンションを追加するには、コアプログラムのソースコードへのアクセスが必要となる。

このようなクラス定義を取得した後、１６１０で、コアクラスおよびそのエクステンションの定義をＯＤＬプリプロセッサにより一緒に処理する。ＯＤＬプリプロセッサは、オブジェクト記述言語表現をソースコード表現に翻訳することができる。すると、１６２０で、ＯＤＬプリプロセッサによる前処理の結果は、コアクラスおよびそのエクステンションの定義をＣ＋＋のようなソースコード言語で表すヘッダファイルあるいは他のコードとなる。その後、１６３０で、コアクラスメンバおよび拡張クラスメンバを含む拡張されたクラス定義を有するヘッダファイルを、こうして拡張されたコアフレームワークに関係するコードの残りの部分とともにコンパイルすることにより、カスタム構成されたソフトウェア開発ツールを生成する。

図１７は、図１６のプロセスを実装する例示的システムを示している。図１７に示すように、コアクラス定義１７２０に対するエクステンションの複数の定義１７１０を、オブジェクト記述言語ファイルとして格納することができる。コアクラス定義およびエクステンション定義にそれぞれ対応するファイル１７１０および１７２０を受け取ることが可能なＯＤＬプリプロセッサ１７３０を提供することができる。プリプロセッサは、ファイル１７１０および１７２０を、それらのオブジェクト記述言語形式からソースコード表現１７４０に翻訳することも可能でなければならない。ソースコード表現は、コンピュータプロセッサによって実行可能な形式に最終的にコンパイルすることができるいかなる言語であってもよい。プリプロセッサ１７３０によって生成されるソースコード１７４０としては、クラス定義が通常格納されるヘッダファイルが挙げられる。プリプロセッサ１７３０によって出力されるソースコード１７４０の言語に適したソースコードコンパイラ１７５０を提供することができる。ソースコードコンパイラ１７５０は、ソースコード表現１７４０をコンパイルすることにより、コンパイラ等のソフトウェア開発ツールのようなコアソフトウェアプログラムのカスタマイズされた拡張バージョン１７６０を作成する。

図１８は、ランタイム時に適切なコアクラスにエクステンションをリンクすることにより拡張可能コアフレームワークソフトウェアプログラムのコアクラス定義を拡張する方法を示している。コアクラス定義およびエクステンションは、オブジェクト記述言語を用いて別個に表現することができる。記述言語は、コアクラス定義が動的に拡張可能であることを表現するのに適しているかもしれない。また、このような言語は、特定のコアクラス定義とそのエクステンションとの間の関連づけを表現するのに適しているかもしれない。１つのこのような好適な言語の構文について以下でさらに詳細に説明する。定義が表現された後、１８１０でＯＤＬプリプロセッサを使用することにより、１８２０で、オブジェクト記述言語表現による定義をソースコード表現に翻訳することができる。しかし、静的プロセス（図１６）とは異なり、図１８の動的プロセスでは、コアクラス定義は、ＯＤＬプリプロセッサによって、そのエクステンションの定義と一緒には処理されない。その代わりに、コアクラス定義に対応するソースコードヘッダファイルおよびクラスエクステンション定義に対応するソースコードヘッダファイルが別個に生成される。これらは、異なるＯＤＬプリプロセッサにより生成してもよいが、必ずしもそうする必要はない。さらに、１８３０で、コアクラス定義を含むヘッダファイルおよびエクステンション定義を含むヘッダファイルを別個にコンパイルすることにより、コンピュータにより実行可能な別個のファイルを作成する。しかし、１８４０で、ランタイム時に、クラスエクステンション定義を適切なコアクラス定義にリンクすることにより、定義の通りにコアクラスを拡張することができる。

図１９は、図１８のプロセスを実装する例示的システムを示している。図１９に示すように、クラスエクステンション定義がオブジェクト記述言語で提供され、ファイル１９１０に格納される。必ずしも各エクステンションが図示のように別個のファイルとして格納される必要はない。コアクラス定義もまたオブジェクト記述言語で提供され、ファイル１９２０に格納される。図１８に記載のプロセスによれば、コアクラス定義をオブジェクト記述言語表現からソースコード言語表現に翻訳することによってコアクラス定義を処理し、ヘッダファイル１９３５として格納するために、ＯＤＬプリプロセッサ１９２５が提供される。同様に、クラスエクステンションファイル１９１０を処理することによりエクステンションを含むソースコードヘッダファイル１９４０を生成するために、さらにもう１つのＯＤＬプリプロセッサ１９３０を提供することができる。クラスエクステンションヘッダファイル１９４０をコンパイルすることによりクラスエクステンション定義を含むコンピュータ実行可能ファイル１９６０を生成するために、ソースコードコンパイラ１９４５を提供することができる。同様に、コアクラス定義を含むヘッダファイル１９３５をコンパイルすることによりコアクラス定義を含むコンピュータ実行可能ファイル１９５５を生成するために、ソースコンパイラ１９５０を提供することができる。その後、ランタイム時に、コアクラスに対応する実行可能ファイル１９５５および拡張クラスに対応する実行ファイルが実行されると、コアおよび拡張クラス内に提供されるリンク１９７０により、コアクラスを適切に拡張することができる。

ソフトウェア成果物
図２０は、本明細書に記載の技術のコンピュータソフトウェア成果物(deliverable)のブロック図である。ソフトウェア成果物２０００はＳＤＡ２００２を含む。ＳＤＡ２００２は、本明細書に記載のＩＲ、例外処理モデル、型システム、コードジェネレータ、またはコアデータ構造拡張技術の１つまたは複数を実装するためのソースコードまたはオブジェクトを含むことができる。ＳＤＡ２００２は、任意個数のソフトウェア開発シナリオにおいて、さまざまなソフトウェア開発ツールのいずれかを生成するように構成されることが可能である。そのコンフィギュレーションとしては、以下のものに限定されないが、ネイティブコンパイラコンフィギュレーション２００４、ＪＩＴコンパイラコンフィギュレーション２００６、Ｐｒｅ−ＪＩＴコンパイラコンフィギュレーション２００８、解析ツールコンフィギュレーション２０１０、欠陥検出コンフィギュレーション２０１２、オプティマイザコンフィギュレーション２０１４、またはＣＤＫコンフィギュレーション２０１６が挙げられる。

ソフトウェア成果物は、ターゲットソフトウェア開発ツールを生成するために、好適なコンピュータシステムで実行することができる。コンポーネント２０１８が、コンピュータシステム上のソフトウェア成果物２０００／ＳＤＡ２００２に提供される。コンポーネント２０１８は、以下のものに限定されないが、ターゲット実行アーキテクチャに関連するデータ２０２０、クラス拡張宣言のセット２０２２、ターゲットソフトウェア開発ツールの入力言語に関連するデータ２０２４、および１つまたは複数の型ルールセット２０２６、の１つまたは複数を含むことができる。

ソフトウェア成果物は、選択されたコンフィギュレーションおよびコンポーネント２０１８に基づいてソフトウェア開発ルールを生成することができる。例えば、図２１は、図２０に記載のソフトウェア実行ファイルの一具体例を示すブロック図である。

ソフトウェア成果物２１００は、オプティマイザコンフィギュレーションでのＳＤＡ２１０２を含む。コンポーネント２１０４は、ｘ８６に関連するデータ２１０６、オプティマイザコンフィギュレーションと整合するクラス拡張宣言のセット２１０８、入力言語Ｃ＋＋に関連するデータ２１１０、および型チェックのための３個のルールセット２１１２（例えば、１つのセットは強い型チェックに対応し、１つは弱い型チェックに対応し、１つは表現型チェックに対応する）を含む。コンポーネント２１０４がソフトウェア成果物２１００／ＳＤＡ２１０２にリンクされることにより、オプティマイザ２１１４が作成される。オプティマイザ２１１４は、Ｃ＋＋言語で書かれたソースコードを入力とし、ｘ８６アーキテクチャをターゲットとする。

図２２は、本明細書に記載の技術のコンピュータソフトウェア成果物のもう１つの実施形態を示している。この実施形態では、ソフトウェア成果物２２００は、ＳＤＡ２２１０のバイナリ等のコンピュータ実行可能ファイルバージョンであり得る。その場合、ソフトウェア開発コンポーネント２２２０が（例えば、ソースコードにアクセスせずにランタイム時に）ソフトウェア成果物２２００に（例えば動的に）リンクされることが可能である。結果として得られるコンポーネントとソフトウェア成果物の組合せから、ソフトウェア開発ツール２２３０を作成することができる。

別法として、図２３に示すように、既存のソフトウェア開発ツール２３００を修正することができる。ソフトウェア開発ツール２３００は、本明細書に記載の種々の方法等において、ＳＤＡ２３１０を用いて生成することができる。そして、ソフトウェア開発ツールの修正バージョン２３３０を作成するために、新しいコンポーネント２３２０を作成し、ＳＤＡ２３１０にリンクすることができる。

さらにもう１つの実施形態では、ＳＤＡを用いて相互互換（inter-compatible）ソフトウェアツールを作成することができる。図２４は、ＳＤＡ２４１０を用いて生成された第１のソフトウェア開発ツール２４００のブロック図である。続いて、第２のソフトウェアツールの機能を含む１つまたは複数の新しいコンポーネント２４２０を作成し、バイナリ等の実行可能フォーマットのＳＤＡ２４３０にリンクすることにより、第２のソフトウェア開発ツール２４４０を形成することができる。第１および第２のソフトウェアツール２４００／２４４０は、それらがＳＤＡの（共通ＩＲのような）特性を共有していることにより、相互互換である。

例示的なＩＲフォーマットの拡張性
ＳＤＡに対して定義されるコアクラスが拡張可能であるので、ＩＲフォーマット自体も拡張可能である。例えば、新しいクラスメンバをコアクラスに追加し、ＩＲフォーマットで表現することができる。このような構成は、スケーラビリティの目的上、有益となり得る。例えば、ＪＩＴコンパイラのために（例えばパフォーマンスの理由から）軽量（ライトウェイト）データ構造を使用することが望ましい場合がある。他方、全プログラムの最適化コンパイラのためには、より包括的なデータ構造が適切な場合がある。

コアクラスは、本明細書に記載のオブジェクト記述言語メカニズムにより拡張可能である。したがって、コアクラスは、適切なソフトウェアコンポーネントまたはツールの開発時またはランタイム時のいずれにも（例えば、コアクラスのソースコードにアクセスせずに）拡張可能である。このようにして、システムは、ＩＲフォーマットのランタイム拡張性をサポートすることができる。

例示的なソフトウェア開発シナリオ非依存性
ソフトウェア開発シナリオ非依存性は、さまざまな方法で示すことができる。例えば、１つまたは複数のソフトウェア開発シナリオに関する非依存性である。例えば、実装は、プログラミング言語（例えば入力言語）、ソフトウェア実行アーキテクチャ（例えば、プロセッサまたは仮想マシン）、例外処理モデル、マネージドコードシナリオ等、またはそれらの任意の組合せから非依存であり得る。

例示的なオペレーティング環境
図２５は、ＳＤＡの一実施形態のためのオペレーティング環境として作用するコンピュータシステムの一例を示している。コンピュータシステムとしてはパーソナルコンピュータ２５２０があり、これは処理ユニット２５２１、システムメモリ２５２２、およびシステムメモリを含む種々のシステムコンポーネントを処理ユニット２５２１と相互接続するシステムバス２５２３を含む。システムバスは、メモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含む、いくつかのタイプのバス構造のいずれを備えてもよい。バス構造が使用するバスアーキテクチャとしては、いくつか例を挙げれば、ＰＣＩ、ＶＥＳＡ、マイクロチャネル（ＭＣＡ）、ＩＳＡおよびＥＩＳＡ等がある。システムメモリは、読み出し専用メモリ（ＲＯＭ）２５２４およびランダムアクセスメモリ（ＲＡＭ）２５２５を含む。起動中等にパーソナルコンピュータ２５２０内の要素間で情報を転送するのに役立つ基本ルーチンを含む基本入出力システム２５２６（ＢＩＯＳ）がＲＯＭ２５２４に格納される。パーソナルコンピュータ２５２０はさらに、ハードディスクドライブ２５２７、磁気ディスクドライブ２５２８（例えばリムーバブルディスク２５２９の読み書きを行う）、および光ディスクドライブ２５３０（例えば、ＣＤ−ＲＯＭディスク２５３１の読み出し、または他の光媒体の読み書きを行う）を含む。ハードディスクドライブ２５２７、磁気ディスクドライブ２５２８、および光ディスクドライブ２５３０は、それぞれハードディスクドライブインタフェース２５３２、磁気ディスクドライブインタフェース２５３３、および光ドライブインタフェース２５３４によりシステムバス２５２３に接続される。ドライブおよびそれらに関連するコンピュータ可読媒体は、パーソナルコンピュータ２５２０のためのデータ、データ構造、コンピュータ実行可能命令（ダイナミックリンクライブラリ、および実行可能ファイルのようなプログラムコード）等の不揮発性ストレージを提供する。上記のコンピュータ可読媒体の記載では、ハードディスク、リムーバブル磁気ディスクおよびＣＤに言及しているが、磁気カセット、フラッシュメモリカード、ディジタルビデオディスク、ベルヌーイカートリッジ等のような、コンピュータで読むことができる他のタイプの媒体も含み得る。

複数のプログラムモジュールが、ドライブおよびＲＡＭ２５２５に格納され得る。そのようなプログラムモジュールとしては、オペレーティングシステム２５３５、１つまたは複数のアプリケーションプログラム２５３６、他のプログラムモジュール２５３７、およびプログラムデータ２５３８がある。ユーザは、キーボード２５４０およびマウス２５４２等のポインティングデバイスを通じてパーソナルコンピュータ２５２０にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）としては、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナ等が挙げられる。これらおよび他の入力デバイスは、システムバスに結合したシリアルポートインタフェース２５４６を通じて処理ユニット２５２１に接続されることが多いが、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）のような他のインタフェースにより接続されてもよい。モニタ２５４７または他のタイプのディスプレイデバイスもまた、ディスプレイコントローラまたはビデオアダプタ２５４８のようなインタフェース経由でシステムバス２５２３に接続される。モニタに加えて、パーソナルコンピュータは通常、スピーカおよびプリンタのような他の周辺出力デバイス（図示せず）を含む。

パーソナルコンピュータ２５２０は、リモートコンピュータ２５４９のような１つまたは複数のリモートコンピュータへの論理接続を用いたネットワーク環境で動作し得る。リモートコンピュータ２５４９は、サーバ、ルータ、ピアデバイスまたは他の普通のネットワークノードであってよく、通常、パーソナルコンピュータ２５２０に関して前述した要素の多くまたはすべてを含む。ただし、図２５にはメモリストレージデバイス２５５０のみが例示されている。図２５に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）２５５１および広域ネットワーク（ＷＡＮ）２５５２を含む。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネットおよびインターネットで一般的である。

ＬＡＮネットワーキング環境で使用される場合、パーソナルコンピュータ２５２０はネットワークインタフェースすなわちアダプタ２５５３を通じてローカルネットワーク２５５１に接続される。ＷＡＮネットワーキング環境で使用される場合、パーソナルコンピュータ２５２０は通常、インターネットのような広域ネットワーク２５５２を通じて通信を確立するためのモデム２５５４等の手段を含む。モデム２５５４は、内蔵でも外付けでもよいが、シリアルポートインタフェース２５４６経由でシステムバス２５２３に接続される。ネットワーク環境では、パーソナルコンピュータ２５２０に関して図示したプログラムモジュールまたはその部分は、リモートメモリストレージデバイスに格納されてもよい。図示したネットワーク接続は単なる例示であり、コンピュータ間に通信リンクを確立する他の手段を使用してもよい。

代替形態
以上、例示的な実施形態の原理について図示し説明したが、当業者には明らかなように、実施形態は、このような原理から逸脱することなく、構成および細部において変更可能である。

多くの可能な実施形態を考慮すると、例示した実施形態は単なる例を含んでいるだけであり、本発明の範囲に対する限定と解釈してはならないことが認識されるであろう。むしろ、本発明は、特許請求の範囲によって規定される。したがって、本発明者等は、特許請求の範囲内に入るすべてのそのような実施形態を本発明として主張するものである。

さまざまなソフトウェア開発ツールを構築するためのＳＤＡを示すブロック図である。ＳＤＡを用いてソフトウェア開発ツールを作成する方法を示すフローチャートである。ＳＤＡを用いてソフトウェア開発ツールを作成する別の方法を示すフローチャートである。ＳＤＡを用いてソフトウェア開発ツールのコンポーネントを作成するシステムのハイレベルブロック図である。図３に示されているようなシステムを用いて作成された３つのターゲット実行アーキテクチャのそれぞれに対するコンパイラ、デバッガ、およびオプティマイザを示すブロック図である。ＳＤＡを用いて作成されたコンパイラにおける例示的なコンパイルプロセスを示すブロック図である。ソースの読み込みからハイレベルマシン非依存ＩＲを経てローレベルマシン依存ＩＲまでのＩＲ変換を順を追って示す最初の段階の図である。ソースの読み込みからハイレベルマシン非依存ＩＲを経てローレベルマシン依存ＩＲまでのＩＲ変換を順を追って示す後続の図である。ソースの読み込みからハイレベルマシン非依存ＩＲを経てローレベルマシン依存ＩＲまでのＩＲ変換を順を追って示すさらに後続の図である。ソースの読み込みからハイレベルマシン非依存ＩＲを経てローレベルマシン依存ＩＲまでのＩＲ変換を順を追って示す最後の段階の図である。コンパイルの種々の段階でＩＲを型チェックするコンパイラシステムの一実施形態のブロック図である。ＩＲとともに使用するための型チェッカのブロック図である。ＩＲにおいて統一的例外処理を実装するシステムを示す図である。ＩＬリーダを用いて例外処理コンストラクトのための中間表現の統一的なセットを生成する方法を示す図である。ソフトウェアの統一的ＩＲから実行ファイルを生成する方法を示す図である。複数のＩＬ表現の形式で表された複数のソース言語内の例外処理コンストラクトの単純で統一的なＩＲを生成するシステムのブロック図である。コード生成のためのシステムのブロック図である。コード生成のためのソフトウェアに実装される方法の一実施形態のフローチャートである。コアフレームワークを拡張することによってツールを構築するためにコアクラス定義を拡張する全体的プロセスを示す図である。ＳＤＡコアフレームワークを拡張するためにソフトウェアシナリオ依存エクステンションを使用することによってソフトウェア開発ツールを構築する全体的プロセスを示す図である。コアコンパイラフレームワークを拡張するためにコアコンパイラフレームワークにエクステンションを追加する手法を示す図である。コアコンパイラフレームワークがエクステンションとは別個のファイルとしてコンパイルされる手法を示す図である。コンパイル時の前にコアフレームワークプログラムに関係するクラスを静的に拡張する方法を示す図である。図１６のプロセスを実装する例示的システムを示す図である。ランタイム時に適切なコアクラスにエクステンションをリンクすることにより拡張可能コアフレームワークソフトウェアプログラムのコアクラス定義を拡張する方法を示す図である。図１８のプロセスを実装する例示的システムを示す図である。コンピュータソフトウェア成果物のブロック図である。図２０に記載のソフトウェア実行ファイルの一具体例を示すブロック図である。コンピュータソフトウェア成果物のもう１つの実施形態を示す。既存のソフトウェア開発ツールを修正するためのコンピュータソフトウェア成果物を示す図である。ＳＤＡからの相互互換ソフトウェアツールの作成を示す図である。ＳＤＡの一実施形態のためのオペレーティング環境として作用するコンピュータシステムの一例を示す図である。

符号の説明

１００ＳＤＡコア
１０２マネージドおよび／またはネイティブアプリケーションプログラムインタフェース（ＡＰＩ）
１０４ネイティブコンパイラ
１０６Ｐｒｅ−ＪＩＴコンパイラ
１０８ＪＩＴコンパイラ
１１０最適化ツール
１１２欠陥検出ツール
１１４解析ツール
１１６コンパイラ開発キット（ＣＤＫ）
３００ＳＤＡ
３０２仕様
３０４コンポーネント
３０６ツール
７００ソースコード
７０２ＨＩＲ
７０４ＭＩＲ
７０６ＬＩＲ
７０８型チェッカ
７１０ルールセット
８００型チェッカ
８０２，８０４，８０６，８０８ルールセット
８１０，８１２プログラムモジュール
９０５〜９０８ソース言語
９１０〜９１３中間言語（ＩＬ）表現
９２０ＩＬリーダ
９３０ＩＲ
９４０コンパイラバックエンド
１１１０ソース言語グループ
１１３０ＣＩＬ
１１３５，１１４５ＩＬリーダ
１１６０バックエンド
１２００，１２０４仕様
１２０２リターゲティングツール
１２０６トークン化文法
１２０８パーサ文法
１２１０Ｃソースおよびヘッダファイル
１２１２ｌｅｘコンパイラ
１２１４ソースコードおよびヘッダファイル
１２１６ｙａｃｃコンパイラ
１２１８共通フレームワークのソースコードおよびヘッダファイル
１２２０ソースコード
１２２２，１２２４コンパイラ
１５１０コアフレームワークファイル
１５２０，１５３０，１５４０エクステンション
１５５０コアコンパイラフレームワーク
１５６０，１５７０，１５８０エクステンション
１７１０エクステンションの定義
１７２０コアクラス定義
１７３０ＯＤＬプリプロセッサ
１７４０ソースコード表現
１７５０ソースコードコンパイラ
１７６０コアソフトウェアプログラムのカスタマイズされた拡張バージョン
１９２５，１９３０ＯＤＬプリプロセッサ
１９３５，１９４０ヘッダファイル
１９４５，１９５０ソースコードコンパイラ
１９５５コアクラス定義を含むコンピュータ実行可能ファイル
１９６０クラスエクステンション定義を含むコンピュータ実行可能ファイル
１９７０リンク
２０００ソフトウェア成果物
２００２ＳＤＡ
２００４ネイティブコンパイラコンフィギュレーション
２００６ＪＩＴコンパイラコンフィギュレーション
２００８Ｐｒｅ−ＪＩＴコンパイラコンフィギュレーション
２０１０解析ツールコンフィギュレーション
２０１２欠陥検出コンフィギュレーション
２０１４オプティマイザコンフィギュレーション
２０１６ＣＤＫコンフィギュレーション
２０１８コンポーネント
２０２０ターゲット実行アーキテクチャに関連するデータ
２０２２クラス拡張宣言のセット
２０２４ターゲットソフトウェア開発ツールの入力言語に関連するデータ
２０２６型ルールセット
２１００ソフトウェア成果物
２１０２ＳＤＡ
２１０４コンポーネント
２１０６ｘ８６に関連するデータ
２１０８クラス拡張宣言のセット
２１１０入力言語Ｃ＋＋に関連するデータ
２１１２ルールセット
２１１４オプティマイザ
２２００ソフトウェア成果物
２２１０ＳＤＡ
２２２０ソフトウェア開発コンポーネント
２２３０ソフトウェア開発ツール
２３００ソフトウェア開発ツール
２３１０ＳＤＡ
２３２０コンポーネント
２３３０ソフトウェア開発ツールの修正バージョン
２４００第１のソフトウェア開発ツール
２４１０，２４３０ＳＤＡ
２４２０コンポーネント
２４４０第２のソフトウェア開発ツール
２５２０パーソナルコンピュータ
２５２１処理ユニット
２５２２システムメモリ
２５２３システムバス
２５２４読み出し専用メモリ（ＲＯＭ）
２５２５ランダムアクセスメモリ（ＲＡＭ）
２５２６基本入出力システム（ＢＩＯＳ）
２５２７ハードディスクドライブ
２５２８磁気ディスクドライブ
２５２９リムーバブルディスク
２５３０光ディスクドライブ
２５３１ＣＤ−ＲＯＭディスク
２５３２ハードディスクドライブインタフェース
２５３３磁気ディスクドライブインタフェース
２５３４光ドライブインタフェース
２５３５オペレーティングシステム
２５３６アプリケーションプログラム
２５３７他のプログラムモジュール
２５３８プログラムデータ
２５４０キーボード
２５４２マウス
２５４６シリアルポートインタフェース
２５４７モニタ
２５４８ビデオアダプタ
２５４９リモートコンピュータ
２５５０メモリストレージデバイス
２５５１ローカルエリアネットワーク（ＬＡＮ）
２５５２広域ネットワーク（ＷＡＮ）
２５５３ネットワークインタフェース（アダプタ）
２５５４モデム

Claims

ソース言語で記述されたプログラムモジュールをコンパイルするためのコンパイラシステムであって、
プログラムモジュールを型チェックするための複数のルールセットと、
ソフトウェア開発シナリオ非依存の中間言語を表現する手段であって、該中間表現はレベルを有し、該中間表現のレベルは、ハイレベル、ミドルレベル、またはローレベルである、中間言語表現手段と、
前記複数の異なるソース言語の型表現を表す型システムであって、
前記ソース言語で記述されたプログラムモジュールが、ソース言語から前記ハイレベル中間表現に変換されたとき、型チェッカがルールセットに従ってハイレベル中間表現を型チェックし、
前記ソース言語で記述されたプログラムモジュールが、前記ハイレベル中間表現から前記ミドルレベル中間表現に変換されたとき、型チェッカがルールセットに従って前記ミドルレベル中間表現を型チェックし、
前記ソース言語で記述されたプログラムモジュールが、前記ミドルレベル中間表現から前記ローレベル中間表現に変換されたとき、型チェッカがルールセットに従って前記ローレベル中間表現を型チェックし、
前記ルールセットは、ソース言語、中間表現のレベル又は型付けの強さに基づいて選択される
型システムと、
複数の実行アーキテクチャをターゲットとするコードを生成するコードジェネレータと
を備え、
前記コードジェネレータは、前記複数の異なるソース言語に対する複数のプログラミング言語固有の例外処理をサポートすることが可能なコードを生成する、
ことを特徴とするコンパイラシステム。