JP2021501949A - マルチ・プロセッサ・システム用プログラミングの流れ - Google Patents

Abstract

高性能および低電力損失を求めて最適化された処理要素を伴うマルチ・プロセッサ・システム用の最適化を伴うコンパイル、ならびに処理要素をプログラムする関連方法のさまざまな実施形態を開示する。アプリケーション・ソース・コードを最初にコンパイルして中間表現にしてよい。最初のコンパイルに続いて、資源をマッピングして、通信合成を遂行してよい。マルチ・プロセッサ・システムの上に実行可能イメージをロードする前に、シミュレーションおよびデバッグを遂行してよい。各ステップで、最適化が可能であるかどうか確認を遂行してよく、確認結果を使用して１つまたは複数のステップを反復してよい。【選択図】図６

Description

（関連出願の相互参照）
発明者がＭｉｃｈａｅｌ Ｂ． Ｄｏｅｒｒ、Ｃａｒｌ Ｓ． Ｄｏｂｂｓ、Ｍｉｃｈａｅｌ Ｂ． Ｓｏｌｋａ、Ｍｉｃｈａｅｌ Ｒ． Ｔｒｏｃｉｎｏ、Ｋｅｎｎｅｔｈ Ｒ． Ｆａｕｌｋｎｅｒ、Ｋｅｉｔｈ Ｍ． Ｂｉｎｄｌｏｓｓ、Ｓｕｍｅｅｒ Ａｒｙａ、Ｊｏｈｎ Ｍａｒｋ Ｂｅａｒｄｓｌｅｅ、およびＤａｖｉｄ Ａ． Ｇｉｂｓｏｎである、「Ｍｅｍｏｒｙ−Ｎｅｔｗｏｒｋ Ｐｒｏｃｅｓｓｏｒ ｗｉｔｈ Ｐｒｏｇｒａｍｍａｂｌｅ Ｏｐｔｉｍｉｚａｔｉｏｎｓ（プログラム可能な最適化を有するメモリネットワークプロセッサ）」と題する米国特許第９，４３０，３６９号明細書は、あらゆる点で完全に本明細書に示されているように全体が参照により本明細書に組み入れられる。

本発明は、マルチ・プロセッサ・システムに関し、より詳細にはプロセッサの動作および実行の改善だけではなく、そのようなシステムを対象とするソフトウェアの開発にも関する。

一般的ハードウェアシステムの主要な目的は、完全なプログラム可能性を維持しながら、特定用途向け（プログラム可能ではない）ハードウェアの性能を達成することである。歴史的に、これら２つの概念は、両極端にある。特定用途向けハードウェアは、可能な最も効率的方法で特有の機能を遂行する、固定したハードウェア解決手段である。この解決手段は、通常は機能あたりのエネルギー、または１つもしくは複数の動作あたりのエネルギーに関して、ならびに製品の部分的費用に関係がある可能性がある（回路）面積あたりの機能に関して測定される。チップ製品の費用は、ダイ面積および最終パッケージを含む多くの要因からなる。費用はまた、製品を開発するためのエコシステム全体も考慮すべきである。このエコシステム費用は、特有のアプリケーションを特有のハードウェア解決手段に変換するための時間、システム全体を構成するのに必要な特有のハードウェア解決手段の数、およびカスタム化した通信およびメモリの構造によって特有のハードウェア解決手段のすべてを一体化するのにかかる時間などからなる。したがって、完全に一体化された解決手段は、カスタムな相互接続を伴う数多くの特有のハードウェア解決手段のすべてをサポートする必要があり、その結果、単一チップダイ上に非常に大きな面積要件をもたらす。歴史的に、この過程は、面積、エネルギー、および市場に出るまでの時間に関して非効率的な解決手段をもたらしてきた。

プログラム可能性の世界、および対象とするハードウェアの概念について考えるとき、ハードウェアアーキテクチャおよびソフトウェア開発様式の観点から見た市場または状況は、Ｉｎｔｅｌ、ＡＭＤ、およびＡＲＭが提供する汎用プロセッサ（Ｇｅｎｅｒａｌ Ｐｕｒｐｏｓｅ Ｐｒｏｃｅｓｓｏｒ、ＧＰＰ）、ＮＶＩＤＩＡおよびＡＭＤから得られるグラフィカル処理ユニット（Ｇｒａｐｈｉｃａｌ Ｐｒｏｃｅｓｓｉｎｇ、Ｕｎｉｔ、ＧＰＵ）、Ｔｅｘａｓ ＩｎｓｔｒｕｍｅｎｔｓおよびＡｎａｌｏｇ Ｄｅｖｉｃｅｓから得られるデジタル・シグナル・プロセッサ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ、ＤＳＰ）、Ｘｉｌｉｎｘ、Ａｌｔｅｒａなどから得られるＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、ＣａｖｉｕｍおよびＴｉｌｅｒａから得られるマルチ・コア・プロセッサ／メニー・コア・プロセッサ、ならびに特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ、ＡＳＩＣ）またはシステム・オン・チップ（Ｓｙｓｔｅｍ Ｏｎ Ｃｈｉｐ、ＳｏＣ）により代表される。

ＧＰＰは、汎用処理のためにある、すなわち、非常に古いが検証済みの、４０年以上にわたって考えられているハードウェアアーキテクチャに基づき、何でも屋になろうとしている。ＧＰＰの一般的目的は、サポートするオペレーティングシステム（たとえば、ＷｉｎｄｏｗｓおよびＬｉｎｕｘ（登録商標））を用いて、ユーザインタフェース（ｕｓｅｒ ｉｎｔｅｒｆａｃｅ、ＵＩ）、およびＭＳＷｏｒｄ、Ｅｘｃｅｌ、電子メールなどのような高度な対話型ＵＩを集約的に用いるアプリケーションを走らせることである。電力散逸に影響を及ぼすハードウェア特性は、マルチ・レベル・キャッシュ、複雑なハードウェアメモリ管理ユニット、大規模バス、および大規模クロック制御構造である。要するに、ＧＰＰは、これらのタスクを遂行するために大量の電力を散逸する。ソフトウェア開発の観点から、目標とするのは、最も簡単なソフトウェア・プログラミング・モデルであると考えられる。このモデルは、ユーザが連続的または直列に実行する単一スレッドを開発しているという観点から得られる。並列処理または複数のハードウェアスレッド（約４つよりも多いスレッド）を導入するとき、スレッドを効率的にプログラムする能力は、はるかに難解になる。これは、基本的に、並列スレッド動作をサポートするためのアーキテクチャが開発されなかったという事実、およびその結果、ハードウェアアーキテクチャは、管理するために途方もない量のオーバーヘッドとなる複雑性を必要とするという事実に起因する。ソフトウェア・プログラミング・モデルは、複数のソフトウェアスレッドの規定をサポートするために、ＡＰＩまたは言語の拡張を導入する必要がある。この拡張は、複雑である必要はないが、不都合なことに現在のＧＰＰハードウェアアーキテクチャは、そのような複雑性を必要とする。

高い水準では、世界のあらゆるスーパーコンピュータで長年の間Ｃ、Ｃ＋＋、Ｆｏｒｔｒａｎなどと共に広範囲にわたって使用されてきたＡＰＩは、１９９０年代初頭以来の業界標準であるＭＰＩ（ｍｅｓｓａｇｅ ｐａｓｓｉｎｇ ｉｎｔｅｒｆａｃｅ、メッセージ受渡インタフェース） ＡＰＩである。このＭＰＩは、非常に簡単で、よく理解されている、ハードウェア実装パスを制限しないＡＰＩである。ＭＰＩ ＡＰＩは、ハードウェアとは無関係な手法でソフトウェアスレッドおよび通信の規定を可能にする。このＭＰＩ ＡＰＩは、ＯｐｅｎＭＰ、Ｃｏａｒｒａｙ Ｆｏｒｔｒａｎ、ＯｐｅｎＣＬなど、ならびに想定される基礎となるモデルを本来規定する他の言語／ＡＰＩと異なり、したがってそれにより、解釈の柔軟性を制限し、前方互換性の問題を引き起こす。換言すれば、これらの他の言語／ＡＰＩを用いる場合、プログラマは、対象となるあらゆる新しいハードウェアプラットフォーム用にプログラムを書き直す必要がある。

ＧＰＵは、歴史的にデータ表示を処理し、対象とするために開発された。ＧＰＵは、ＧＰＵのコア外（外部）メモリモデル要件および内部コアメモリモデル要件によりアーキテクチャ上制約されるハードウェアである。コア外メモリは、ＧＰＰに対してＧＰＵメモリ空間内にデータを配置するように要求する。ＧＰＵは、次いでデータを得て、パイプライン方式でデータに対して動作し、次いでデータをＧＰＵの外部メモリ空間に戻して配置する。ここから表示装置にデータを送信することができる、またはＧＰＰは、一般的処理を受ける動作でさらに使用／記憶するために、ＧＰＵメモリ空間の外にデータを移動させる必要がある。ハードウェアが非効率なのは、（１）コア外ハードウェア制約をサポートするためにデータをあちこち移動させるために必要なサポート、ならびに（２）能率化されたパイプラインでデータを処理するように制約される、深くパイプライン化されたＳＩＭＤ機械に類似する限定的内部コアメモリ構造に起因する。その結果、データを処理するためのハードウェアが非効率であることに起因して電力利用が高い。使用するソフトウェア・プログラミング・モデルは、極度にハードウェア中心のＯｐｅｎＣＬ、ＣＵＤＡなどであり、したがって、効率を達成するには複雑であり、それほど移植可能ではなく、新しいハードウェア対象プラットフォームに移行しようとするとき、コードを書き換えて、再構成しなければならない。

ＤＳＰは、一般的信号処理用に縮小され、かつその処理を対象とした命令セットを用いるＧＰＰと考えることができる。ＤＳＰは、その兄貴分／姉貴分であるＧＰＰと同じキャッシュ、ＭＭＵ、およびバスの悩みを欠点として持つ。追加で、Ｖｉｔｅｒｂｉ／Ｔｕｒｂｏ復号または動き推定などの、実際に高スループットな任意の処理機能は、通常は商業市場での限定的な１組の特有の標準だけをサポートしている、限定的能力を伴うＡＳＩＣアクセラレータになっている。プログラミングモデルは、単一のハードウェアスレッドを対象とするときにはＧＰＰに類似するが、実行ユニットのハードウェアでは信号処理命令の取り組み方法であるので、任意の高効率を達成するには、関数のハンドアセンブリを必要とする、またはＤＳＰの会社のライブラリを使用する必要がある。上記で論じた並列ＧＰＰに類似する多重並列ＤＳＰアーキテクチャを作成するとき、問題はさらに悪化する。

ＦＰＧＡは、機能の規定をビットレベルで行うことができ、プログラム可能な有線構造によって論理機能間の通信が行われる、完全に異なるハードウェア取り組み方法である。このハードウェア取り組み方法は、途方もないオーバーヘッドおよび複雑性を導入する。これに起因して、ＶｅｒｉｌｏｇまたはＶＨＤＬなどのハードウェアプログラミング言語で効率的プログラミングを遂行する。プログラム可能な配線およびプログラム可能論理が、ＡＳＩＣ／ＳＯＣで必要とされるものに類似するが構造化された有線構成を伴うタイミング収束障害を導入することに起因して、コンパイル処理は、はるかにより複雑である。特有の機能に関する電力散逸および性能スループットは、ＦＰＧＡが、プログラムされたことだけを正確に遂行し、他に何も遂行しないことに起因して、一度に１つの機能だけを比較するとき、ＧＰＰまたはＧＰＵよりもはるかに良好であることは明らかである。しかしながら、ＧＰＰの能力のすべてをＦＰＧＡ内に実装しようとする場合、ＦＰＧＡは、ＧＰＰよりもはるかに劣ることは明らかである。ハードウェアレベルでプログラムすることの困難さは明らかである（たとえば、タイミング収束）。ＦＰＧＡのプログラミングは、実際には「プログラミング」ではなく、むしろ、論理／ハードウェア設計であり、ＶＨＤＬ／Ｖｅｒｉｌｏｇは、論理/ハードウェア設計言語であり、プログラミング言語ではない。

マルチ・コア・アーキテクチャ／メニー・コア・アーキテクチャのほとんどすべては、ハードウェアの観点から、コアプロセッサ、キャッシュ、ＭＭＵ、バス、およびすべての関連する論理を採用しており、これらをダイ上でこれらの周囲の通信バス／構成と共に複製している。マルチ・コア・アーキテクチャの例は、ＩＢＭのＣｅｌｌ、ＩｎｔｅｌおよびＡＭＤのクアッドコアおよびＮマルチコア、ＣａｖｉｕｍおよびＴｉｌｅｒａの製品、いくつかのカスタムＳｏＣなどである。追加で、マルチ・コア・アーキテクチャで達成される電力低減は、大部分は微々たるものである。このかなり明白な結果は、マルチコアの取り組み方法がＧＰＵの取り組み方法を単に複製しているにすぎないという事実から導出される。マルチ・コア・アーキテクチャで唯一実際に電力節約するのは、いくつかのＩＯドライバの低減であり、これらのドライバは、コアが以前は別個のダイ上にあったのに対して、追加された通信バス上で接続されるので、今では必要ない。したがって、マルチコアの取り組み方法は、より少ない電力をもたらすことはまったくない。第２に、ソフトウェア・プログラミング・モデルは、上記で論じたＧＰＰから改善されていない。

その他の取り組み方法で識別される問題のリストは、特有の市場では、性能効率および費用の目標を達成する唯一の方法が、特有のＧＰＰ、ＤＳＰ、およびＡＳＩＣアクセラレータを有するカスタムチップを開発して、ＳｏＣを形成することであると多くの場合考えられている理由から生じる。ＳｏＣは、電力損失および費用のバランスをとるために、必要な場合にプログラム可能性を、および特有の機能のためにＡＳＩＣ性能を提供する。しかしながら、今ではソフトウェア・プログラミング・モデルは、上記のプログラム可能なハードウェア解決手段のもとで論じたよりもさらにより複雑である。追加で、ＳｏＣは、完全にプログラム可能な解決手段に関連する柔軟性を失う結果となることがある。

これらのプログラム可能な解決手段すべての間で共通なことは、今日市場を代表するソフトウェア・プログラミング・モデルが、実行モデルおよび基盤となるハードウェアアーキテクチャを、それが目標としていることをより効率的にサポートするように外挿することに焦点を当てていることである。実行モデルの特徴をソフトウェア・プログラミング・モデルに完全に外挿することに焦点を当てることは、より広く普及した並列プログラミング言語のいくつかの重要な特性を考える際に観察することができる。今日使用されている取り組み方法を代表する数少ない例は、ＯｐｅｎＭＰ、ＯｐｅｎＣＬ、およびＭＰＩである。

ＯｐｅｎＭＰ（Ｏｐｅｎ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇ）は、共有メモリ多重処理プログラミングをサポートする業界標準ＡＰＩである。ＯｐｅｎＭＰは、１組のコンパイラ指示文、ライブラリルーチン、および実行時挙動に影響を及ぼす環境変数を備える。ＯｐｅｎＭＰは、並列化の方法によってマルチスレッディングをサポートし、それにより、マスタスレッド（連続して実行される一連の命令）は、指定された数のスレーブスレッドをフォーク（ｆｏｒｋ）し、タスクは、複数のスレーブスレッドの間で分割される。次いで、スレッドは、並列に走らされ、実行時環境は、使用量、機械負荷、および他の要因に応じて、異なる資源またはプロセッサにスレッドを配分する。環境変数に基づき、または機能を使用するコード内で、実行時環境によりいくつかのスレッドを割り当てることができる。並列に走らせることが意図されるコード部分に、それに応じて、その部分を実行する前に、スレッドを形成させるプリプロセッサ指令を用いて印をつける。Ｃ／Ｃ＋＋では、これは、＃ｐｒａｇｍａ（プラグマ）による。デフォルトにより、各スレッドは、コードの並列化部分を独立に実行する。タスク並列処理もデータ並列処理も達成することができる。並列化コードを実行した後、スレッドは、マスタスレッドに戻って連結し、マスタスレッドは、以後プログラムの最後まで継続する。スレッド間通信をサポートするために、ＯｐｅｎＭＰの拡張、またはＭＰＩ（Ｍｅｓｓａｇｅ Ｐａｓｓｉｎｇ Ｉｎｔｅｒｆａｃｅ）などの異なる業界標準ＡＰＩを使用することができる。

ＯｐｅｎＣＬ（Ｏｐｅｎ ｃｏｍｐｕｔｉｎｇ ｌａｎｇｕａｇｅ）は、中央処理装置（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＣＰＵ）、グラフィックス処理ユニット（ｇｒａｐｈｉｃｓ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＧＰＵ）、デジタル・シグナル・プロセッサ（ＤＳＰ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、および他のプロセッサを備える異種プラットフォームにわたり実行を可能にする目的でプログラムを書くためのフレームワークである。ＯｐｅｎＣＬは、抽象化を制限した、ハードウェアに近いインタフェースをサポートするように設計されている。このため、ＯｐｅｎＣＬに基づくプログラムは、一般に受け入れることができる性能を達成するために、基盤となるハードウェアに関する知識を前もって必要とする。ＯｐｅｎＣＬプログラムはまた、異なるハードウェアアーキテクチャを再対象化するときにリファクタリングを必要とする。

ＯｐｅｎＣＬは、いくつかの制限事項および追加事項と共にＡＮＳＩ Ｃプログラミング言語を使用してカーネルを書くことをサポートする。ＯｐｅｎＣＬは、関数ポインタ、再帰、ビットフィールド、可変長アレイ、および標準ヘッダファイルの使用を許可しない。言語は、ベクトル型およびベクトル動作を伴う並列化、同期、ならびに作業項目／グループを用いて作業するための関数をサポートするように拡張されている。アプリケーション・プログラミング・インタフェース（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ、ＡＰＩ）を使用して、プラットフォームを規定し、次いでプラットフォームを制御する。ＯｐｅｎＣＬは、コースレベルでタスクに基づく並列処理およびデータに基づく並列処理を使用して並列コンピューティングをサポートする。

ＭＰＩ（Ｍｅｓｓａｇｅ Ｐａｓｓｉｎｇ Ｉｎｔｅｒｆａｃｅ）は、標準化され言語に依存しない、拡張可能で移植可能なメッセージ受渡通信プロトコルＡＰＩである。ＭＰＩ ＡＰＩは、言語特有構文法（結合）を用いて、言語独立な方法で（ノード／サーバ／コンピュータインスタンスにマッピングされた）１組のプロセス間で、不可欠の仮想トポロジ、同期、および通信機能性を提供することを意図する。ＭＰＩ ＡＰＩ標準は、ポイント間通信および集合／ブロードキャスト通信の送信／受信動作ならびに処理の同期を規定可能な、さまざまな挙動のサポートを含むが、それらに限定されないライブラリルーチンのコアの構文法および意味論を規定する。ＭＰＩは今日、依然として高性能コンピューティングで使用される支配的モデルである。

マルチ・プロセッサ・システム上で並列実行するためのソフトウェアアプリケーションを開発するための他の取り組み方法は、一般に開発しやすさと並列実行の効率の間のトレードオフを必要とする。換言すれば、一般に、プログラマにとって開発過程が容易であるほど、それだけ結果として得られる実行可能プログラムは、ハードウェア上でより非効率に、並列に実行され、逆に、より効率的に並列実行するには、一般にプログラマがさらにかなり努力する必要がある、すなわち、非効率な処理を回避するために、プログラムをより詳細に設計して、対象とするハードウェアの、効率を高める特徴を使用する必要があるというのが事実であった。

したがって、アプリケーションおよびシステムレベルの視点からソフトウェア記述を容易にして、実行モデルおよび基盤となるハードウェアアーキテクチャを対象とするソフトウェア・プログラミング・モデルおよびその後ソフトウェア・プログラミング・モデルの使用を推進するための、改善されたシステムおよび方法が望まれる。この過程を通して、アプリケーションの効率的でプログラム可能な実装を可能にする仕組みを提供する改善もまた望まれる。

マルチ・プロセッサ・アレイ用アプリケーションソフトウェアを準備するためのさまざまな実施形態を開示する。マルチ・プロセッサ・アレイは、（たとえば、２Ｄまたは３Ｄグリッドの形の）複数のプロセッサと、プロセッサの間に散在した複数のメモリおよびルーティング要素とを備えてよい。ルーティング構成を提供して、ルーティング要素を使用してさまざまなプロセッサおよびメモリを接続してよい。

アプリケーション・ソース・コードを使用してフロント・エンド・コンパイルを遂行して、複数の中間表現および接続性情報を生成してよい。複数の中間表現のうちの特定の中間表現は、複数のタスクのうちの特定のタスクに対応してよく、接続性情報は、複数の接続を含み、特定の接続は、複数のタスクのうちの第１のタスクと複数のタスクのうちの第２のタスクの間の通信を指定する。複数の中間表現および接続性情報を使用して、マルチ・プロセッサ・アレイに含まれる物理資源にアプリケーション・ソース・コードに含まれる論理オブジェクトをマッピングして、資源マップを生成してよい。次いで、複数の接続内の接続ごとに、対応する実装を選択してよく、複数の中間表現を使用して第１の最適化動作を遂行して、複数の最適化中間表現を生成してよい。複数の最適化中間表現を使用して、実行可能コードを生成してよい。次いで、実行可能コードをシミュレートして、シミュレーション結果を生成してよく、マルチ・プロセッサ・アレイの上に実行可能コードをロードしてよい。

限定しない実施形態では、アプリケーション・ソース・コードを構文解析して、初期中間表現を生成してよく、初期中間表現を使用して少なくとも１つの第２の最適化動作を遂行して、複数の中間表現を生成してよい。複数の中間表現を使用して、複数の接続を生成するための、複数のタスク間の接続を決定してよく、プロジェクトデータベースに複数の中間表現および接続性情報を記憶してよい。マルチ・プロセッサ・アレイは、複数のプロセッサだけではなく、プロセッサ間に散在したメモリも含んでよい。論理オブジェクトをマッピングする際、複数のタスクのうちの特定のタスクを複数のプロセッサのうちの特定のプロセッサに割り当ててよく、特定のタスクに関連する変数を特定のプロセッサに関連する（たとえば、物理的に最も近い）対応するデータメモリに割り当ててよい。

マルチ・プロセッサ・システム（ｍｕｌｔｉ−ｐｒｏｃｅｓｓｏｒ ｓｙｓｔｅｍ、ＭＰＳ）の一実施形態を例示する構成図である。 データ・メモリ・ルータを一様に散在した処理要素からなる例示的ＭＰＳを示す。 動的に構成可能な処理要素に含まれるデータパスのある実施形態を例示する構成図である。 コンパイルの流れのある実施形態を描く流れ図である。 マルチ・タスク・コンパイルの流れのある実施形態を描く流れ図である。 最適化を伴うマルチ・プロセッサ・コンパイルのある実施形態を描く構成図である。 マルチ・プロセッサ・コンパイルの流れのある実施形態を描く流れ図である。 最適化を伴うマルチ・プロセッサ・コンパイルの流れのある実施形態を描く流れ図である。 フロント・エンド・コンパイルを遂行するための方法のある実施形態を描く流れ図である。 資源マッピングを遂行するための方法のある実施形態を描く流れ図である。 通信合成を遂行するための方法のある実施形態を描く流れ図である。

本開示は、さまざまな修正形態および代替形態が可能であるが、それらの具体的実施形態について、図面で例として示し、本明細書で詳細に記述する。しかしながら、それらの実施形態に対する図面および詳細な記述は、例示する特定の形態に本開示を限定することを意図するものではなく、それどころか、本発明は、添付の特許請求の範囲により規定されるような本開示の精神および範囲にはいるすべての修正形態、均等物、および代替形態を包含するためにあることを理解されたい。本明細書で使用する見出しは、編成するためだけにあり、本明細書の範囲を限定するために使用するものではない。本出願全体を通して使用するとき、単語「ｍａｙ（してよい、することがある）」は、義務的な意味（すなわち、しなければならない（ｍｕｓｔ）を意味する）ではなく、許可する意味（すなわち、する可能性を有することを意味する）で使用される。同様に、単語「ｉｎｃｌｕｄｅ（含む）」、「ｉｎｃｌｕｄｉｎｇ」、および「ｉｎｃｌｕｄｅｓ」は、含むが、限定されるわけではないことを意味する。

さまざまなユニット、回路、または他の構成要素について、１つまたは複数のタスクを遂行する「ように構成される」として記述することがある。そのような文脈では、「ように構成される」は、動作中に１つまたは複数のタスクを遂行する「回路を有すること」を一般に意味する構造についての包括的な詳述である。したがって、ユニット／回路／構成要素は、現在作動していないときでさえ、タスクを遂行するように構成することができる。一般に、「ように構成される」に対応する構造を形成する回路は、ハードウェアの回路を含んでもよい。同様に、さまざまなユニット／回路／構成要素について、説明の便宜上、１つまたは複数のタスクを遂行するとして記述することがある。そのような記述は、「ように構成される」という語句を含むと解釈されるべきである。１つまたは複数のタスクを遂行するように構成されたユニット／回路／構成要素について記載することは、そのユニット／回路／構成要素に関して米国特許法第１１２条段落６の解釈を引用することを明示的に意図するものではない。より一般的には、任意の要素の記載は、用語「ための手段（ｍｅａｎｓ ｆｏｒ）」または「ためのステップ（ｓｔｅｐ ｆｏｒ）」が具体的に記載されない限り、その要素に関して米国特許法第１１２条段落６の解釈を引用することを明示的に意図するものではない。
実施形態の詳細な記述
用語

コンピュータシステム―用語「コンピュータシステム」は、パーソナル・コンピュータ・システム（ＰＣ）、メインフレーム・コンピュータ・システム、ワークステーション、ネット家電、インターネット家電、携帯情報端末（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ、ＰＤＡ）、グリッド・コンピューティング・システム、もしくは他の機器、または機器の組合せを含む、さまざまなタイプのコンピューティングシステムまたは処理システムのいずれかを指す。一般に、記憶媒体から得られる命令を実行する少なくとも１つのプロセッサを有する任意の機器（または機器の組合せ）を包含するように、用語「コンピュータシステム」を広く規定することができる。

ソフトウェアアプリケーション―用語「ソフトウェアアプリケーション」（本明細書では単に「アプリケーション」とも呼ばれる）は、その通常の意味の広さを完全に有することが意図され、１つまたは複数のメモリに記憶して、１つまたは複数のプロセッサにより実行してよい任意のタイプのプログラム命令、コード、スクリプト、および／もしくはデータ、またはそれらの組合せを含む。代表的ソフトウェアアプリケーションは、Ｃ、Ｃ＋＋、Ｆｏｒｔｒａｎ、Ｊａｖａ（登録商標）、アセンブリ言語などのようなテキストに基づくプログラミング言語で書かれたプログラム、グラフィカルプログラム（グラフィカルプログラミング言語で書かれたプログラム）、アセンブリ言語プログラム、機械語にコンパイルされたプログラム、スクリプト、および他のタイプの実行可能ソフトウェアを含む。一般にプログラムは、１つまたは複数のデータ構造を指定し、かつ１つまたは複数の機能を遂行するためにデータ構造内のデータに関して行う手続きステップを指定する１組の命令である。プログラムは、多くの場合、特有の機械アーキテクチャを対象とする。より抽象的には、プログラムの手続きステップを、プログラムのアルゴリズムと呼んでよい。

アプリケーションは、マルチ・プロセッサ・システム（ＭＰＳ）の１つまたは複数のプロセッサ上で実行されてよく、ＭＰＳのローカルメモリの１つまたは複数からデータを読み出してよい、および／またはそこにデータを書き込んでよい。アプリケーションは、１つまたは複数の計算タスク（または単に「タスク」）を含んでよく、その場合、各タスクは、典型的にはＭＰＳの単一プロセッサ上で走らされ、１つまたは複数のアプリケーションからの１つまたは複数のタスクと、プロセッサを共有してよい。アプリケーションは、特定の機能または動作を遂行してよい。アプリケーションが２つ以上のタスクを含む場合、タスクは、互いに通信して、機能または動作を遂行してよい。

ＭＰＳは、たとえばアプリケーションが互いに並列に実行される場合、複数のアプリケーションを同時に実行してよい。アプリケーションは、互いに通信してよく、アプリケーションにより遂行されるそれぞれの機能または動作は、互いの上に構築されて、より大きな、またはより高水準の機能または動作を遂行してよい。

ソフトウェア・プログラミング・モデル―ソフトウェア・プログラミング・モデルは、簡単に言うと、機械および機械の動作環境に関するユーザの視点である。ソフトウェア・プログラミング・モデルは、アプリケーションを書くことができる言語（または複数の言語）だけではなく、１つまたは複数の言語で直接表現された、抽象化されカプセル化された機能性を提供するライブラリも含む。ソフトウェア・プログラミング・モデルはまた、アプリケーションが自身の外部にあるエンティティ（Ｉ／Ｏ、拡張メモリなど）と対話し、かつアプリケーションに関するメタ情報（たとえば、性能の制約または要件）を表現する仕組みを含む。プログラミングモデルの２つの主要な部分は、並列処理をどのように表現するか、またはアプリケーションから並列処理をどのように導出するかを表す制御モデル、ならびにアプリケーションの並列エンティティが情報をどのように共有するかを表す通信モデルである。

ソフトウェア・プログラミング・モデルは、アプリケーションを最終的に実行するときに発生する実際の制御およびデータの流れ、ならびに通信についての「理想化した」視点を提示する。動作の意味論は、基になる実装が「まるで」ソフトウェア・プログラミング・モデルで記述したように正確に遂行されるようなものであり、行われる実際のステップは、同じ効果（結果）を得る限り重要ではない。実際の実装ステップは、効率性の理由でコードおよび／またはデータサイズ、速度、電力消費などが異なってよい。

ソフトウェア・プログラミング・モデルの重要な考慮事項は、ソフトウェア・プログラミング・モデルが、ユーザにとって好都合で自然な直感的用語でアプリケーション（およびその動作）の表現をサポートする仕組みをユーザに同時に提供し、一方ではさらにまた、ツールセット（コンパイラなど）を通して、次いで実行モデルのもとで、アプリケーションを正しく効率的に処理するのをサポートするのに十分な情報を取り込むことである。

ハードウェア・プログラミング・モデル／実行モデル―ハードウェア・プログラミング・モデルまたは実行モデルは、アプリケーションをどのように実行するかを表す。ハードウェア・プログラミング・モデルまたは実行モデルは、アプリケーションの論理オブジェクトおよびデータオブジェクトに対応する１組の情報をどのように表現するか、およびその情報を経時的に処理して、アプリケーションが指定する機能をどのように達成するかを規定する。システムツール（コンパイラ、並列処理抽出器、配置配線など）の目的は、アプリケーションをそのソフトウェア・プログラミング・モデルの表現から、対応する実行モデルの表現に変換することである。実行モデルは、ソフトウェア・プログラミング・モデルにより（たとえば、ライブラリを通して）記述する機能性をサポートするために必要な仕組みだけではなく、（たとえば、Ｏ／Ｓを通して）ハードウェアの使用を監視し、調停し、管理するために必要な仕組みも含む。

実行モデルは、ソフトウェア・プログラミング・モデルにかなり密接に対応してよい、またはかなり異なってよく、ソフトウェア・プログラミング・モデルの異なる側面は、実行モデルに直接対応する程度が異なってよい。対応の度合いは、基盤となるハードウェアアーキテクチャが最初の（ソフトウェア）プログラミングモデルにどれだけ密接に類似しているかに関係がある。類似度が近いほど、それだけ対応が高度になる。

基盤となるハードウェアアーキテクチャ―基盤となるハードウェアアーキテクチャは、計算が実行される物理機器のアーキテクチャである。このレベルでは、すべての動作は、機器が行う物理動作に直接対応する。基盤となるハードウェアアーキテクチャについて記述してよい抽象化のレベルは、高レベルの概念アーキテクチャ（評価、シミュレーション、特徴分析、および設計空間探索中のトレードオフ分析に有用である）から低レベルの実装アーキテクチャ（製作すべき機器の物理的設計を推進するのに有用である）まで変わる可能性がある。実装レベルでさえ、基盤となるハードウェアアーキテクチャの異なるインスタンスは、能力または容量が変わってよい。たとえば、一方のインスタンスは、１０×１０のグリッドの処理ユニットを実装してよく、一方では、別のインスタンスは、６×６のグリッドだけを実装してよい。容量が異なるが、各インスタンスは、基盤となるハードウェアアーキテクチャと相変わらず整合性がとれている。

自動的に―ユーザ入力が活動または動作を直接指定または遂行することなく、コンピュータシステム（たとえば、コンピュータシステムが実行するソフトウェア）または機器（回路、プログラム可能なハードウェア素子、ＡＳＩＣなど）により遂行される活動または動作を指す。したがって、用語「自動的に」は、ユーザが操作を直接行うための入力を提供する、ユーザにより手動で行われる、または指定される操作とは対照をなす。自動手順は、ユーザにより提供される入力により開始されてよいが、「自動的に」遂行される後続の動作は、ユーザにより指定されない、すなわち、「手動で」行われず、この場合、ユーザは、遂行すべき各活動を指定する。たとえば、ユーザが各フィールドを選択し、情報を指定する入力を提供することにより（たとえば、情報をタイプし、チェックボックス、ラジオボタン選択などを選択することにより）電子式フォームに必要事項を書き入れることは、たとえコンピュータシステムがユーザの活動に応答してフォームを更新しなければならなくても、フォームに必要事項を手動で書き入れることになる。コンピュータシステムは、フォームに必要事項を自動的に書き入れられてよく、この場合、どのユーザ入力もフィールドへの回答を指定することなく、コンピュータシステム（たとえば、コンピュータシステム上で実行されるソフトウェア）がフォームのフィールドを解析し、フォームに書き込む。上記に示したように、ユーザは、フォームの自動書込みを起動してよいが、フォームを実際に書き込むことには関与しない（たとえば、ユーザがフィールドへの回答を手動で指定するのではなく、むしろ、フィールドが自動的に完成される）。本明細書は、ユーザが行った活動に応答して、操作が自動的に遂行されるさまざまな例を提供する。

処理要素（Ｐｒｏｃｅｓｓｉｎｇ Ｅｌｅｍｅｎｔ、ＰＥ）―マルチ・コア・プロセッサ内の単一のプログラム可能なコア。

データメモリ―１つまたは複数のＰＥが使用するデータを記憶するために使用するメモリ。

Ｉ／Ｏポート―チップ外からコンピュータプロセッサの中への、またはそこから外への接続。

ルート―２つのメモリ間でデータを転送するために使用することができる、２つのデータメモリ間の物理接続。

直接メモリアクセス（Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ、ＤＭＡ）―ルートを使用して２つのデータメモリ間でデータを転送するための方法。ＤＭＡアクセスは、ＰＥを通してデータを転送しない。

共有メモリ―２つ以上のタスクがアクセス可能なデータメモリに記憶したデータ。

タスク―特有の機能を実装するアプリケーション・ソース・コードからなる計算ユニット。タスクは、マルチ・コア・プロセッサ上の１つまたは複数のＰＥに割り当てられる。

変数―シンボル名と対になった記憶場所。変数は、タスク内で参照され、タスクがアクセス可能なデータメモリ内の１つまたは複数の場所に割り当てられる。

入力／出力（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ、ＩＯ）―ＩＯポートを通してチップ外から読み出され、チップ外に書き込まれるデータ。

通信（Ｃｏｍｍｕｎｉｃａｔｉｏｎ、Ｃｏｍｍ）―タスクまたはＩＯと、データを転送するために使用する２つ以上の他のタスクとの間の抽象的接続。ルート、共有メモリ、または任意の他の利用可能な物理資源を使用してｃｏｍｍを実装することができる。

通信ＡＰＩ―タスク間、またはＩ／Ｏとタスクの間でデータを転送するために使用するＭＰＩ（Ｍｅｓｓａｇｅ Ｐａｓｓｉｎｇ Ｉｎｔｅｒｆａｃｅ）などの１組のルーチンおよびプロトコル。

資源マッピング―抽象オブジェクト（タスク、変数、ｃｏｍｍ、Ｉ／Ｏなど）をプロセッサチップ上の物理資源に割り当てる処理。手作業で、自動的に、または両方の組合せで、すべての資源をマッピングしてよい。

タスクマッピング―タスクをＰＥに、およびＩＯをＩＯポートに割り当てる資源マッピングステップ。

変数配分―変数をデータメモリにマッピングし、変数のためにデータメモリ内のアドレス空間を配分する資源マッピングステップ。

Ｃｏｍｍマッピング―共有メモリまたはルートなどの物理資源に通信を割り当てる資源マッピングステップ。

中間表現（Ｉｎｔｅｒｍｅｄｉａｔｅ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ、ＩＲ）―ソースコードを表すためにコンパイラが内部で使用するデータ構造。ＩＲは、最適化および変換など、さらに処理する助けになる。

図１を参照すると、マルチ・プロセッサ・システム（ＭＰＳ）の一実施形態を例示する構成図が描かれている。例示する実施形態では、ＭＰＳ１０は、複数の処理要素（ＰＥ）と、データおよび命令を互いに通信するように連結された、動的に構成可能なコミュニケータまたは動的に構成可能な通信要素と呼ばれることもある複数のデータ・メモリ・ルータ（ｄａｔａ ｍｅｍｏｒｙ ｒｏｕｔｅｒ、ＤＭＲ）とを含む。本明細書で使用するとき、ＰＥはまた、ＰＥノードと呼ばれることもあり、ＤＭＲはまた、ＤＭＲノードと呼ばれることもある。

処理システム（ＭＰＳ）１０は現在、ＧＰＭＣ、ＤＳＰ、ＦＰＧＡ、またはＡＳＩＣを使用するさまざまなシステムおよびアプリケーションのいずれでも使用されてよい。したがって、たとえば、処理システム１０は、さまざまなタイプのコンピュータシステム、または計算を必要とする他の機器のいずれでも使用されてよい。企図される一実施形態では、デジタルビデオ表示システムで単一の処理機器として処理システム１０を使用する。

一実施形態では、ＰＥは、データを操作するように構成された１つまたは複数の算術論理演算装置（ａｒｉｔｈｍｅｔｉｃ−ｌｏｇｉｃ ｕｎｉｔ、ＡＬＵ）、ＡＬＵを制御するように構成された１つまたは複数の命令処理ユニット（ｉｎｓｔｒｕｃｔｉｏｎ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＩＰＵ）、命令またはデータを保持するように構成された１つまたは複数のメモリ、ならびにさまざまな種類のマルチプレクサおよび復号器を含んでよい。そのような実施形態は、いくつかのポート（「プロセッサポート」）を含んでよく、ＤＭＲに接続するように構成されてよいポートがあれば、他のＰＥに接続するように構成されてよいポートもある。

一実施形態では、ＤＭＲは、データおよび命令を保持するように構成された１つまたは複数のランダム・アクセス・メモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ、ＲＡＭ）と、構成可能なコントローラと、クロスバスイッチなどのネットワークスイッチと、レジスタと、マルチプレクサとを含んでよい。そのような実施形態は、複数のポートを含んでよく、ＰＥに接続するように構成されてよいポート（本明細書ではＰＥタイプのポートと呼ばれる）があれば、ＤＭＲに接続するように構成されてよいポート（本明細書ではＤＭＲタイプのポートと呼ばれる）もある。任意の所与のポートでは、ＤＭＲとの間で接続するために構成されていようがＰＥとの間で接続するように構成されていようが、特定のクロックサイクルでそのような所与のポートを通して転送可能なデータの量は、さまざまな実施形態で変わってよいことが留意される。たとえば、一実施形態では、クロックサイクルあたり１ワードのデータを転送するように所与のポートを構成してよいのに対して、別の実施形態では、クロックサイクルあたり複数ワードのデータを転送するように所与のポートを構成してよい。さらに別の実施形態では、所与のポートは、時分割多重などの技法を採用して、複数クロックサイクルにわたり１ワードのデータを転送してよく、それにより、ポートを備える物理接続の数は低減される。

ＭＰＳ１０の一実施形態では、各ＰＥは、命令用に確保された小規模ローカルメモリを含んでよく、非常に少ないローカルデータ記憶領域を含んでよい。そのような実施形態では、各ＰＥに隣接するＤＭＲは、所与のＰＥにオペランドを提供するように構成されてよい。特定の実施形態については、多くのＰＥ命令では、所与のＰＥは、１クロックサイクル内に、隣接するＤＭＲからオペランドを読み出し、ＡＬＵ動作を実行し、所与の隣接するＤＭＲにＡＬＵの結果を記憶してよい。それにより、１つのＰＥから得られるＡＬＵの結果は、実行直後のクロックサイクルでいくつかの他のＰＥに利用可能になってよい。この方式で結果を作り出すことにより、隣接するＰＥの実行が密接に調和可能に、または「密結合」可能になってよい。

本明細書で使用するとき、所与のＤＭＲまたはＰＥの観点から、隣接するＤＭＲまたはＰＥは、特定の待ち時間の範囲内に所与のＤＭＲまたはＰＥからアクセスすることができるＤＭＲまたはＰＥを指す。いくつかの実施形態では、隣接関係の範囲を規定する待ち時間は、たとえばクロック速度などの要因に応じて変わってよい。さらに、いくつかの実施形態では、複数の隣接度を規定してよく、隣接度は、異なるアクセス待ち時間に対応してよい。たとえば、一実施形態では、「最も近い隣接」を、データを要求する同じクロックサイクルの間にデータを供給することができる機器と規定してよく、「次に最も近い隣接」を、データ要求後の１クロックサイクル以内にデータを供給することができる機器と規定してよいなどである。他の実施形態では、他の指標を使用して、隣接関係を定量化してよいことが企図される。

所与のＭＰＳの実施形態では、いくつかのＤＭＲおよびＰＥは、他のＤＭＲおよびＰＥに論理的に近接してよい。本明細書で使用するとき、「論理的に近接した」は、一方のＤＭＲと別のＤＭＲ、または一方のＤＭＲと一方のＰＥなど、２つの機器間の関係を指し、その結果、一方の機器の１つまたは複数のポートは、介在するＤＭＲまたはＰＥを通過することなく他方の機器の対応するポートに直接接続される。さらに、所与のＭＰＳの実施形態では、いくつかのＤＭＲおよびＰＥは、他のＤＭＲおよびＰＥに物理的に近接してよい。本明細書で使用するとき、「物理的に近接した」は、一方のＤＭＲと別のＤＭＲ、または一方のＤＭＲと一方のＰＥなど、２つの機器間の関係を指し、その結果、他のどのＤＭＲもＰＥも、２つの機器の間に物理的に配置されない。

いくつかのＭＰＳの実施形態では、論理的および／または物理的に近接するＤＭＲおよびＰＥなどの機器はまた、隣接している、または隣接機器である。しかしながら、いくつかの実施形態では、所与の機器間の論理的および／または物理的近接は、所与の機器間の隣接関係または隣接関係の特定の度程を必然的に伴うわけではないことが留意される。たとえば、一実施形態では、一方のＤＭＲは、かなり距離を離して配置した別のＤＭＲに直接接続されてよい。そのような対は、論理的に近接しているが、物理的に近接しておらず、一方のＤＭＲから他方のＤＭＲへの信号伝播時間は、大きすぎて、隣接の待ち時間要件を満足させることができないことがある。同様に、一実施形態では、一方のＤＭＲは、別のＤＭＲに物理的に近接しているが、別のＤＭＲに直接接続されず、したがって、別のＤＭＲに論理的に近接していないことがある。一方のＤＭＲから他方のＤＭＲへのアクセスは、１つまたは複数の中間ノードを横断してよく、結果として得られる通過遅延は、大きすぎて、隣接の待ち時間要件を満足させることができないことがある。

ＭＰＳ１０の所与の実施形態の技術および実装に応じて、ＤＭＲの複数のポートの特有の数だけではなく、ＤＭＲメモリのサイズも、全体の所望の実行速度およびＤＭＲのサイズとバランスをとってよい。たとえば、ＤＭＲの一実施形態は、４つのＰＥタイプのポート、４つのＤＭＲタイプのポート、および４Ｋワードのメモリを含んでよい。そのようなＤＭＲの実装形態は、直接メモリアクセス（ＤＭＡ）の仕組みを提供するように構成されてよい。ＤＭＡの仕組みは、ＰＥが結果を計算している間、所与のＤＭＲが別のＤＭＲとの間で、またはＭＰＳ１０の外部の場所との間で、データを効率的にコピーすることができるようにしてよい。

ＭＰＳ１０の一実施形態では、いくつかの異なる方法の１つで、ＤＭＲ間でデータおよび命令を転送してよい。ＭＰＳ１０内のすべてのメモリに直列バスを提供してよく、そのようなバスを使用して、外部メモリからＭＰＳ１０を初期化してよい、またはＭＰＳデータ構造の試験をサポートしてよい。短距離転送では、所与のＰＥをプログラムして、所与のＰＥの隣接ＤＭＲ間でデータを直接移動させてよい。より長い距離にわたりデータまたは命令を転送するために、ＤＭＲのネットワーク内で通信経路を動的に作成し、消滅させてよい。

そのようなより長い距離をデータ転送するために、ＭＰＳ１０内部で相互接続されたＤＭＲのネットワークは、通信経路用切替えルーティング機構（ｓｗｉｔｃｈｅｄ ｒｏｕｔｉｎｇ ｆａｂｒｉｃ、ＳＲＦ）を構成してよい。そのような実施形態では、ＳＲＦ内の通信経路を管理するための方法が少なくとも２つ存在してよい。第１の方法は、大域プログラミングによるものであり、そこでは、パスは、ソフトウェア制御により（たとえば、人間のプログラマにより、またはルーティング能力を有するコンパイラにより）選択されてよく、命令は、クロスバを適切にプログラムするためにＤＭＲ構成コントローラの中に符号化されてよい。経路を作成するために、その経路に沿ったあらゆるＤＭＲは、特定のルーティング機能を用いて明示的にプログラムされてよい。経路が頻繁に作成され、消滅させられる動的環境では、多数のクロスバ構成コードを必要とすることがあり、さらにまた、コードの記憶領域は、潜在的に制限されたＤＭＲのＲＡＭ資源を消費することがある。

通信経路を管理するための第２の方法は、「ワームホールルーティング」と呼ばれる。ワームホールルーティングを実装するために、各ＤＭＲは、１組のステアリング（ｓｔｅｅｒｉｎｇ）機能と、ＳＲＦを通して、メッセージと呼ばれるワードのシーケンスの進行を停止および再開させる仕組みとを含んでよい。ステアリング機能は、すべての通信経路により共通に使用され、再利用されてよいので、ＤＭＲのＲＡＭを占有してよい構成コードの量は、上述の大域プログラミング方法よりもはるかに少なくてよい。ワームホールルーティング法では、ソフトウェア制御を依然として使用して、経路が使用する特定のリンクを選択するが、経路作成（本明細書ではセットアップとも呼ばれる）および消滅／リンク解放（本明細書では解体（ｔｅａｒｄｏｗｎ）とも呼ばれる）の処理は、最小のソフトウェア介在で、ハードウェアの形で実装されてよい。

経路上でデータワードが損失する可能性を回避するために、ＭＰＳ１０のある実施形態は、経路に沿って受信側と送信側の間でフロー制御を実装してよい。フロー制御は、伝送側の対応する受信側がデータをもはや受信することができない場合に伝送側を停止させてよく、かつ伝送側の対応する受信側がデータを受信する準備ができたときに伝送側を再開してよい仕組みを指す。経路上でのデータの流れを停止および再開させることは、ワームホールルーティングでメッセージの進行を停止および再開させることと多くの類似点があるので、一体化した方式で両者を組み合わせてよい。

一実施形態では、ＭＰＳ１０は、均一なアレイの形で一緒に接続された、同一であってよい複数のＰＥおよび同一であってよい複数のＤＭＲを含んでよい。均一なアレイでは、ＰＥの大多数は、同一であってよく、ＰＥの大多数の各々は、ＤＭＲへの接続を同数有してよい。また、均一なアレイでは、ＤＭＲの大多数は、同一であってよく、ＤＭＲの大多数の各々は、他のＤＭＲおよびＰＥへの接続を同数有してよい。ＰＥおよびＤＭＲは、ＭＰＳの一実装形態では、実質的に均質な方式で散在してよい。本明細書で使用するとき、実質的に均質な散在は、ＤＭＲに対するＰＥの比がアレイの副領域の大部分にわたり不変な配列を指す。

実質的に均質な方式で配列された一様なアレイは、予測可能な相互接続パターンを提供する、およびソフトウェアモジュールをアレイ全体にわたって再利用可能にするなど、ある種の有利な特性を有してよい。一実施形態では、一様なアレイは、ＰＥおよびＤＭＲの少数のインスタンスを設計および試験することを可能にすることがある。この場合、ＤＭＲおよびＰＥを備えるユニットを製作し、次いでそのようなユニットを複数回反復する、または「タイルのように並べる」ことにより、システムを組み立ててよい。そのような取り組み方法は、共通のシステム要素を再利用することによって設計および試験の費用を安くすることがある。

ＰＥおよびＤＭＲの構成可能な性質は、多種多様の非一様な挙動を、物理的に一様なアレイ上で行うようにプログラムできるようにすることがあることもまた留意される。しかしながら、ある代替実施形態ではさらにまた、規則的もしくは不規則なアレイの形に、またはランダムな方法でさえ接続されてよい、非一様なＤＭＲおよびＰＥのユニットを用いてＭＰＳ１０を形成してもよい。一実施形態では、たとえば集積回路（ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ、ＩＣ）、セラミック基板、またはプリント回路基板（ｐｒｉｎｔｅｄ ｃｉｒｃｕｉｔ ｂｏａｒｄ、ＰＣＢ）上に回路トレースとしてＰＥおよびＤＭＲの相互接続を実装してよい。しかしながら、代替実施形態では、そのような相互接続は、たとえば電磁エネルギー（すなわち、無線または光のエネルギー）用導波管、無線（すなわち、導波管なし）エネルギー、粒子（電子ビームなど）、または分子上の電位など、さまざまな小型通信リンクのいずれであってよい。

単一集積回路上にＭＰＳ１０を実装してよい。一実施形態では、複数のＭＰＳ集積回路を組み合わせて、より大きなシステムを作り出してよい。ＭＰＳ１０の所与の実施形態は、シリコン集積回路（Ｓｉ−ＩＣ）技術を使用して実装されてよく、そのような技術の特有の特性の原因となるさまざまな特徴を採用してよい。たとえば、Ｓｉ−ＩＣチップ上の回路を、薄い平面に閉じ込めてよい。それに応じて、ＭＰＳ１０の所与の実施形態は、図２に例示するような、ＰＥおよびＤＭＲの２次元アレイを採用してよい。しかしながら、ＰＥおよびＤＭＲの異なる配列を含む代替ＭＰＳの実施形態が企図される。

さらに、Ｓｉ−ＩＣ上の利用可能な配線密度は、そのようなチップの間の配線密度よりもはるかに高いことがあり、各チップは、チップ上の信号およびチップ外の信号とインタフェースをとる周辺の特殊な入力／出力（Ｉ／Ｏ）回路を有してよい。それに応じて、ＭＰＳ１０の所与の実施形態は、チップのコア内にＰＥおよびＤＭＲの一様なアレイと、チップの周辺に沿った、修正されたＰＥ／ＤＭＲユニットとからなる少し非一様なアレイを採用してよい。しかしながら、異なる配列、および一様なＰＥ／ＤＭＲユニットと修正されたＰＥ／ＤＭＲユニットの組合せを含む代替ＭＰＳの実施形態が企図される。

また、Ｓｉ−ＩＣ回路が遂行する計算動作は、熱を生じさせることがあり、その熱は、ＩＣパッケージングにより取り除かれてよい。ＩＣパッケージングが大きくなることにより、追加空間を必要とすることがあり、ＩＣパッケージングを通した、およびＩＣパッケージングの周囲の相互接続は、パス長に比例する遅延を招くことがある。したがって、上記で指摘したように、非常に大規模なＭＰＳは、複数のチップを相互接続することにより構築されてよい。そのような複数チップＭＰＳの実施形態のプログラミングは、チップ間信号遅延がチップ内信号遅延よりもはるかに大きくなることを考慮してよい。

所与のＳｉ−ＩＣのＭＰＳ１０の実装形態では、単一チップ上に実装してよいＰＥおよびＤＭＲの最大数は、所与のＳｉ−ＩＣ技術で可能な小型化、および各ＰＥおよびＤＭＲの複雑性により決定されてよい。そのようなＭＰＳの実装形態では、ＰＥおよびＤＭＲの回路の複雑性は、目標とするレベルの計算スループットの達成を条件として最小化されてよい。そのように最小化されたＰＥおよびＤＭＲを、本明細書では簡素化されたと呼ぶことがある。ＭＰＳ１０の一実施形態では、ＰＥに関して目標とするスループットのレベルは、同じＳｉ−ＩＣ技術で作られた最良のデジタル・シグナル・プロセッサ（ＤＳＰ）の算術実行ユニットのレベルに匹敵してよい。しかしながら、目標とするＰＥスループットに関する代替基準を使用してよい他のＭＰＳの実施形態が企図される。

いくつかの実施形態では、ＭＰＳ１０は、ＤＳＰおよびＦＰＧＡのアーキテクチャが有する最良の特徴を採用してよい。ＤＳＰと同様に、ＭＰＳ１０は、複数の処理ユニットおよびオン・チップ・メモリを伴う、プログラム可能なチップであってよい。しかしながら、ＤＳＰと比べて、ＭＰＳ処理ユニットは簡素化されてよく、さらに多くのＭＰＳ処理ユニットが存在してよく、ＭＰＳ処理ユニットは、ＭＰＳ処理ユニット間のデータ移動の帯域幅だけではなく、チップ上およびチップ外のデータ移動の帯域幅も最大にする新規な方法で相互接続されてよい。ＤＳＰよりも多くの処理ユニットを有することにより、ＭＰＳ１０は、単位時間あたりより多くの積算を行うことができるようになり、簡素化された処理ユニットは、エネルギー使用を最小にすることがある。内部並列処理を有する多くのＤＳＰは、バス指向アーキテクチャであってよい。いくつかの実施形態では、ＭＰＳ１０は、バスを含むのではなく、むしろバス指向アーキテクチャよりも著しく高い全帯域幅を提供してよいＳＲＦ内に埋め込まれたＤＭＲ内などに、隣接する共有ローカルメモリを含んでよい。

ＦＰＧＡの取り組み方法と比較して、いくつかのＭＰＳの実施形態は、より粗い粒状であってよい。たとえば、ＭＰＳの一実施形態では、自然な語長（たとえば、１６ビット）を有してよく、計算は、自然な語長の倍数のデータを使用して遂行する場合、最も効率的であってよい。いくつかのＭＰＳの実施形態では、ＰＥおよびＤＭＲは、ＦＰＧＡで実現される等価な構造より高密度あってよく、その結果、より短い平均配線長、より低い配線容量、およびより少ないエネルギー使用がもたらされることがある。ＦＰＧＡの実装とは対照的に、いくつかのＭＰＳの実施形態では、ＭＰＳ内のあらゆるＡＬＵは、プロセッサ（すなわち、ＰＥ）の一部であってよく、それにより、オペランドのフェッチ、およびＤＭＲ内の周囲の高速メモリへ結果を書き戻すのが容易になる。ＡＬＵに関するタイミングおよびクロックスキューの問題、フェッチ動作、および書き戻し動作は、ＩＣチップを設計する間に一度解決すればよく、ＦＰＧＡの実装で特有なように、新しいアプリケーションごとに再度解決する必要はない。

粗い粒状のプログラム可能な埋込システムは、少数のプロセッサまたはデジタル信号処理エンジンから構成されてよい。たとえば、機器は、４つまたは８つのプロセッサコアだけではなく、固定された、またはプログラム可能な特定用途向け論理機能を包含してよい。これらのシステムは通常、データおよび命令を記憶するために使用する大規模共通メモリを有する。典型的には、これらのシステムは、仮想メモリ方式を利用して、チップ上のメモリのサイズよりも大きなアドレス指定が可能なデータおよび命令メモリの範囲を拡張する。そのようなシステムは、通信マッピング要件、およびコード生成中に考慮すべき最低限の物理特性を有しない。

図３は、９×９のＤＭＲアレイ（円形）と共に一様に散在した８×８のＰＥアレイ（正方形）からなる、ある例のＭＰＳを例示する。ＰＥに割り当てるタスクの中にプログラムをコンパイルしてよい。第１の例のプログラムを、タスクＩＤ＝６２でコンパイルして、アレイの左上隅にある特有のＰＥに割り当てた。変数ｕ、ｖ、ｗは、プログラム・ソース・コード内で宣言した通信変数であり、近接するＤＭＲ内の特有のメモリアドレスに割り当てられ、ｕおよびｖは、Ｉ／Ｏポート用バッファであり、ｗは、タスクＩＤ＝６２の関連するＤＭＲとのチップ上でのネットワーク通信用バッファである。第２の例のプログラムを、タスクＩＤ＝７１でコンパイルして、アレイの内部にある特有のＰＥに割り当てた。変数ｘは、宣言された通信変数であり、図示するＤＭＲに割り当てられる。変数ｘに関連する通信経路は、タスクＩＤ＝７１の割り当てられたＤＭＲから他のＤＭＲを経由して最上部の行にあるＩ／Ｏポートまで伸びている。図示するように、２つの例示的プログラムは、互いに通信しないが、タスク７１に別の通信変数を追加し、タスク７１のＤＭＲとタスク６２に近接するＤＭＲ内の変数ｗとの間の経路を追加することにより、容易に通信するようにできる。

図３は、データパスの例を示し、データパイプライン０（ＤＰ０）およびデータパイプライン１（ＤＰ１）を指定された二重高スループット動作ユニットを伴い、この議論のために追加フローレジスタをいくつか拡張している。これらのフローレジスタは、入力用の特別のパイプラインレジスタＸ、Ｙ、および出力用の特別のパイプラインレジスタＺである。さらにまた、名目上のオペランドステージＡ、Ｂ、Ｃ、および宛先ステージＤも示す。

Ａ、Ｂ、およびＣのレジスタを使用して、利用可能なとき、すでに論じたように最大６４ビット幅のオペランドを記憶する。ＨｙｐｅｒＯｐは、Ａ、Ｂ、およびＣのレジスタと、２つのデータパスのＸおよびＹのレジスタとの間の多重通信を使用して、データパスにより遂行される動作ごとに必要とされるオペランドおよびワード整列（ｗｏｒｄ ａｌｉｇｎｍｅｎｔ）を制御する。ＨｙｐｅｒＯｐ処理中にＡ、Ｂ、およびＣのレジスタの中へフェッチするオペランドは、プログラムの制御を受け、オプションをシフトして、アドレスが整列したメモリへのアクセス、およびデータパスの数学的ユニット用に適切なオペランド整列を可能にする。この新機軸は、複雑なデータパス／ＨｙｐｅｒＯｐの組合せに十分なオペランドを提供して、オペランドがメモリにどのように記憶されるかとは無関係にピークスループットを提供する手法を提供するように、より簡単で低電力なメモリ構造およびアドレス指定モードを可能にする。

結果の１つは、オペランドの議論に類似している。データパスの結果は、ＨｙｐｅｒＯｐ実行中にアキュムレータまたはＺレジスタの中に置かれる。次いで、これらの結果は、他の場所に書き戻すためにＤに移動させることができる、または次の命令で追加オペランドとして使用するために、例示するパス上にフィードバックすることができる。オペランドと同様に、この場合、結果の再整列を行って、非整列データ用メモリ／レジスタに、整列した書戻しを提供することができる。この場合も、これらの動作は、ＨｙｐｅｒＯｐ命令により独立に制御される。

多くのアーキテクチャでは、類似する数学的動作からなる長いストリングを集約して、単一アキュムレータが存在する単一の総計にするためのアキュムレータをサポートする。追加で、場合によっては、すべての動作は、結果（この場合も、前世代）を用いてこのアキュムレータを修正する。この構造は、主にサイクルあたり単一スカラー動作であるアーキテクチャについてはうまく作動し、その一方で、特別のデータパスと、ＨｙｐｅｒＯｐを用いてサイクルあたり複数のオペランドに対して動作する能力とを追加して、この概念を拡張することが必要となる。現在の設計点は、データパスあたり２つの独立したアキュムレータを包含する。各動作は、もしあれば、どちらのアキュムレータを更新するかを選ぶことができる。したがって、これらのアキュムレータを使用して、すでに論じた多重通信構造を通して、後で処理するための中間値を記憶可能である、またはアキュムレータ値を保存および回復する追加サイクルおよび電力オーバーヘッドなしに、インターリーブされた形態で複数のデータストリームを処理できるようにすることが可能である。二重アキュムレータ構造のこれらの特徴は、二重データパスおよびオペランド／結果整列などのその他の特徴と結合したとき、パイプラインをより完全に利用された状態に保つ仕組みを提供し、それによりさらにまた、設計に関する動作あたりの全電力が低減される。

アキュムレータに関係する別の特徴は、いくつかのアルゴリズムの内部ループをスピードアップして、チップ内の複数のＰＥにわたり並列実行を増大させる別の方法を提供する。たとえばこの特徴は、マルチタップ広帯域幅ＦＩＲフィルタのように、十分なデータ処理帯域幅を提供するために、複数のＰＥにわたり広がるべきである計算ループに対するオーバーヘッドを最小にするために必要である。

図３では、アドレス生成ユニット（ａｄｄｒｅｓｓ ｇｅｎｅｒａｔｉｏｎ ｕｎｉｔ、ＡＧＵ）を包含するアドレス生成器セクションを示すが、詳述しなかった。ＰＥアーキテクチャのアドレス生成器セクションは、ハードウェアがサポートするさまざまなアドレス指定モード用のアドレスを生成する。ＰＥアーキテクチャのアドレス生成器セクションの固有の特徴について、本節でさらに記述する。

アドレス生成器セクションは、アドレスを生成するために使用する、複数のプログラム可能な数学的ユニットを有してよい。これらのユニットの各々は、アドレス生成ユニット（ＡＧＵ）である。追加で、パイプラインのアドレス計算部分で追加計算を行うために使用することができる１つまたは複数の拡張算術論理演算装置（ＧＡＬＵ）が存在してよい。これらの計算は、パイプの機能性および性能を拡張するために、およびテーブルルックアップのタイプの動作などでパイプライン遅延を除去するために有用である。図３では、例示的アドレス生成器セクションは、３つのＡＧＵ、および１つのＧＡＬＵ、および１組のサポートレジスタを包含する。

標準的符号化法での典型的動作では、ＡＧＵを使用して、２つのソースオペランドおよび宛先用のアドレス、またはこれらおよびいくつかのアドレスのサブセット、もしくは拡張された数学操作用アドレスを生成する。ユニットは、符号化と密結合である。ＨｙｐｅｒＯｐ符号化を介した拡張動作では、これらのユニットをさらに分離して、命令ストリームにより独立に制御することができる。これにより、より高い動作の柔軟性およびより高い動作の並列化が可能になる。最適化は、リアルタイムでの並べ替えを必要とせず、したがって、そのような最適化により動作電力を犠牲にすることがまったくないように、コンパイル時に遂行されてよい。

典型的なプログラミング設計の流れを図４に示す。コンパイラおよびアセンブラを介してユーザ・ソース・コードを変換し、１つまたは複数のオブジェクトファイルにして、次いでオブジェクトファイルを一緒にリンクして、対象となるプロセッサコアが解釈可能なバイナリ・コード・イメージを包含する実行可能ファイルを形成する。実行可能イメージを走らせ、試験するために、ローダプログラムは、実行可能イメージをシミュレータに、または物理的埋込システムの、対象となるコアの命令メモリにコピーする。

図４の典型的な流れでは、すべてのコンパイラ最適化は、アセンブラおよびリンカ段階の前に完了する。これは、異なるコア上で個々のスレッドが走ることができるようになるマルチ・スレッド・アプリケーション・プログラムについてさえ当てはまる。

多くのＰＥおよびより小規模な分散メモリを伴うマルチ・コア・プロセッサは、電力消費がより低いという利益を有するが、考慮すべき物理的制約がより多くある。そのようなプロセッサのための典型的ツールの流れを図５に示す。ブロック５０１で始まるこのツールの流れでは、ユーザ・ソース・コードは、通信を可能にするアプリケーション・プログラミング・インタフェース（ＡＰＩ）を介して互いに通信する１つまたは複数のタスクから構成される。たとえば、メッセージ受渡パラダイムをサポートするようにＡＰＩを設計してよい。

方法は、アプリケーション・ソース・コードをコンパイルして、アセンブリコードを生成するステップ（ブロック５０２）を含む。コンパイラ段階は、Ｃコンパイラ、アセンブラ、およびタスクリンカを走らせて、タスクごとにオブジェクトファイルを生成し、次いでタスク間の接続性を接続性データベースの中に抽出する。この時点で、すべてのコンパイラ最適化は完了しているが、タスク、変数、および通信は、物理資源にまだマッピングされていない。

方法は、資源をマッピングするステップ（ブロック５０３）を含む。資源マッピング中にタスクマッピング、変数配分、および通信マッピングを行う。追加で方法は、通信を合成するステップ（ブロック５０４）を含む。通信ＡＰＩ用のそのようなコード合成を、コンパイル処理の最終リンカ段階の一部として遂行してよい。

方法はまた、シミュレートおよびデバッグするステップ（ブロック５０５）を含む。イメージファイルを、そのような試験およびデバッグのためにソフトウェアシミュレーションおよびハードウェアデバッガの中にロードしてよい。方法は、ハードウェア上に実行イメージをロードするステップ（ブロック５０６）をさらに含む。そのようなロードするステップは、マルチ・プロセッサ・アレイ上で使用するためのコンパイル済みソフトウェアを導入するステップの一部であってよい。

最適化のために使用するコンパイラデータは、コンパイル処理が完了した後に捨てられるので、資源マッピングで物理資源が割り当てられた後、最適化はほとんど、またはまったく不可能である。流れの中でのステップの繰返しはサポートされていない。

分散メモリのマルチ・コア・プロセッサを用いて最適な結果を達成する方法は、すべての資源を完全にマッピングした後、流れ全体を通して十分な情報を維持して、最後にコンパイラ最適化を行うことができるようにするツールの流れを作成することである。この方法は、すべての形態のコンパイラ最適化だけではなく、マルチタスキングなどの負荷分散最適化も含む。マルチタスキングでは、複数のタスクを同じＰＥに割り当てる。一般に有用で実用的であるためには、ＰＥごとに選択されるタスクは、コンテキストスイッチ（この場合、レジスタおよび変数は、少し後で回復されてよいように保存される）によるオーバーヘッドを招くことなく一緒に動作するように選択されてよい。そのような流れを実行することができるコンピュータシステムの構成図を図６に例示する。

例示するように、コンピュータシステム６００は、ワークステーション６０１、プロジェクトデータベース６０２、シミュレータ６０３、およびマルチ・プロセッサ・アレイ６０４を含む。さまざまな実施形態では、ワークステーション６０１は、コンピュータ、ラップトップコンピュータ、タブレット、または有線ネットワークもしくは無線ネットワークを介してプロジェクトデータベース６０２、マルチ・プロセッサ・アレイ６０４、およびシミュレータ６０３と通信可能な、任意の他の適切なコンピューティング機器を含んでよい。

プロジェクトデータベース６０２は、アプリケーション・ソース・コードだけではなく、中間表現およびイメージファイルなどのコンパイル処理中に生成したファイルも含んでよい。さまざまな実施形態では、プロジェクトデータベース６０２は、ディスクサーバ上に、またはコンピュータシステム６００内に例示するその他の構成要素に接続された他の適切な記憶装置上に記憶されてよい。

さまざまな実施形態では、マルチ・プロセッサ・アレイ６０４は、複数の処理要素（ＰＥ）だけではなく、他の構成要素も含んでよい。たとえば、上述のように、マルチ・プロセッサ・アレイ６０４は、図１に描く実施形態で例示するように、１つまたは複数のデータ・メモリ・ルータを含んでよい。

シミュレータ６０３は、コンパイル済みバージョンのアプリケーション・ソース・コードを実行するように構成されたソフトウェアとハードウェアの任意の適切な組合せを含んでよい。たとえば、シミュレータ６０３は、ソフトウェアを実行して、アプリケーションが最終的に実行される所望の環境をエミュレートする専用のコンピュータまたはワークステーションであってよい。いくつかの事例では、シミュレータ６０３は、シミュレートされているアプリケーションソフトウェアに試験データを提供し、アプリケーションソフトウェアが試験データに対して動作することにより生成された、変数値などの結果を集めるように構成されてよい。

図７を参照すると、アプリケーション・ソース・コードをコンパイルするための方法のある実施形態を描く流れ図が例示されている。ブロック７０１で始まる方法は、図６に例示するコンピュータシステムに適用されてよい。

方法は、アプリケーション・ソース・コードを使用してフロント・エンド・コンパイルを遂行して、複数の中間表現および接続性情報を生成するステップであって、複数の中間表現のうちの特定の中間表現は、複数のタスクのうちの特定のタスクに対応し、接続性情報は、複数の接続を含み、特定の接続は、複数のタスクのうちの第１のタスクと複数のタスクのうちの第２のタスクとの間の通信を指定するステップ（ブロック７０２）を含む。本明細書で使用し、記述するとき、接続性情報は、２つ以上のタスクと２つ以上の入力／出力ポートの間の抽象的接続について記述する情報である。

方法はまた、複数の中間表現および接続性情報を使用して、マルチ・プロセッサ・アレイに含まれる物理資源にアプリケーション・ソース・コードに含まれる論理オブジェクトをマッピングして、資源マップを生成するステップ（ブロック７０３）を含む。以下でより詳細に記述するように、資源マッピングは、マルチ・プロセッサ・アレイ内部の特定のＰＥに特有のタスクを割り当てるステップを含んでよい。

方法は、複数の接続内の接続ごとに、対応する実装を選択するステップ（ブロック７０４）をさらに含む。以下で記述するように、接続は、アプリケーションプログラマが提供するコードを通して明示的に識別されてよい、またはソースコードを分析することによってソフトウェアツールにより自動的に抽出されてよい。

追加で方法は、複数の中間表現を使用して第１の最適化動作を遂行して、複数の最適化中間表現を生成するステップ（ブロック７０５）を含む。以下でより詳細に記述するように、そのような最適化は、マルチ・プロセッサ・アレイの能力を利用する、よりよい資源マッピングを含んでよい。最適化を遂行することにより、初期資源マップを決定した後、最適化は、有利にはマルチ・プロセッサ・アレイ上でのアプリケーションソフトウェアの実行を改善することがある。

方法はまた、複数の最適化中間表現を使用して、実行可能コードを生成するステップ（ブロック７０６）を含む。さまざまな実施形態では、実行可能コードを生成するステップは、イメージファイルの作成を含んでよく、イメージファイルの一部分は、マルチ・プロセッサ・アレイに含まれる、対応するＰＥにより実行されてよい。

方法はまた、マルチ・プロセッサ・アレイの上に実行可能コードをロードするステップ（ブロック７０７）を含む。いくつかの実施形態では、実行可能コードのイメージファイルの一部分を、マルチ・プロセッサ・アレイの、対応するＰＥの中にロードしてよい。そのようなロードするステップは、マルチ・プロセッサ・アレイのさまざまなＰＥを連結する通信ネットワークを採用してよい。方法は、ブロック７０８で終了する。

いくつかの事例では、フロントエンド最適化とバックエンド最適化の両方を遂行する。そのような方法のある実施形態を描く流れ図を図８に例示する。ブロック８０１で始まる方法は、図６に描くコンピュータシステムに適用されてよい。方法は、フロント・エンド・コンパイルを遂行して、中間表現を生成するステップ（ブロック８０２）を含む。

方法は、資源をマッピングするステップ（ブロック８０３）をさらに含む。さまざまな実施形態では、中間表現から集めた情報を使用して、どのタスクを、マルチ・プロセッサ・アレイに含まれるどのＰＥにマッピングすべきかを決定してよい。方法はまた、最適化が可能であるかどうかを調べるステップ（ブロック８０４）を含む。いくつかの事例では、最適化は、最初に割り当てられたのと異なる資源のマッピングを伴ってよい。

この場合、方法は、最適化が可能であるかどうか（ブロック８０５）に左右される。最適化が可能である場合、方法は、上述のようにブロック８０３から継続する。あるいは、最適化が不可能である場合、方法は、バック・エンド・コンパイルおよび通信合成を遂行するステップ（ブロック８０６）を含む。

フロント・エンド・コンパイルと同様に、方法は、最適化が可能であるかどうかを調べるステップ（ブロック８０７）を含む。方法は、この場合も最適化が可能であるかどうか（ブロック８０８）に左右される。最適化が可能である場合、方法は、上述のようにブロック８０６またはブロック８０３から継続する。最適化がまったく不可能である場合、方法は、シミュレートおよびデバッグするステップ（ブロック８０９）を含む。いくつかの事例では、そのようなシミュレーションおよびデバッグは、マルチプロセッサの上にソフトウェアをロードして、ソフトウェアを実行するステップを含む。そのような実行は、試験データの使用を含んでよく、ソフトウェアの実行から得られる結果を集めてよい。期待されるデータと結果を比較してよい。

次いで、方法は、最適化が可能であるかどうかを調べるステップ（ブロック８１０）を含む。すでに記述したのと類似する手法で、方法は、この場合、最適化が可能であるかどうか（ブロック８１１）に左右される。最適化が可能である場合、方法は、上述のようにブロック８０３、ブロック８０６、またはブロック８０９から継続する。最適化が不可能である場合、方法は、マルチ・プロセッサ・アレイの上に実行可能イメージをロードするステップ（ブロック８１２）を含む。実行可能イメージは、さまざまな実施形態では、上述のように、個々のＰＥ間を接続する通信ネットワークを使用してマルチ・プロセッサ・アレイの上にロードされてよい。方法は、ブロック８１３で終了する。

図９に描くように、Ｃなどの高水準言語用コンパイラは、中間表現（ＩＲ）を使用して、コンパイル処理の中間結果を記憶する。ブロック９０１で始まる方法は、アプリケーション・ソース・コードを分析するステップ（ブロック９０２）を含む。ＬＬＶＭなどの現代のコンパイラは、ソース言語をＩＲに変換する構文解析プログラムを含む１組のコンポーネントを提供する。次いで、方法は、初期最適化動作を遂行するステップ（ブロック９０３）を含む。そのような初期最適化動作は、１つまたは複数の最適化パスと、Ｘ８６、Ａｒｍなどのような対象となる異なる命令セット用の命令からなるプログラムモジュールを生成する命令−生成器フレームワークとを含むことができる。

それぞれ入力ＩＲを読み込み、変換を行い、修正されたＩＲを出力する１つまたは複数の「低減（ｌｏｗｅｒｉｎｇ）」パスを使用して、最適化を実装する。任意の所望の変換用に追加パスを加えてよい。高水準言語構造体を低水準の機械特徴に変換するように一連の変換を設計する。従来、コンパイルステップは順次実行され、最終パスは、対象とする機械用に最適化されたアセンブリ言語を生成する。次いで、アセンブラおよびタスクリンカを走らせて、タスクあたりの単一オブジェクトファイル、およびすべてのタスクを包含するデータベースを作り出す。次いで、この情報を使用して、タスク間の接続性を識別し、データベースに接続性を記憶する。従来の取り組み方法に関する重要な観察結果がいくつか存在する。

すべての最適化を走らせて、接続性を識別する必要はない。定数を伝播し、デッドコードを除去する最適化だけが必要である。これらは、誤った接続性を識別するのを回避するために必要である。

タスクあたりの単一オブジェクトファイルを作り出すためにタスクリンキングは必要ないことが留意される。むしろ、方法は、手続き間分析（ｉｎｔｅｒ−Ｐｒｏｃｅｄｕｒａｌ Ａｎａｌｙｓｉｓ、ＩＰＡ）を遂行するステップ（ブロック９０４）を含む。ＩＰＡは、ソース・コード・ファイル全体にわたり動作し、かつタスクあたりの単一ＩＲを作り出すコンパイラ最適化パスである。

オブジェクトコードは、接続性識別のための要件ではない。タスクに関するＩＲから接続性を抽出することが可能である。強化された流れでは、フロント・エンド・コンパイル処理は、最小最適化パス、およびタスクごとにＩＲ表現を生成するＩＰＡだけを走らせる。各タスクに関する関連情報およびタスクごとのＩＲをデータベースに記憶する。方法は、ブロック９０５で終了する。

上記で記述する流れは、バック・エンド・コンパイル・ステップまでアセンブリ言語を生成しない。したがって、アセンブリ・ソース・ファイル、およびＣソースファイルに含まれるインラインアセンブリは、Ｃソースから生成されるＩＲ表現と同じ手法で取り扱われるＩＲ表現に変換される。これは、フロント・エンド・コンパイル処理の一部として取り扱われる。

当然のことながら、アセンブリ言語コードは、一般にアプリケーション開発者により手作業で最適化されるので、生成されるＩＲは、Ｃソースから生成される初期ＩＲよりも低水準にある。都合のいいことには、ＩＲでは雑多の水準の抽象化がサポートされ、いくつかの追加最適化は、依存として可能であってよい。

インラインアセンブリでは、アセンブリ・コード・ブロック内で参照される物理レジスタは、コード生成中のレジスタ配分で追加情報を使用することができるように認識される。あるいは、流れは、インライン・アセンブリ・コードのブロック内で仮想レジスタの使用をサポートすることができる。これらのレジスタ参照は、レジスタ割当て中に認識され、Ｃソースから生成されたコードのためにレジスタ配分を行うのと同時に物理レジスタと置換される。

接続性識別は、コンパイル段階の最終ステップである。このステップ中、タスク間の接続をすべて識別する。これは、アプリケーションプログラマにより提供されるコードによって明示的に達成することができる、または分析を介してソフトウェアツールにより自動的に抽出することができる。

自動通信抽出では、タスクごとの通信の送信および受信に関する情報は、フロント・エンド・コンパイル中にＩＲに記憶される。抽出処理は、全体設計のための接続性グラフを構築する。これは、宣言情報とタスクに関するＩＲで利用可能な通信ＡＰＩの組合せを使用して行われる。接続性情報をデータベースに記憶する。

図１０を参照すると、資源マッピングのための方法のある実施形態を描く流れ図が例示されている。ブロック１００１で始まる方法は、ハードウェア上の物理資源にアプリケーションコード内で規定される論理オブジェクトを割り当てる処理である。これを達成するために、方法は、タスクをマッピングするステップ（ブロック１００２）を含む。たとえば、異なるタスクを対応するＰＥにマッピングしてよい。方法は、配分変数（ブロック１００３）をさらに含む。いくつかの事例では、利用可能なメモリの所与の１つに特定の変数を配分する。

追加で方法は、タスク間通信をマッピングするステップ（ブロック１１０４）を含む。いくつかの事例では、入出力通信は、Ｉ／Ｏポートだけではなく、他の物理資源にもマッピングされる。方法は、ブロック１００５で終了する。

これらの動作の順序は重要であるが、異なるハードウェアに合わせて変わってよいことが留意される。典型的分散メモリ・アレイ・プロセッサ上では、ＰＥにタスクを割り当てなければならず、通信をルーティングすることができる前に、通信に関係する変数およびＩ／Ｏポートを配分しなければならない。通信に関係しない変数を、通信マッピングが完了する前後に配置してよい。

結果に影響を及ぼす資源マッピングに制約を与えてよい。任意選択または必須として制約を指定してよい。資源マッパが必須の制約を達成するのに失敗する結果、資源マッピングエラーがもたらされる。任意選択の制約を達成するのに失敗することは、受入可能である。制約のいくつかの例は、タスクおよび変数に関する相対的場所の制約、ならびに通信の間で同じルート資源を共有することである。

場所の制約は、共有メモリなどの共通資源にアクセスできるようにするために、または最適化する目的で、ある種の命令にアクセスできるようにするために必要である。制約を満たす場合、ソフトウェアツールは、最適な結果を得るために、必要な資源を利用することができる。制約を満たさない場合、利用可能な資源に基づき、あまり最適ではない方法を使用してよい。

通信マッピングの制約を使用して、広帯域幅要件を伴う通信間の競合を防止してよい。そのような制約をユーザにより手作業で、またはツールにより自動的に提供してよい。ツールにより自動的に提供することは、ユーザ・ソース・コードが実装用ハードウェア資源の特有の配列を必要とする構造体を含む場合に一般的である。制約はまた、流れの中で下流ツールから提供されてよい。

最終コード最適化前にタスクマッピングを行うので、タスク間のコンテキストスイッチングのために大きなオーバーヘッドを招くことなく、同じＰＥに複数のタスクを割り当てることが可能である。コンテキストスイッチは、レジスタおよび変数を含む状態情報の保存および回復を必要とする。バック・エンド・コンパイラ段階までレジスタおよび変数の配分は行われないので、複数のタスクにわたりレジスタおよび変数を配分することができ、コンテキストスイッチのオーバーヘッドを完全に低減する、または完全に除去することができる。

通信の各々を実装する最良の仕組み、および適切なコードの生成を選ぶ処理は、「通信合成」と呼ばれる。通信合成を遂行するための方法のある実施形態を描く流れ図を図１１に例示する。資源マッピングが完了すると、方法は、ブロック１０１で始まる。そのような資源マッピング後、通信ＡＰＩごとに最良の実装を選ぶために必要なすべての情報は、利用可能である。方法は、次いで通信を合成するステップ（ブロック１１０２）を含む。たとえば、ソフトウェアツールは、通信に関係する変数の相対的場所および利用可能なハードウェア資源に基づき、最も効率的な実装を選ぶ。たとえば、直接メモリアクセス（ＤＭＡ）を介した転送は、多くの場合、最良の解決手段であるが、送信側および受信側の変数が同じデータメモリ内にある場合、最良の仕組みは、共有メモリを利用してよい。

通信が実際の実装とすべて置換されると、方法は、コンパイラ最適化を遂行するステップ（ブロック１１０３）を含む。そのような最適化は、タスクごとにＩＲ上で走らせられてよい１つまたは複数の最適化パスを遂行するステップを含んでよい。通信ＡＰＩ用に合成されたコードは、タスク内のその他のコードと一緒に最適化される。これは、通信ＡＰＩ用コードが合成される前にバック・エンド・コンパイラ最適化が行われたこれまでの流れに対して明らかな利点である。

流れのこの時点で実行される共通の最適化は、ハードウェア特有のループ最適化と、ソースオペランドおよび宛先オペランドをアクセスする最良の方法を選ぶためのオペランドモード選択とを含んでよい。さまざまな実施形態では、ハードウェア特有のループ最適化は、反復ループ抽出、ループ不変コード移動、ある種のＰＥ機能の待ち時間を隠すためのソフトウェアパイプライン処理、複数のＰＥを利用して性能を改善するベクトル化、ループ展開、類似ループを組み合わせるループ融合、およびループを特定の部分に分離するループ分裂（ｆｉｓｓｉｏｎ）を含んでよい。

いくつかの実施形態では、オペランドモード選択は、ハードウェアレジスタを最適に使用するためのレジスタ選択、およびメモリアドレスに変数を最適に割り当てるための変数配分を含んでよい。

これらの最適化の多くは、資源マッピングが完了する前に行うことができるが、一方では、適切に行うことができない。たとえば、レジスタおよび変数の配分は、マルチタスキングのためのスケジューリングを最適化できるようにタスクが完全に配置された後に最も効果的に完了する。ループベクトル化は、近接するＰＥ内の利用可能な資源が既知であるようにタスクをＰＥに割り当てた後に最も効果的に行われる。そして、ループ不変コード移動などの最適化は、通信合成が完了した後に最も効果的に行われる。

方法はまた、実行可能コードを生成するステップ（ブロック１１０４）を含む。さまざまな実施形態では、コード生成は、タスクＩＲごとにオブジェクトコードを生成するステップと、ハードウェアの上に、またはソフトウェアシミュレーション環境の中にアプリケーションをロードするために使用する最終イメージファイルを生成するステップとを含んでよい。実装に応じて、第１のステップは、タスクごとにアセンブリ言語ソースの生成を伴ってよく、アセンブリ言語ソースは、次いで、オブジェクトコードを生成するためにアセンブラにかけられる。

コード生成中、ソフトウェアツールは、命令のシーケンスを選んで、タスクごとに、データベースに記憶したそのタスクに関する最適化されたＩＲに基づき、最初のソースを実装する。この処理は、タスクおよび変数の相対的場所に基づき利用可能なハードウェアの特殊な特徴を伴ってよい。たとえば、いくつかの命令は、アレイ内のある種のＰＥ上でだけ利用可能であってよい。タスクがそれらのＰＥの１つに配置された場合、実装するために特殊な命令を使用することができる。他の事例では、いくつかの命令は、ソースおよび／または宛先の変数が同じメモリ内にある場合だけ利用可能であってよい。資源マッピングが変数を同じ場所へ配置するという必要なことを達成することができない場合、あまり最適ではない実装を選ぶ。

方法は、ブロック１１０５で終了する。いくつかの事例では、コード生成を完了した後、最終イメージファイルを書き込むことが留意される。このファイルは、実際のハードウェア上にロードすることができる、または試験およびデバッグのためにソフトウェアシミュレータまたはハードウェアデバッガの環境の中にロードすることができる。

いくつかの事例では、実行可能イメージをマルチ・プロセッサ・アレイの上にロードする前に、ツールの流れの中の最終ステップは、シミュレーションステップである。さまざまな実施形態では、シミュレーションステップは、アプリケーション実行、挙動試験およびデバッグ、性能およびタイミング特性解析、ならびに電力特性解析を含んでよい。挙動の問題は、典型的にはアプリケーション・ソース・コードを修正することにより解決される。

性能目標を満たすためのさまざまな要件が存在する。いくつかの実施形態では、これらの要件は、すべてのタスクが所望のスループットに対応するほどに十分に速く走らなければならないこと、ならびにタスク間のデータは、タスクがデータを待つ必要がないように十分速く流れなければならないことを必要とすることを含む。

タスク実行速度は、タスクがその機能を完了するために実行する必要がある命令の数により制限されることがある。この場合、この問題は、タスクを複数のタスクに分離することにより、またはいくつかの命令を他のタスクに移動させることによって負荷のバランスをとることにより、緩和される。これらのいずれも、手作業で行ってよい。あるいは、シミュレーションは、設計をさらに最適化するために使用することができる情報を記憶する。たとえば、あるループが、時間がかかりすぎて実行することができないことがわかった場合、ループベクトル化などの最適化をさらに使用して、結果を改善することができる。

マルチタスキングは、負荷分散のための、別の利用価値のあるツールである。小規模で高速に実行する多くのタスクを使用してアプリケーションを開発する場合、単一ＰＥを使用して、複数のタスクのすべてまたは一部分を実行してよい。タスクは、所望のスループットに対応していない場合、より多くの利用可能なコンピュータ資源を有するように、異なるＰＥに割り当てることができる。

タスク実行速度はまた、共通資源を求めて他のタスクと競合することにより制限されることがある。たとえば、２つのタスクは、同じメモリバンクに同時にアクセスしようとすることがある。これは、異なるメモリバンク内のアドレスに、または異なるメモリ内のアドレスにさえ、変数を再配分することにより解決することができる。シミュレーション中にこの情報を集め、この情報を使用して、変数を再配分する。

データを転送する際の遅延は、多くの場合、共有資源を求めて競合することに起因する。たとえば、２つの重要な通信は、同じＤＭＡエンジン、または同じルーティング資源の一部を共有していてよい。これにより、通信の一方は、他方の通信が完了するのを待っている間に機能停止させられることがある。通信機能停止に関する情報は、シミュレーション中に記憶され、タスクマッピングおよび通信マッピングを改善するために使用することができる。

電力を考慮することもまた、多くの埋込システムで重要である。タイミング性能データとよく似て、シミュレーション中に保存した電力データを使用して、資源マッピング、通信合成、およびバック・エンド・コンパイル中に最適化を改善することがある。

いくつかの事例では、静的分析を使用して、特有の試験データを必要とすることなく、シミュレーションと同じ性能限界のいくつかを見つけ出すことができる。たとえば、静的分析を使用して、潜在的メモリバンク衝突または潜在的通信衝突を見つけ出すことが可能であることがある。この情報をさらにまた資源マッピング、通信合成、およびバック・エンド・コンパイルに供給して、結果を最適化する。

反復の流れは、流れの中の後のステップで集めた情報を流れの中の前のステップに戻して供給する流れである。この場合、設計をさらに最適化するために、前のステップの一部またはすべてを再実行する。たとえば、コード最適化は、ある種の変数を追加または削除させてよく、その結果、資源マッピングの部分的再実行を余儀なくさせて、変数配置を調節する。または、シミュレーションもしくは静的分析から集めた情報を使用して、以前のステップ全体にわたり反復して、設計をさらに最適化してよい。これは、データベースがすべてのアプリケーションタスクに関するＩＲを含むので可能である。必要に応じて、最適化パスを走らせてよい。

さまざまな実施形態では、コンピュータ可読記憶媒体は、ソフトウェアアプリケーションのスワッピングに関係する機能など、上述のさまざまな機能を実装するために、ＭＰＳのプロセッサ、および／または１つもしくは複数の外部プロセッサにより実行可能なプログラム命令を記憶してよい。一般に、コンピュータ可読記憶媒体は、実行されたときに本明細書で記述する機能の一部分またはすべてを実装する任意の１組の命令を含んでよい。一般的に言って、コンピュータ可読記憶媒体は、コンピュータシステムに命令および／またはデータを提供するために、使用中にコンピュータによりアクセス可能な任意の記憶媒体を含んでよい。たとえば、コンピュータ可読記憶媒体は、磁気媒体または光媒体、たとえば、ディスク（固定または取外し可能）、テープ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、またはブルーレイなどの記憶媒体を含んでよい。記憶媒体は、ＲＡＭ（たとえば、同期型ダイナミックＲＡＭ（ＳＤＲＡＭ）、Ｒａｍｂｕｓ ＤＲＡＭ（ＲＤＲＡＭ）、スタティックＲＡＭ（ＳＲＡＭ）など）、ＲＯＭ、フラッシュメモリ、周辺インタフェースを介して、たとえばユニバーサル・シリアル・バス（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ、ＵＳＢ）インタフェース、フラッシュ・メモリ・インタフェース（ｆｌａｓｈ ｍｅｍｏｒｙ ｉｎｔｅｒｆａｃｅ、ＦＭＩ）、シリアル周辺インタフェース（ｓｅｒｉａｌ ｐｅｒｉｐｈｅｒａｌ ｉｎｔｅｒｆａｃｅ、ＳＰＩ）などを介してアクセス可能な不揮発性メモリ（たとえば、フラッシュメモリ）などの揮発性メモリ媒体または不揮発性メモリ媒体をさらに含んでよい。記憶媒体は、微小電気機械システム（ｍｉｃｒｏｅｌｅｃｔｒｏｍｅｃｈａｎｉｃａｌ ｓｙｓｔｅｍ、ＭＥＭＳ）だけではなく、ネットワークおよび／または無線リンクなどの通信媒体を介してアクセス可能な記憶媒体も含んでよい。搬送媒体は、コンピュータアクセス可能な記憶媒体だけではなく、有線伝送または無線伝送などの伝送媒体も含んでよい。

好ましい実施形態に関連して本発明のシステムおよび方法について記述してきたが、本明細書で示す特有の形態に限定することを意図するのではなく、それどころか、そのような代替形態、修正形態、および均等物を、添付の特許請求の範囲により規定される本発明の精神および範囲の中に合理的に含むことができるとして含むことが意図される。

Claims (20)

1. 方法であって、
   アプリケーション・ソース・コードを使用してフロント・エンド・コンパイルを遂行して、複数の中間表現および接続性情報を生成するステップであって、前記複数の中間表現のうちの特定の中間表現は、複数のタスクのうちの特定のタスクに対応し、前記接続性情報は、複数の接続を含み、特定の接続は、前記複数のタスクのうちの第１のタスクと前記複数のタスクのうちの第２のタスクとの間の通信を指定するステップと、
   前記複数の中間表現および前記接続性情報を使用して、マルチ・プロセッサ・アレイに含まれる物理資源に前記アプリケーション・ソース・コードに含まれる論理オブジェクトをマッピングして、資源マップを生成するステップと、
   前記複数の接続内の接続ごとに、対応する実装を選択するステップと、
   前記複数の中間表現を使用して第１の最適化動作を遂行して、複数の最適化中間表現を生成するステップと、
   前記複数の最適化中間表現を使用して実行可能コードを生成するステップと、
   前記マルチ・プロセッサ・アレイの上に前記実行可能コードをロードするステップと
   を備える方法。
2. 前記フロント・エンド・コンパイルを遂行する前記ステップは、
   前記アプリケーション・ソース・コードを構文解析して、初期中間表現を生成するステップと、
   前記初期中間表現を使用して少なくとも１つの第２の最適化動作を遂行して、前記複数の中間表現を生成するステップと、
   前記複数の中間表現を使用して、前記複数のタスク間の接続性を識別して、前記複数の接続を生成するステップと、
   プロジェクトデータベースに前記複数の中間表現および前記接続性情報を記憶するステップと
   を含む、請求項１に記載の方法。
3. 前記マルチ・プロセッサ・アレイは、複数のプロセッサを含み、前記複数のプロセッサのうちの特定のプロセッサは、データメモリを含み、前記論理オブジェクトをマッピングする前記ステップは、
   前記複数のプロセッサのうちの前記特定のプロセッサに前記複数のタスクのうちの特定のタスクを割り当てるステップと、
   前記データメモリに前記特定のタスクに関連する変数を割り当てるステップと
   を含む、請求項１に記載の方法。
4. 前記複数の接続内の接続ごとに、前記対応する実装を選択する前記ステップは、送信側から、前記複数の接続のうちの特定の接続に含まれる受信側にデータを転送するために直接メモリアクセスを選択するステップを含む、請求項１に記載の方法。
5. 前記マルチ・プロセッサ・アレイは、複数のプロセッサを含み、前記複数の中間表現を使用して前記第１の最適化動作を遂行して、前記複数の最適化中間表現を生成する前記ステップは、複数の命令のループをベクトル化して、前記複数のプロセッサのサブセットを利用するステップを含む、請求項１に記載の方法。
6. 前記実行可能コードをシミュレートして、シミュレーション結果を生成するステップと、
   前記シミュレーション結果に基づき、少なくとも１つの前記アプリケーション・ソース・コードを修正するステップと
   をさらに備える、請求項１に記載の方法。
7. コンピュータシステムで、あって、
   命令を記憶するように構成された１つまたは複数のメモリと、
   前記１つまたは複数のメモリから命令を受信するように構成された１つまたは複数のプロセッサであって、前記命令を実行して、前記コンピュータシステムに、
   アプリケーション・ソース・コードを使用してフロント・エンド・コンパイルを遂行して、複数の中間表現および接続性情報を生成するステップであって、前記複数の中間表現のうちの特定の中間表現は、複数のタスクのうちの特定のタスクに対応し、前記接続性情報は、複数の接続を含み、特定の接続は、前記複数のタスクのうちの第１のタスクと前記複数のタスクのうちの第２のタスクとの間の通信を指定するステップと、
   前記複数の中間表現および前記接続性情報を使用して、マルチ・プロセッサ・アレイに含まれる物理資源に前記アプリケーション・ソース・コードに含まれる論理オブジェクトをマッピングして、資源マップを生成するステップと、
   前記複数の接続内の接続ごとに、対応する実装を選択するステップと、
   前記複数の中間表現を使用して第１の最適化動作を遂行して、複数の最適化中間表現を生成するステップと、
   前記複数の最適化中間表現を使用して実行可能コードを生成するステップと
   を含む動作を遂行させるように構成された１つまたは複数のプロセッサと
   を備えるコンピュータシステム。
8. 前記フロント・エンド・コンパイルを遂行する前記ステップは、
   前記アプリケーション・ソース・コードを構文解析して、初期中間表現を生成するステップと、
   前記初期中間表現を使用して少なくとも１つの第２の最適化動作を遂行して、前記複数の中間表現を生成するステップと、
   前記複数の中間表現を使用して、前記複数のタスク間の接続性を識別して、前記複数の接続を生成するステップと、
   プロジェクトデータベースに前記複数の中間表現および前記接続性情報を記憶するステップと
   を含む、請求項７に記載のコンピュータシステム。
9. 前記マルチ・プロセッサ・アレイは、複数のプロセッサを含み、前記複数のプロセッサのうちの特定のプロセッサは、データメモリを含み、前記論理オブジェクトをマッピングする前記ステップは、
   前記複数のプロセッサのうちの前記特定のプロセッサに前記複数のタスクのうちの特定のタスクを割り当てるステップと、
   前記データメモリに前記特定のタスクに関連する変数を割り当てるステップと
   を含む、請求項７記載のコンピュータシステム。
10. 前記複数の接続内の接続ごとに、前記対応する実装を選択する前記ステップは、送信側から、前記複数の接続のうちの特定の接続に含まれる受信側にデータを転送するために直接メモリアクセスを選択するステップを含む、請求項７に記載のコンピュータシステム。
11. 前記マルチ・プロセッサ・アレイは、複数のプロセッサを含み、前記複数の中間表現を使用して前記第１の最適化動作を遂行して、前記複数の最適化中間表現を生成する前記ステップは、複数の命令のループをベクトル化して、前記複数のプロセッサのサブセットを利用するステップを含む、請求項７に記載のコンピュータシステム。
12. 前記動作は、
    前記実行可能コードをシミュレートして、シミュレーション結果を生成するステップと、
    前記シミュレーション結果に基づき、少なくとも１つの前記アプリケーション・ソース・コードを修正するステップと
    をさらに含む、請求項７に記載のコンピュータシステム。
13. 前記複数の最適化中間表現を使用して前記実行可能コードを生成する前記ステップは、前記複数の最適化中間表現のうちの対応する最適化中間表現を使用して、前記複数のタスクのタスクごとに、対応するオブジェクトコードを生成するステップを含む、請求項７に記載のコンピュータシステム。
14. プログラミング命令を中に記憶した非一時的コンピュータアクセス可能記憶媒体であって、コンピュータシステムによる実行に応答して、前記コンピュータシステムに、
    アプリケーション・ソース・コードを使用してフロント・エンド・コンパイルを遂行して、複数の中間表現および接続性情報を生成するステップであって、前記複数の中間表現のうちの特定の中間表現は、複数のタスクのうちの特定のタスクに対応し、前記接続性情報は、複数の接続を含み、特定の接続は、前記複数のタスクのうちの第１のタスクと前記複数のタスクのうちの第２のタスクとの間の通信を指定するステップと、
    前記複数の中間表現および前記接続性情報を使用して、マルチ・プロセッサ・アレイに含まれる物理資源に前記アプリケーション・ソース・コードに含まれる論理オブジェクトをマッピングして、資源マップを生成するステップと、
    前記複数の接続内の接続ごとに、対応する実装を選択するステップと、
    複数の中間表現を使用して第１の最適化動作を遂行して、複数の最適化中間表現を生成するステップと、
    前記複数の最適化中間表現を使用して実行可能コードを生成するステップと、
    前記マルチ・プロセッサ・アレイの上に前記実行可能コードをロードするステップと
    を備える動作を遂行させる非一時的コンピュータアクセス可能記憶媒体。
15. 前記フロント・エンド・コンパイルを遂行する前記ステップは、
    前記アプリケーション・ソース・コードを構文解析して、初期中間表現を生成するステップと、
    前記初期中間表現を使用して少なくとも１つの第２の最適化動作を遂行して、前記複数の中間表現を生成するステップと、
    前記複数の中間表現を使用して、前記複数のタスク間の接続性を識別して、前記複数の接続を生成するステップと、
    プロジェクトデータベースに前記複数の中間表現および前記接続性情報を記憶するステップと
    を含む、請求項１４に記載の非一時的コンピュータアクセス可能記憶媒体。
16. 前記マルチ・プロセッサ・アレイは、複数のプロセッサを含み、前記複数のプロセッサのうちの特定のプロセッサは、データメモリを含み、前記論理オブジェクトをマッピングする前記ステップは、
    前記複数のプロセッサのうちの前記特定のプロセッサに前記複数のタスクのうちの特定のタスクを割り当てるステップと、
    前記データメモリに前記特定のタスクに関連する変数を割り当てるステップと
    を含む、請求項１４記載の非一時的コンピュータアクセス可能記憶媒体。
17. 前記複数の接続内の接続ごとに、前記対応する実装を選択する前記ステップは、送信側から、前記複数の接続のうちの特定の接続に含まれる受信側にデータを転送するために直接メモリアクセスを選択するステップを含む、請求項１４に記載の非一時的コンピュータアクセス可能記憶媒体。
18. 前記マルチ・プロセッサ・アレイは、複数のプロセッサを含み、前記複数の中間表現を使用して前記第１の最適化動作を遂行して、前記複数の最適化中間表現を生成する前記ステップは、複数の命令のループをベクトル化して、前記複数のプロセッサのサブセットを利用するステップを含む、請求項１４に記載の非一時的コンピュータアクセス可能記憶媒体。
19. 前記動作は、
    前記実行可能コードをシミュレートして、シミュレーション結果を生成するステップと、
    前記シミュレーション結果に基づき、少なくとも１つの前記アプリケーション・ソース・コードを修正するステップと
    をさらに含む、請求項１４に記載の非一時的コンピュータアクセス可能記憶媒体。
20. 前記複数の最適化中間表現を使用して前記実行可能コードを生成する前記ステップは、前記複数の最適化中間表現のうちの対応する最適化中間表現を使用して、前記複数のタスクのタスクごとに、対応するオブジェクトコードを生成するステップを含む、請求項１４に記載の非一時的コンピュータアクセス可能記憶媒体。

Images