JP6894377B2 - 専用プロセッサ用ハードウェア命令生成ユニット - Google Patents

Description

（関連出願の相互参照）
本願は、２０１５年２月２５日に出願された「専用プロセッサ用ハードウェア命令コンパイラ」と題する米国仮特許出願第６２／１２０，６０３号の関連出願であり、米国特許法第１１９条（ｅ）の下でこの仮特許出願に基づく優先権を主張する。この仮出願は、完全且つ十分に本明細書に記載されているように全体があらゆる目的のために援用されることによって、本願に組み込まれている。

命令セットアーキテクチャ（ＩＳＡ）は、コンピュータープロセッサの設計及び開発において基本的なものである。ＩＳＡは、プロセッサの命令セット、命令のフォーマット、及び、プロセッサ特性（例えば、使用可能なオペランドのタイプ、命令実行に使用される記憶メカニズム、記憶メカニズムのアクセス方法等）を含む。命令セットは、プログラマがプログラムをプロセッサに通信するために用いられる。さらに、命令セットアーキテクチャは、コンパイラ、リンカ及びデバッガを含むプロセッサ開発及びプログラミング用の複数のソフトウェア「ツール」に用いられる。

コンパイラは、上位のプログラミング言語で記述された「ソースコード」を、プロセッサが理解可能な「オブジェクトコード」に変換する。リンカは、コンパイラが生成した１つ以上のオブジェクトコードファイルを単一の実行可能ファイルに結合し、さらに、コードを実行するためにプロセッサの適切なアドレス空間に配置することができる。デバッガは、プロセッサで動作するように記述されたプログラムをテストする際に用いられるプログラムである。これらのツールは、プロセッサ用の他の開発ツールと共に「ツールチェーン」と呼ばれる。プロセッサの命令セット又は命令セットアーキテクチャの他の特徴に対する変更は、ＩＳＡを使用する各ツールのツールチェーン全体に反映されなければならない。

ＩＳＡは、一般的に、ＩＳＡに基づいて仕様、シミュレータ及び開発用ツールチェーンを生成可能となるまで、十分に満足するまで広範にテストされ、変更され、検証される。そして、ＩＳＡに基づいてプロセッサ設計（マイクロアーキテクチャの設計と検証、ハードウェア記述言語（ＨＤＬ）によるマイクロアーキテクチャの実装、及び、ＨＤＬで実装された回路の合成を含む）を進めることができる。

ＩＳＡと、ＩＳＡと互換性のあるプロセッサとの高度な統合は、ＩＳＡ及び関連するツールの開発が膨大な作業となっていることに伴って、専用プロセッサ設計の実装が困難になる場合がある。新たな命令セットを生成したり、既存の命令セットを修正したりすることは、関連する検証と、生成又は修正する必要のある開発ツールとを考えると、非常にコストが嵩み、煩雑になる場合がある。

以下に開示する様々な実施形態の詳細な説明では、添付の図面を参照する。

データ処理アーキテクチャの例示的な実施形態の簡略ブロック図である。 専用プロセッサの例示的な実施形態の簡略ブロック図である。 ホストコンピュータを用いた命令生成ユニットの例示的な実装を示す簡略ブロック図である。 命令生成ユニットの実施形態を示す簡略ブロック図である。 本明細書に記載の命令生成ユニットが実行する処理の実施形態を示すフローチャートである。 本明細書に記載の命令生成ユニットが実行する処理の実施形態を示すフローチャートである。 本明細書に記載の命令生成ユニットが実行する処理の実施形態を示すフローチャートである。 本明細書に記載の命令生成ユニットが実行する処理の実施形態を示すフローチャートである。 本明細書に記載の命令生成ユニットが実行する処理の実施形態を示すフローチャートである。

（概要）
ホストコンピュータを専用プロセッサに接続する方法、装置及びシステムが開示される。一実施形態では、ホストコンピュータを専用プロセッサに接続するように構成された命令生成ユニットは、ホストプログラムのオペレーションコードと、第１仮想ホストプログラムオペランドと、をホストコンピュータから受信するように構成された属性ステージ（attribute stage）を備える。ここで、第１仮想ホストプログラムオペランドは、専用プロセッサの第１オペランドを表す。本実施形態では、属性ステージは、第１仮想ホストプログラムオペランドを第１オペランド記述子に拡張するようにさらに構成されている。ここで、第１オペランド記述子は、１つ以上のオペランド属性に関して第１オペランドの記述を提供する。命令生成ユニットは、第１オペランド記述子と、ホストプログラムのオペレーションコードと、を属性ステージから受信し、ホストプログラムのオペレーションコードを、専用プロセッサが実行するために１つ以上のデコードした命令に変換し、デコードした命令を専用プロセッサが実行するときに使用する記憶領域を割り当てるように構成されたデコードステージ（decode stage）を備える。本実施形態の命令生成ユニットは、デコードした命令をデコードステージから受信し、１つ以上のデコードした命令を１つ以上の命令キューに配置し、専用プロセッサが実行するために、デコードした命令を１つ以上の命令キューのうち少なくとも１つから発行するように構成された命令バッファステージ（instruction buffer stage）をさらに備える。

さらなる実施形態では、命令生成ユニットは、１つ以上のオペランド記述子を含む属性テーブルを記憶するように構成されたメモリをさらに備える。属性ステージは、ホストプログラムのオペレーションコードが第１オペランドの最初の宣言（initial declaration）に一致するか否かを判別するようにさらに構成されている。属性ステージは、ホストプログラムのオペレーションコードが第１オペランドの最初の宣言に一致していると判別したことに応じて、第１オペランド記述子を含むエントリを属性テーブルに記憶し、記憶した属性テーブルのエントリのアドレスをホストコンピュータに返すようにさらに構成されている。

一実施形態では、命令生成ユニットは、少なくとも２つの相互接続された処理ユニットのアレイを含む専用プロセッサと接続している。各処理ユニットは、命令バッファと、少なくとも２つの領域に分割されたデータメモリと、を備える。さらなる実施形態では、第１オペランドは、専用プロセッサの１つ以上のデータメモリの複数の領域にわたって記憶された二次元データアレイを含む。さらに別の実施形態では、相互接続された処理ユニットの各々の命令バッファは、１つの処理ユニットから次の処理ユニットへ順次命令を伝えるように構成された命令パイプラインによって接続されている。１つ以上の命令キューは、ベクトル命令キューと、スカラー命令キューと、を備える。命令バッファステージは、デコードした命令を１つ以上の命令キューから発行することに関連して、デコードした命令をベクトル命令キューから命令パイプラインに配置するように構成されている。

専用プロセッサ用の命令を生成する方法が本明細書で開示される。一実施形態では、この方法は、ホストプログラムのオペレーションコードと、仮想ホストプログラムオペランドと、をホストプロセッサから受信することであって、仮想ホストプログラムオペランドは専用プロセッサのオペランドを表すことと、仮想ホストプログラムオペランドをオペランド記述子に拡張することであって、オペランド記述子は１つ以上のオペランド属性に関してオペランドの記述を提供することと、ホストプログラムのオペレーションコードを、専用プロセッサが実行するための１つ以上のデコードした命令に変換することと、を備える。この方法の実施形態は、デコードした命令を実行するときに専用プロセッサによって使用される記憶領域を割り当てることと、１つ以上のデコードした命令を１つ以上の命令キューに配置することと、デコードした命令を、専用プロセッサが実行するために１つ以上の命令キューのうち少なくとも１つから発行することと、を含む。

さらなる実施形態では、この方法は、ホストプログラムのオペレーションコードが第１オペランドの最初の宣言に一致しているか否かを判別することを備える。この方法は、ホストプログラムのオペレーションコードが第１オペランドの最初の宣言に一致していると判別したことに応じて、第１オペランド記述子を含むエントリを属性テーブルに記憶し、記憶した属性テーブルのエントリのアドレスをホストプロセッサに返すことを備える。

一実施形態では、専用プロセッサは、少なくとも２つの相互接続された処理ユニットのアレイを備える。ここで、各処理ユニットは、命令バッファと、少なくとも２つの領域に分割されたデータメモリと、を備える。さらなる実施形態では、第１オペランドは、専用プロセッサの１つ以上のデータメモリの複数の領域にわたって記憶された二次元データアレイを備える。さらに別の実施形態では、相互接続された処理ユニットの各々の命令バッファは、１つの処理ユニットから次の処理ユニットへ順次命令を伝えるように構成された命令パイプラインによって接続されており、１つ以上の命令キューは、ベクトル命令キューと、スカラー命令キューと、を備える。かかる実施形態では、デコードした命令を１つ以上の命令キューから発行することは、デコードした命令をベクトル命令キューから命令パイプラインに配置することを含む。

本明細書ではデータ処理システムも開示される。一実施形態では、データ処理システムは、コンパイルしたプログラムを実行するように構成されたホストプロセッサと、専用プロセッサと、命令生成ユニットと、を備える。命令生成ユニットは、ホストプロセッサ及び専用プロセッサに動作可能に接続されており、ホストプログラムのオペレーションコードと仮想ホストプログラムオペランドとを、コンパイルしたプログラムから受信するように構成されている。ここで、仮想ホストプログラムオペランドは、専用プロセッサのオペランドを表す。命令生成ユニットは、専用プロセッサが実行するために、ホストプログラムのオペレーションコードを１つ以上のデコードした命令に変換し、デコードした命令を実行するときに専用プロセッサに使用される記憶領域を割り当て、１つ以上のデコードした命令を１つ以上の命令キューに配置し、デコードした命令を、専用プロセッサが実行するために１つ以上の命令キューのうち少なくとも１つから発行するように構成されている。

データ処理システムの一実施形態では、専用プロセッサは、少なくとも２つの相互接続された処理ユニットのアレイを備える。ここで、各処理ユニットは、命令バッファと、少なくとも２つの領域に分割されたデータメモリと、を備える。さらなる実施形態では、相互接続された処理ユニットの各々の命令バッファは、一つの処理ユニットから次の処理ユニットへ順次命令を伝えるように構成された命令パイプラインによって接続されており、１つ以上の命令キューは、ベクトル命令キューと、スカラー命令キューと、を備える。かかる実施形態では、命令生成ユニットは、デコードした命令を１つ以上の命令キューから発行するのに関連して、デコードした命令をベクトル命令キューから命令パイプラインに配置するように構成されている。

本明細書に記載された他の実施形態のうち上記の実施形態は、専用プロセッサ用のカスタム命令を生成するための、より一般的な方法を反映する。既存のアプローチとして、米国特許第６，４７７，６８３号は、特定の方法で構成可能な命令セットを記述するための標準化された言語の使用について説明している。標準化された言語の記述は、プロセッサの開発と構成のためのツールを生成するために使用される。しかしながら、かかる解決手段では、既存のアーキテクチャに対して、特定の、所定の限定数の変更のみが許される。

本明細書で説明するアプローチの実施形態では、オブジェクトクラスライブラリは、従来のコンパイラによって、及び、他のツールチェーンプログラムやアプリケーションプログラムの開発者によってアクセスされるように適合される。一実施形態では、オブジェクトクラスライブラリは、オブジェクト指向プログラミングのアプローチに関連するクラスやテンプレートを含む。かかる実施形態では、１つ以上のクラスは、アプリケーションプログラムによって提供されるデータを用いてオブジェクトとしてインスタンス化されるように構成されている。オブジェクトクラスライブラリは、コンパイル中のソースファイルに見慣れないオペランドや関数が見つかった場合に例えばコンパイラによってアクセスされる１つ以上のカスタムファイルを含む。

一実施形態では、オブジェクトクラスライブラリ内のカスタムファイルは、カスタム命令マクロ、又は、プロセッサに関連するカスタム機能ユニット、すなわち命令生成ユニット用のカスタム命令を生成するのに用いられるテンプレートである。カスタム命令は、オペレーションコードすなわちオペコードと、１つ以上のオペランドと、を含む。さらなる実施形態では、カスタム命令マクロは、従来のコンパイラのユーザ定義命令機能を用いて定義される。カスタム機能ユニットは、本明細書では、「命令生成ユニット」又は「ハードウェア命令コンパイラ」と呼ぶことができる。一実施形態では、カスタム機能ユニットは、従来のコンパイラから受信したカスタム命令であって、オペコードとオペランドとを含むカスタム命令を、専用プロセッサのハードウェア構成に適合した１つ以上の命令に変換する。

上述したオブジェクトクラスライブラリ及びカスタム機能ユニットを使用することにより、プログラマは、専用プロセッサのＩＳＡの詳細を理解することなく、専用プロセッサの機能にアクセスすることができる。必要なオペレーションを、プログラマのソースコードにおいて抽象的な表現で記述することができる。かかるオペレーションは、従来のコンパイラによって（オブジェクトクラスライブラリのカスタムファイルを用いて）、カスタム機能ユニット用の命令に変換される。次に、カスタム機能ユニットは、この命令を専用プロセッサに適した１つ以上の命令に変換することができる。一実施形態では、カスタム機能ユニットに対する命令は、専用プロセッサに対して１つ以上の変数を構成又は生成するための命令である。かかる命令は、本明細書では「コンストラクタ命令」と呼ばれる。一実施形態では、カスタム機能ユニットによって生成されるプロセッサ命令は、特定の長さやフォーマットに限定されない。

追加的な実施形態では、オブジェクトクラスライブラリ内のカスタムファイルは、専用プロセッサの１つ以上の機能のソフトウェアバージョンを実装するためにコンパイラのネイティブ命令セットで実行可能なソースコードを含む。さらなる実施形態では、このコードは、ソフトウェア実装を採用するオプションが選択されたときにコンパイルされる。

プロセッサのオペレーションのソフトウェアベースバージョンを実装するためのオブジェクトクラスライブラリの使用は、（ハードウェアベースの）プロセッサのオペレーションのテストに使用することができる。一実施形態では、ソフトウェアベースの処理を実装するコードは、ハードウェアベースのプロセッサと少なくともいくつかの同じステップを同じ順序で実行することができ、エラーの特定を支援するように実行可能である。ハードウェア命令コンパイラに対するカスタム命令を生成する場合と同様に、プログラマはオペレーションを抽象的に記述することができ、コンパイラの従来のユーザ定義機能は、オブジェクトクラスライブラリからカスタムルーチンを呼び出すために使用される。

さらに別の実施形態では、ソフトウェア実装用の命令を含むものと、カスタム機能ユニット用のカスタム命令を生成するために使用されるものとの両方が実行される上述した両タイプのカスタムファイルを使用して生成されるプログラム命令が実行される。一実施形態では、１つのプログラムは、専用プロセッサを用いて実行され、他のプログラムは、ネイティブ命令セットで実行される同じプログラムのソフトウェアベースバージョンである。さらなる実施形態では、ハードウェアベース及びソフトウェアベースのプログラムは、少なくとも部分的に同時に実行される。さらに別の実施形態では、テスト制御モジュールがプログラムの実行を管理し、実行される計算又は処理の１つ以上のポイントで、ハードウェアベース及びソフトウェアベースの実行結果を比較する。

（タイルプロセッサ）
本明細書で説明するオブジェクトクラスライブラリ及びハードウェア命令コンパイラと共に使用可能な専用プロセッサの一例は、米国特許第９，１８３，６９４号に記載されているタイルプロセッサである。この特許は、十分且つ完全に本明細書に記載されているものとし、参照することによって本明細書に組み込まれるものとする。タイルプロセッサは、画像処理に使用されるような二次元の相関データセットの効率的な高スループット処理に適合される。上述した特許出願で詳述されているように、タイルプロセッサは、ハードウェアベースの処理を実行するために、メモリ分割及び命令シーケンシングの新規技術を含む複数の特徴を用いる。しかしながら、本明細書に記載するカスタムコンパイルの方法及びシステムは、特定のタイプの専用プロセッサでの使用に限定されない。

本明細書で用いられる「視覚処理」は、画像、ビデオ画素（ピクセル）及び関連するデータの処理の一般的なクラスを指す。視覚処理は、画像の強調及びピクセルフォーマットの変換、動き検出及び追跡、並びに、静止画像やビデオフレームの特徴やオブジェクトの識別等のアプリケーションを含む。タイルプロセッサベースの視覚処理アーキテクチャは、膨大な視覚データセットを効率良く処理するために、プログラム可能でスケーラブルなソフトウェア互換ソリューションを幅広く提供する。このアーキテクチャは、このアプリケーション分野における従来のアプローチ（共有メモリ、対称型マルチプロセッシング（ＳＭＰ）の構成において単一命令多重データ（ＳＩＭＤ）コアを通常使用し、プロセッサの割り当て、通信、及び、プロセッサコア間の同期の問題を取り扱うカスタムプログラミング及び実行時環境を使用する。）の限界を克服する。

一方、タイルプロセッサベースのアーキテクチャでの処理は、自動的に割り当てられ、並列度の規模に応じて動的にスケーリングされる任意数の細かいタイルパスを使用しており、タイルパス間の通信のためのグローバル共有メモリを必要とせず、同期が一般的な順次実行モデルに基いている。一実施形態では、プログラミングは、コンパイラの再ターゲッティングを行うことなく、業界標準の命令セットアーキテクチャ（ＩＳＡ）での標準Ｃ＋＋を使用する。

このアーキテクチャは、並列実行を提供するために使用されるメカニズムの理解をほとんど必要としない、よく理解されたプログラミングモデルを使用して、大規模な並列実行を可能にする。これは、処理するハードウェアを、仮想化によって通常想定されるオーバーヘッドなしに、完全に仮想化された並列プロセッサとして提示することで達成される。仮想化は、通常、仮想オペレーションを解釈してハードウェアオペレーションに変換することに対する性能ペナルティを招く。その代わり、一実施形態では、タイルプロセッサベースのアーキテクチャは、Ｃ＋＋のオブジェクトクラスが表わす抽象を、例え当該抽象が数百あるいは数千のオペレーションを表していたとしても、通常、単一サイクルで直接実行する。並列実行の仮想化は、ハードウェア（命令生成ユニット（ＩＧＵ））が仮想命令をネイティブ命令に変換することと、ネイティブ命令を正しく並列実行するのを保証することと、の両方に依存している。

図１は、視覚処理アーキテクチャの高レベルのシステム図である。視覚処理アーキテクチャは、ホストコア１０２及びホスト命令／データ１０４により示されるローカルホストプロセッサと、ＩＧＵテーブル／ロジック１０６により示されるＩＧＵと、タイルパスアレイ（この例では２５６のタイルパス）で編成されたタイルパスと、システムインタフェースと、グローバルテーブル１０８と、を備える。図１のタイルパスは、ローカルデータメモリ１１０（斜線部分）と、処理ロジック（例えば、機能ユニット及び相互接続）１１２（白い部分）と、の組み合わせとして示されている。一連の２５６のタイルパスは、４つの行に折り返されている。非常に高度な構造と規則性があり、制御のオーバーヘッドのほとんどが、ＩＧＵとテーブルシステムユニットとに制限されている。

タイルパスは、機能ユニットと、オプションのレジスタファイル（オプションでアキュムレータを含む）と、ローカルデータメモリ（ＤＭＥＭ）と、を備える単純な処理要素である。命令メモリが無ければ、命令フェッチロジックもない。タイルパスによって実行される命令は、視覚処理オペレーションのみを実行し、ＤＭＥＭ及びレジスタファイルは、プログラム制御等のオーバーヘッドなしに、ピクセル及び関連するデータにのみ使用される。タイルパスは、命令を実行する以上のことをほとんどしない。制御ロジックは、タイルパス間の相互接続とデータコヒーレンシとをほとんど扱う。タイルパスは、任意数のタイルパスのタイルアレイで構成されているが、通常、１つのアレイが２５６〜１０２４のタイルパスで構成されている。

図２は、タイルアレイの例示的なブロック図であり、本明細書で説明するオブジェクトクラスライブラリ及びカスタム機能ユニットと共に使用可能な専用プロセッサの一例である。図２に示すようなタイルアレイの構成要素及びオペレーションは、米国特許第９，１８３，６９４号に記載されている。より具体的には、図２の相互接続された同一の処理ユニット２０４の各々は、個々のタイルプロセッサと呼ばれ、相互接続されたタイルプロセッサのグループが共に動作してタイル処理システム２０２を形成する。一実施形態では、本明細書で説明されるＩＧＵは、レジスタと、メモリと、ホストコンピュータの他の構成要素と共に、上記特許で説明されている「マスタプロセッサ」の命令フェッチ及びシーケンシングオペレーションを実行する。

図２のタイル処理システムの実施形態では、オペレーションが実行されるデータは、タイルプロセッサの集合的に分割されたデータメモリ２０６に記憶される。例えば、本明細書で使用する「タイル」は、ピクセル（又は他の二次元データ）の直線領域或いは二次元アレイを示す。各処理要素すなわちタイルプロセッサは、隣接するタイルが隣接するタイルプロセッサのデータメモリにマップされた、唯一のタイルのピクセルを処理する。これらのオペランドで使用される多値のオペランドは、タイル処理アーキテクチャのオブジェクトとして定義され、「オブジェクトトラッカ」を使用して識別される。したがって、この実施形態では、ホストコンパイラによって生成された命令に含まれるオブジェクトトラッカは、タイルプロセッサのデータメモリに記憶されたデータを参照することができる。（データのアレイ等の）多値のオペランドに対して多値の結果を生成するオペレーションとは対照的に、例えばアレイ内の全ての値の平均を求めるオペレーション等のように、スカラーの結果を作成するオペレーションも存在する。一実施形態では、このタイプのスカラーの結果は、図２に示すようなタイルプロセッサのデータメモリに容易に記憶されない。かかるスカラーの結果は、スカラー結果２０８の線で示すように、タイルプロセッサの相互接続構造を介して命令生成ユニットに戻され、ホストプロセッサに記憶される。

実行されるオペランド及びオペレーションを識別することに加えて、専用プロセッサ用にＩＧＵによって生成される命令は、専用プロセッサに有用な他のパラメータを含むことができる。タイル処理システムの例では、命令内の指定されたビットを用いて渡すことのできる有用な情報は、命令が米国特許第９，１８３，６９４号に定義されているような「タスク境界」に関するか否かに関する情報を含む。命令においてタイルプロセッサに渡すことのできる他の有用な情報は、上記特許の図２０及び関連するテキストに記載されているように、命令の「使用」及び「定義」番号を識別する情報である。かかる情報は、データコヒーレンシを維持するためにタイルプロセッサによって使用され得る。その他のタイプの専用プロセッサは、ＩＧＵによって生成された専用の命令でプロセッサに渡され得る、異なる種類の専用情報を使用することができる。

図２は、タイルアレイのサブセットを示しており、この例では、互いにローカルな４つのタイルパスが示されている。タイルパスは、同じ命令シーケンスを実行するが、同じ命令を同期して実行しない。命令は、時間と空間の両方に分配される。時間的には、命令が、同じタイルパスで異なるタスク間隔で繰り返されることによる。ここで、各間隔は、画像の異なる隣接位置を表す。空間的には、命令が、命令パイプラインを用いて、１つのタイルパスから次のタイルパスへ任意数のタイルパスにわたってストリームされる（コピーされる）ことによる。

全てのクロッキングは、タイルパスに対してローカルであり、グローバルストール（global stall）信号は存在しない。ストールは、スキッドバッファを用いて、上流の命令をサイクル当たり１タイルパスの速度で停止させることによって、タイルパス間の命令パイプラインを中断することによって実行される。この形式の命令の分配及び実行は、グローバルなメカニズムを必要とせずに、タイルパス間の細かいデータ共有を可能にする。

タイルアレイの実装は、ＳＩＭＤ／ＳＭＰ構成と比較して以下の多くの実装上の利点を有する。
・タイルパスは、レジスタファイル及びＤＭＥＭに対して幅広いＲＡＭを必要としない。ＳＩＭＤは、は６４ビットか３２ビットのデータパスを想定すると最大２０４８ビット幅のＲＡＭと同等のＲＡＭを必要とするが、タイルパスは、典型的な３２ビット（又は１６ビット）のデータパスとの違いがない。
・ローカルな近傍のピクセルにアクセスする場合、大きな多重化構造を必要としない。ＳＩＭＤでは、所定位置の左右のピクセルにアクセスする要求が、多数のデータパスにわたってＲＡＭ出力を多重化するオーバーヘッドのために、通常、両側の２〜３ピクセルに制限される。タイルパスでは、事実上完全に相互接続されているものの、相互接続が桁違いに簡素化されているため、このようなアクセスに関する制限はない。
・ＳＩＭＤは、３２又は６４ピクセルの単位で割り当てられるのに対し、タイルパスは、１ピクセルの単位で動的に割り当てられるので、タイルパスのエネルギー効率はＳＩＭＤより高い。この割り当ては命令毎に行われる。このため、例えば、１０２４幅のベクトルに対するオペレーションでは２５６のタイルパスを使用でき、その直後のオペレーションでは、５１２幅のベクトルに対して１２８のタイルパスのみを使用し、残りの１２８のパスのクロックを停止する。
・相互接続でのデータ転送の単位はスカラーであり、システムレベルではスカラーのストリームである。ＳＩＭＤは、一般的に、例えばＳＩＭＤの幅のクロスバー等のベクトルレベルの相互接続を必要とし、システムレベルのデータは、ＳＩＭＤに転送される前に、場合によってはピクセルのインターリーブやデインターリーブを用いてベクトルに集約される必要がある。これにより、システムの相互接続がタイルパスに比べて複雑になるだけでなく、処理の遅延が生じる。単一のタイルパスは、他のタイルパスとは独立して、スカラー入力を受信すると直ぐに処理を開始することができる。ベクトルはシステムレベルで露出しないので、明示的なピクセルのインターリーブやデインターリーブがない。代わりに、ピクセルのフォーマットは、タイルアレイ内でスカラーから抽象的なベクトルをアセンブルするために、プログラムがどのように記述されるかによって決定される。
・ストールによって、同じサイクルで全てのデータパスがアイドル状態になるわけではない。その代わりに、タイルパスは、独立してストール状態を検出し、ストール状態を連続するサイクルで命令パイプラインを介して伝搬する。極端なケースを例として用いると、６４のタイルパスは、ストールによって１サイクルを無駄にするだけで、６４の独立したストール状態を解決することができる。実際、全てのパスにわたって検出されるストール状態の総数は、ストールを解決するのに必要なサイクルの総数よりもはるかに大きく、２〜３倍以上になることもある。これにより、潜在的なシステムレベルの競合の可能性がかなり高いにもかかわらず、サイクル当たりの命令（ＩＰＣ）レートがかなり高くなる。

この最後の点については、ほとんどの並列システムに対して逆の直感的な効果があるので、重点を置くべきである。既存の並列システムの基本的な特性は、通信と同期が、（例えば、セマフォを設定してテストするサイクル等の）必要な基本メカニズムのオーバーヘッドを上回るコア数で増加するストールを引き起こすことである。これは、通常、処理負荷が通信／同期に対する要求に比べて大きいアプリケーションを除いて、並列性に対する厳しい制限となる。この特性は、視覚処理には当てはまらない。なぜなら、通信／同期は、数百又は数千のピクセルにわたって命令毎に必要とされており、通信／同期の周期や全てのアプリケーションに亘る依存関係のトポロジーがほとんど予測できないからである。

これに対し、タイルアレイは、通信及び同期に余分なサイクルを必要としない。なぜならば、数十サイクルの比較的高い相互接続レイテンシであっても、これらのメカニズムが単一サイクルのロード及びストアオペレーションに組み込まれているからである。ストールメカニズムは、ストール状態の並列解決の恩恵を受けるだけでなく、タイルパスが追加されるので構造的な利点ももたらす。一例として、ＣＩＦ解像度のスケール不変特徴変換（ＳＩＦＴ）アプリケーションは、８８のタイルパスを使用し、タイルパス当たり０．８１のＩＰＣ（全てのパスに対して７０を維持）に対して５．３Ｍサイクルで４．３Ｍの命令を実行する。この構成では、ストール状態の総数が４．４Ｍであり、通常、ＩＰＣがはるかに低いことが予想される。予想される４．４Ｍサイクルではなく４．４Ｍのストールを解決するため、１．０Ｍサイクルだけ性能が低下している。

さらに、ＨＤ−１０８０の構成では、最大９６０のタイルパスを使用することができ、１６Ｍの命令を２５Ｍサイクルで実行する。ＩＰＣは、タイルパス当たり０．６４（全てのパスに対し６０７を維持）である。ストール状態の総数は２８２Ｍであって、命令総数の１７倍以上である。予想通り、より多くのタイルパスを追加したことにより、より多くのストール状態が追加される。しかし、ストール状態が並列に解決されるので、性能への影響が大幅に低減する。これは、多数のタイルパスを建設的に使用可能であることを意味する。

（命令生成）
タイルアレイの命令生成は、任意の適切なローカルホストＩＳＡに適合された独特なメカニズムを使用する。ツールチェーンがＣ＋＋や同等の機能を備えたオブジェクト指向言語に基づいている限り、ＩＳＡ用の既存のソフトウェアツールチェーンに変更を加える必要がほとんどない（ある意味で全くない）。したがって、これは、ホストＩＳＡの拡張であり、本明細書では、命令のセットをまとめてビジュアルプロセッシング拡張（ＶＰＸ）と呼ぶ。

ＶＰＸは、一実施形態ではGnu Compiler Collection（ＧＣＣ）の__builtin_customマクロを用いたカスタム命令の概念に基づいている。これらのマクロは、オペコード（通常、列挙子を用いる）と、（レジスタに割り当てられる）即値又は変数の２つのオペランドとを定義するマクロを用いて、所定の命令をコンパイラに発行させる。変数は、整数型、浮動小数点型又はvoidポインタ型（後者はメモリアクセスを許可する）の何れかの型を有する。命令は、他の変数に割り当てられた結果を返すように定義することができる。結果を伴うので、命令は、３オペランドの非破壊命令である。

コンパイラは、カスタム命令によって実行される機能を必ずしも認識する必要がない（通常、何等かの抽象的なマシン記述を用いて認識可能であるが）。コンパイラは、他の命令と同様に、レジスタの割り当てや手続きのリンクに関与する命令等とともに、使用される変数／即値を単に管理し、結果を処理する。これにより、コンパイラは、基本となるタイルパスや命令エンコーディングの詳細にさらされる必要なしに、最終的にタイルアレイの命令を発行することができる。カスタム命令の属性は、柔軟性の高いタイルアレイのコードをコンパイルするのに使用されるが、ツールチェーンが複雑になることがなく、ツールチェーンがタイルパス命令のセマンティクスを理解する必要もない。

コンパイラが命令の機能を認識する必要がないという事実は、ＶＰＸ命令の仮想化を可能にする。ＶＰＳ命令は、命令が通常行うように、機能を直接的にエンコードするのではなく、むしろＩＧＵがタイルアレイへの命令を生成して発行するために使用される情報をエンコードする。例えば、分岐や手続きリンクを扱わない点でソフトウェアコンパイラほど汎用ではないという点を除き、ある意味、ＩＧＵはＶＰＳ用のハードウェアコンパイラである。この汎用性に欠けるということは、実際には強みである。なぜならば、例えば分岐による制御フローの変更は、通常、ソフトウェアコンパイラにおけるレジスタ割り当ての効率を制限するからである。ほとんどのコンパイラが３２個以上のレジスタを効率良く割り当てられないのに対し、ＩＧＵは、例えば１０２４個以上のレジスタを用いて、レジスタ割り当てをより効率的に行うことができる。

（仮想化したプログラミングモデル）
一実施形態では、タイルアレイのアプリケーションは、Ｃ＋＋のクラスライブラリに基づいている。このクラスライブラリは、仮想タイルアレイの機能を２つの異なる形式で実装する。第１の形式は、純粋にソフトウェアで実装されており、タイルアレイと完全に同等の機能を有するが、ハードウェア上で実行されないため非常に実行が遅い。第２の形式は、単にＶＰＸ命令をインラインで発行するものであり、クラスライブラリへのプロシージャコールのオーバーヘッドがなく、スーパースカラーパイプラインで、他のホスト命令と可能な限り並列に、１サイクルで実行する効果がある。

これらの２つの仮想化の形式を用いるクラスライブラリ用の３つの異なるビルドオプションが存在し、コンパイラのフラグで選択できる。１）クラスライブラリのソフトウェア専用エミュレーションを用いて、タイルアレイの実装に依存しないプロトタイプの生成。２）最小限のソフトウェアオーバーヘッドで、ターゲットとなるタイルアレイに対する命令の生成。３）協調シミュレーションと検証に使用されるソフトウェアエミュレーションとタイルアレイのカスタム命令の両方を実装するハイブリッドバージョン。２）のハードウェアのみのバージョンについて以下に説明する。

最初に、３つの整数DataVector a、b、cの宣言を考える。a及びbの幅はwidthで定義される（幅は、必ずしも宣言で定義される必要がなく、ベクトルは、cに適用するように割り当てることにより幅を継承することができる）。プログラムでは、aとbを加え、その結果をcに割り当てる文が後に続く。
DataVector<int> a(width), b(width), c;
…
c = a + b:

コンパイラは、a、b、ｃの宣言を検出すると、ライブラリが定義するオブジェクトのコンストラクタを呼び出す。これらのコンストラクタは、（本明細書で説明するバージョンのライブラリでは）１つ又は２つのカスタム命令を含んでおり、オブジェクトは、オブジェクトトラッカと呼ばれる単一の変数を含む。カスタム命令は、データ型や幅等のオブジェクトの属性をエンコードする。幅以外のかかる情報はコンパイル時に定数として提供され、幅の値をレジスタが保持している場合、コンストラクタ呼び出しは、１サイクルのインライン命令となり、オーバーヘッドが最小限に抑えられる。

コンストラクタカスタム命令は、オブジェクトトラッカに割り当てる結果を返す。このオブジェクトトラッカは、後続のオブジェクト変数に対するオペレーションで使用され、他の全てのオブジェクト変数と同様に扱われる。例えば、上記の例でオーバーロードされた加算は、aとbのオブジェクトトラッカを２つのオペランドとして有する１つのカスタム命令を生成し、加算結果の一時的なオブジェクトトラッカを結果として返す。これをcに割り当てるために、コンパイラは、このオブジェクトトラッカを単にコピー（あるいは伝搬）して、ｃのオブジェクトトラッカとする。

これにより、コンパイラは、非常に大きな視覚オブジェクトを、レジスタに割り当てたり、手続きリンクに関与したり、動的に割り当てられたり等のように、あたかもそれが他の変数であるかのように取り扱うことができる。コンパイラは、オブジェクトのマシン記述やその動作やタイルパス命令の定義を認識する必要がない。これから理解されるように、タイルパス命令の定義と実行は他の如何なるアーキテクチャとも異なるため、このことは重要である。タイルパス命令は、命令長やデータ型の制限等のようなツールチェーンに起因する制限を受けずに、タイルパス及びアレイの利点のために定義することができる。また、タイルパス及びタイルアレイの実装が非常に異なる場合でも、互いにバイナリ互換となり得る。

（ＩＧＵの概要）
図３は、本明細書で説明されるシステム及び方法を実施する際に使用されるホストコンピュータ３００の例示的な実施形態の簡略化したブロック図である。図３に具体的に示される構成要素に加え、ホストコンピュータは、当業者が理解するような従来のコンピュータの方法で相互接続された、従来のコンピュータの構成要素（例えば、電源及び電源への接続のための構成要素等）を含む。一実施形態では、本明細書で説明されるオブジェクトクラスライブラリを用いて従来のコンパイラによってコンパイルされたプログラムを、図３に示すようなホストコンピュータで実行する。一般的なレベルでは、図３の中央右側部分に示すＩＧＵ３０２以外の要素は、従来のプロセッサでも見られる要素である。

一実施形態では、ホストプロセッサは、図３に示すオペランドdataA及びdataBを含む命令を実行する。さらなる実施形態では、ホストプロセッサによって実行される命令は、３２ビット命令である。いくつかの命令では、オペランドdataA及びdataBは、従来の形式の数値や変数を表し、命令は、ホストプロセッサのネイティブ命令セットを用いて従来通りに実行可能である。一実施形態では、このような命令は、図３のＩＧＵを使用せずに、ホストレジスタファイル３０４と、ホストデータメモリ３０６と、他の機能ユニット３０８と、によって表されるプロセッサを用いて実行される。図３のホストプロセッサによって実行される他の命令は、上述したように、コンパイラがオブジェクトクラスライブラリ内のカスタム命令マクロを使用して生成したカスタム命令である。かかる命令は、ＩＧＵによって扱われる。

図３のＩＧＵ（本明細書では、「カスタム機能ユニット」又は「ハードウェア命令コンパイラ」とも呼ばれる）は、コンパイラが生成したカスタム命令によって使用されるオペランドdataA及びdataBの値を認識するようにプログラムされている。ハードウェア命令コンパイラは、カスタム命令のオペランドとオペコードとを用いて、ＩＧＵに接続された専用プロセッサに対する１つ以上の適切な命令を生成する。図３の実施形態では、ＩＧＵは、ＩＧＵから専用プロセッサへ命令パイプラインＩ−Ｐｉｐｅを用いて命令を送信し、専用プロセッサから１つ以上のスカラー結果を受信することによって、専用プロセッサに接続されている。ＩＧＵは、専用プロセッサから見ると、「命令生成ユニット」である。なぜならば、ＩＧＵは、専用プロセッサの命令の順序付けやマルチタスク処理等の付加的なオペレーションを含むことができるからである。

ＩＧＵを用いて処理され得るカスタム命令の例として、２つの例示的なタイルプロセッサホストカスタム命令セットアーキテクチャ表（以下、「カスタムＩＳＡ表」）を以下に示す。以下の表は、例示的な実施形態において、コンパイラによって生成され、図１のＩＧＵに提供され得るカスタム命令のいくつかを定義する。シフト命令、ブール命令及びムーブ命令等の複数の他のタイプの命令も実際の実装に含まれる。カスタムＩＳＡ表の情報は、ユーザ定義関数を実装するためにコンパイラによってアクセスされるオブジェクトクラスライブラリ内の１つ以上のファイルに含まれる。かかる情報を使用して、コンパイラは、dataA及びdataBのようなオペランドと、所望のオペレーションに対応するオペコードと、を含むカスタム命令を生成することができる。一実施形態では、カスタム命令は３２ビット命令である。

専用プロセッサの性質に依存して、dataA及びdataBのようなオペランドは、複数のデータ値を表すことができる。例えば、上記米国特許第９，１８３，６９４号のタイルプロセッサのオペランドは、データの二次元アレイを表すことができる。カスタムＩＳＡ表の例では、カスタム多値フォーマットを有するそのような変数は、オブジェクトとして定義され、「オブジェクトトラッカ」（「objTracker」）を用いて識別される。表１のカスタムＩＳＡ表のCONSTRUCT命令等の特定のカスタム命令は、特定の変数に対応したオブジェクトを生成し、特性を割り当てるために使用されてもよい。その他のカスタム命令は、オブジェクトトラッカによって識別される変数を用いてオペレーションを行う際に使用される。例えば、表２のカスタムＩＳＡ表のADD命令は、オペランドdataAが示すオブジェクトトラッカによって識別されるデータと、dataBが示すオブジェクトトラッカによって識別されるデータとを加算し、結果が示すオブジェクトトラッカに関連するメモリ領域に演算結果が記憶される。一実施形態では、これらのオブジェクトトラッカの１つ以上に関連するデータは、専用プロセッサ内の１つ以上のデータメモリに記憶される。

カスタムＩＳＡ表によって定義されたインタフェースを用いてタイルプロセッサのアレイ（タイルアレイ）と接続するように設計されたＩＧＵの例では、ＩＧＵは、表２のカスタムＩＳＡ表のADD命令を受信したことに応じて、タイルアレイが必要とする形式で加算命令を生成する。このように、ホストプロセッサのコンパイラは、タイルプロセッサ（又は他の専用プロセッサ）によって必要とされる命令の形式に関する情報を必要としない。ホストコンパイラは、ホストコンパイラのためのユーザ定義命令を設定するオブジェクトクラスライブラリ内のファイルで定義されたカスタム機能ユニットへのインタフェースを用いる。ハードウェア命令コンパイラは、如何なる長さで、如何なる形式の命令を専用プロセッサが必要としようとも、専用プロセッサのための命令を自由に生成することができる。専用プロセッサの開発は、プロセッサが必要とする命令の形式が結果的に変更され、専用プロセッサに対する如何なる変更にも適応するために修正を要するのがハードウェア命令コンパイラだけである場合、開始することができる。

図３の実施形態では、ＩＧＵは、ホストのデータパスにおける機能ユニットとして実装されているが、ＶＰＸ命令を直接実行するのではなく、それらを解釈する。この機能ユニットは、２つの入力オペランドと、結果のバスと、を有する。このユニットは、ローカルホストに対して、オブジェクトトラッカ（又は固定値）を受信してオブジェクトトラッカを返すだけであるため、ほとんどの命令を１サイクルで実行するのを明らかにする。コードの例に戻ると、例えば、コンストラクタカスタム命令がＩＧＵに発行されると、ＩＧＵは、スタックベースの割り当て方法を用いて属性テーブルにエントリ（記述子）を単に割り当て、データタイプや幅等のオブジェクトに関する情報を書き込んでいる間に、テーブルのエントリのアドレス（オブジェクトトラッカ）を返す。タイルパス内に共有ＤＭＥＭを必要とするオブジェクトに対しては、オブジェクトにベースアドレスを割り当て、必要なメモリも割り当てる。このベースアドレスは、タイルパスの命令生成に使われる。さらに、例えば循環バッファ等のように他の制御状態を含むオブジェクトに対しては、状態を初期化する。

先の例における加算等の他の命令では、ＩＧＵは、属性テーブルのエントリにアクセスして適切な形式のタイルパスADD命令を生成し、タイルアレイに発行する。ＩＧＵのさらなる詳細については以下に説明するが、ここにいくつかのハイライトを挙げる。
・ＩＧＵは、全ての制御、順序付け及びコヒーレンシのオペレーションを実行する。逐次実行モデルを採用しており、例えば、メモリへの書き込みは、同じ位置の読み出しよりも常に先行し、全ての読み出しは、後続の書き込みの前に実行される。タイルアレイにおける実行は、大規模なアウトオブオーダであるが、逐次実行モデルに基づくタイルパス命令において提供される情報を用いて、順次オーダが等価的に維持されている。
・ＩＧＵは、システムインタフェースとグローバルテーブルのオペレーションを管理する。例えば、ＩＧＵは、ベールアドレス及びアクセス幅をタイルパスとは独立に提供する。これらのオペレーションは、完全にタイルパスの外側で行われる。タイルパスは、グローバルな詳細と全く関わることなく、ロード、ストア及びヒストグラムのオペレーションを単に実行し、ローカルオフセットとデータを提供する。
・ＩＧＵは、タイルパスに対して全てのレジスタ及びメモリの割り当てを行う。この割り当ては、レジスタのスピル／フィルを含み、（オプションで）アキュムレータを割り当てて積和演算を合成する。この割り当ては、従来のコンパイラが処理しなければならない場合に行う割り当てと同等で、一般的であり、実際にはより効果的である。なぜならば、カスタム命令のストリームには、分岐がなければ手続きの呼び出しもなく、明示的な手続のリンクの必要もないからである。スピルされる全てのオブジェクトは、ＤＭＥＭの位置が割り当てられるが、この位置は、スピルが必要なときにのみ割り当てられる。十分な数のレジスタ（通常、１つのピクセル位置に対して２５６個）があれば、スピルはめったに起こらないし、フィルはさらに珍しい。なぜならば、オブジェクトは、手続きからの復帰（又は削除）でデストラクトされ、再び使用されることがないからである。
・ＩＧＵは、共有データをコヒーレンシが保たれるように管理する。例えば、レジスタはタイルパス間で共有されないので、共有データは、一時的な評価時以外にレジスタに割り当てられない。
・命令は、１つのオペレーションが如何なる数のデータタイプに対しても定義できるように、タイプのタグを使用する。例えば、符号付／符号無整数の加算と浮動小数点の加算は、データタイプを識別するフィールドを除いて同一である。これは、基礎となるオペレーションをサポートするようにタイルパスが設計されていると仮定すると、固定小数点等のユーザ定義のタイプを含むように拡張することができる。

（実装の概要）
図４は、図３のＩＧＵ３０２の構成及びオペレーションを示す例示的なブロック図である。上述したように、ＩＧＵは、ホストのデータパス内の機能ユニットとして実装されるが、ＶＰＸ命令を直接実行するのではなく、それらを解釈する。この機能ユニットの例示的な構成は、２つの入力オペランド（ホストdataA及びホストdataB）を有し、１つの結果（ホスト結果）を返す。ホストdataAは、ほとんどの場合オブジェクトトラッカを含むが、例外として、コンストラクタ命令に対してはオブジェクトのパラメータを有し得る。ホストdataBが存在する場合、ホストdataBは、もう１つのオブジェクトトラッカ、固定値（即値）又はコンストラクタ情報の何れかを含む。ホスト結果が命令で定義されている場合は、ホスト結果は、通常、命令の結果に対してＩＧＵが割り当てたオブジェクトトラッカである。しかしながら、ホストに戻されるVectorSummaryオブジェクト内のスカラー値であってもよい。

ＩＧＵは、図の上部、中央部、下部に対応する３つのパイプラインステージ（属性ステージ４０２、デコードステージ４０４、Ｉ−バッファステージ４０６）に分けて実装される。以下の章では、各ステージのオペレーションの概要を示す。この概要以降の章では、各ステージのオペレーションの詳細を説明する。

（属性ステージの概要）
属性ステージは、ホストプロセッサへのメインインタフェースを実装し、ＶＰＸオペコードとdataA及びdataBとを受信し、結果のオブジェクトトラッカを返す。主な機能は、１）オブジェクト記述子を属性テーブルに書き込み、コンストラクタ命令を実行する。２）これらの記述子を、命令実行に伴う要求により更新する。３）記述子を削除して、デストラクタ命令を実行する。４）ＶＰＸ命令をタイルパス命令に変換するのにデコードステージが必要な情報を集める。属性ステージは、この情報をデコードステージに出力する。

属性ステージは、コンストラクタ命令を受信すると、属性テーブル４０８の次のエントリを割り当て、命令に含まれるパラメータに基づいて記述子情報を書き込む。また、ローカルパラメータに基づいて情報を書き込む。例えば、タイルパスのＤＭＥＭを、共有データの循環バッファを実装するLineBufferオブジェクトへ割り当てる。循環バッファを実装するには、循環バッファのサイズに基づいて、バッファを実装するためのいくつかのＤＭＥＭラインが必要である。属性ステージは、属性テーブルのエントリのアドレスを、命令の結果として返す。これが、このオブジェクトの後続のオペレーションにおいてホストが使用するオブジェクトトラッカである。いくつかのオブジェクトは、全てのコンストラクタパラメータを伝えるために２つの命令を必要とし、この場合、オブジェクトトラッカは、２番目の命令のために返される。

命令実行は、命令の結果に対する記述子を生成すること、又は、命令によって暗示されるオブジェクトの状態変化を反映するように既存の記述子を変更することが必要になる場合がある。例えば、１）２つのオブジェクトを加えると、入力オペランドが記述子に反映された新たなオブジェクトが生成される。２）LineBuffer変数を割り当てるには、変数によって実装される循環バッファの状態を更新する必要がある。３）DataVectorオブジェクトを割り当てることは、オブジェクトの幅を変更し得る。これらの場合には、属性ステージは、新たな記述子を生成して、オブジェクトトラッカをホストへ返すか、属性テーブル内の位置のうち、命令のオブジェクトトラッカによって定義された位置にある記述子を更新する。

デコードステージへの主な出力は、元のＶＰＸ命令をパイプライン化した命令と、２つの入力オペランド及び結果に関する他の情報と、である。この場合、dataAオペランドは、オブジェクトトラッカの代わりに、オペランドの記述子に変換される。dataBオペランドは、オペランドの記述子、又は、オペランドの固定値とそのデータタイプの識別子である（変数に対しては、データタイプは記述子に含まれる）。これらの記述子は、属性テーブルを変更する前に、属性テーブルに関連して変更され得る。属性ステージが生成した結果に対する記述子もデコードステージへ伝えられる。

（デコードステージの概要）
図４の中央に示すＩＧＵのデコードステージは、命令及び属性情報を属性ステージから受信し、レジスタ割り当てフラグとレジスタ割り当てキューとを用いて、レジスタの割り当て及び割り当ての解除を行う。また、デコードステージは、専用プロセッサのための命令を形成し、その命令を命令バッファステージに渡す。デコードステージは、ＶＰＸ命令のシーケンスを、機能的に同等のタイルパス命令のシーケンスに変換する。高レベルでは、これは、例えばＶＰＸのaddからタイルパスのaddのように、命令を一つのフォーマットから他のフォーマットに単に変換するだけである。しかしながら、レジスタ割り当て、スピル／フィル位置のＤＭＥＭ割り当てを含むレジスタのスピル／フィル、命令に依存情報を注釈することも含まれる。デコードステージは、図１に示すテーブルシステムユニット１１４に対する制御インタフェースを実装し、システムアクセス及びテーブルアクセスに対する依存性の追跡及び管理を含む。

レジスタ割り当ては、レジスタに含まれ得るオブジェクトのコンストラクタ命令の結果として行われる。これは、レジスタを共有できないため、共有データを含むオブジェクトを除外する。レジスタ割り当ては２つの仕組みを使用しており、「フリーリスト」には、割り当てられていないレジスタの識別子が含まれ、「割り当てＦＩＦＯ」には、既に割り当てられたレジスタを割り当て順に並べたリストが含まれる。フリーリストは、順序付けを必要としないが、レジスタが必要な場合にハードウェアが最も古く割り当てられたレジスタを選択できるように、割り当てリストが順序を保持する。なぜならば、最も古く割り当てられたレジスタは、近い将来必要とされる可能性が最も低いからである。

オペレーション中、コンストラクトオペレーションは、利用可能なレジスタが無い場合にレジスタを要求する場合がある。この場合、デコードステージは、ＤＭＥＭ位置の最上位アドレスから低いアドレスに向かって伸びるスタックを用いて、メモリ位置をスピル用に割り当て、スピル命令を発行する。後続のオペレーションが、既にスピルしたレジスタに対して演算を行う場合がある。この場合、他のレジスタにフィルオペレーションを割り当てるが、この割り当てが、同様にもう１つのスピルを引き起こす可能性がある。新たなレジスタが必要となる一時的な結果を有するオペレーションも、スピルを引き起こす可能性がある。多数の割り当てが、多数のスピルとフィル状態を引き起こすという事実にも関わらず、レジスタ割り当ては、最終的に、必要なレジスタが割り当てられ、スピルしたレジスタが全てＤＭＥＭに記憶されるという状態に辿り着く。

また、デコードステージは、共有データを読み書きする命令に依存情報を追加する。この情報は、実際の命令の実行が空間的、時間的にアウトオブオーダであっても、逐次実行モデルを実装する際にタイルパスを調整するのを可能にする。これは、共有データのアクセスに関連する情報を記憶する２つのテーブルを使用する。第１のテーブルは、各ＤＭＥＭの位置に対して、当該位置に最近書き込みを行った命令の識別子を保持する。このデータを読み出すオペレーションは、命令がターゲットメモリ内で実行されていることを要する。もう一つのテーブルは、さらに各ＤＭＥＭの位置に対して、当該位置に最近読み出しを行った命令の識別子を保持する。後続の書き込みが許可される前に、全てのタイルパスがこの読み出しを完了している必要がある。

デコードステージが実装するテーブルシステムユニットに対する制御インタフェース、すなわちテーブルシステムインタフェース４１０は、このユニットにグローバル情報を通信するのに使用する。これには、全てのタイルパスに適用される読み書きのためのテーブル又はシステムのベースアドレスが含まれる。タイルパスは、このアドレスからのオフセットのみを提供する。オペレーションが読み出し又は書き込みの何れであるかを示し、さらに、ヒストグラムオペレーションであるテーブルへの書き込みの場合、ヒストグラムオペレーションのタイプを示す。最後に、デコードステージは、所定の時間内のアクセスを一意に識別する情報を提供する。これは、特定のアクセスと、アクセスされるオブジェクト（オブジェクトトラッカを使用して）との両方に対する一意な識別子を含む。

これらのオペラ―ションはタイルアレイ上に分散されるので、所定の時間において、処理中に複数のテーブルアクセス及びシステムアクセスが存在する。異なるアクセスストリームは、要求キューを用いて追跡される。テーブルアクセスとシステムアクセスのための別々の要求キューがある。タイルパスに発行されるアクセス命令は、キュー識別子を含む。命令は、テーブルへのアクセスかシステムへのアクセスかをエンコードする。このように、個々のアクセスがキューエントリで識別されるので、多数のアクセスを処理できる。

全てのアクセスが終了すると、テーブルシステムユニット１１４は、対応するキューエントリが空であることを示す指示をデコードステージに返す。この指示には、デコードステージが最初に提供したオブジェクトトラッカも含まれる。デコードステージは、この指示を用いてオブジェクトの読み書きに対する同期を提供する。例えば、デコードステージは、読み出しが行われている間、同じテーブルへの書き込みを阻止する。全てのタイルパスに亘る読み出しが完了したことを示す信号をテーブルシステムユニットが通知すると、テーブルへの書き込みが続行される。

テーブルシステムインタフェース４１０は、システムレベルでのタイルアレイとの同期を可能にするグローバルバリアを実装する。これにより、バリアオペレーションの終了が許可される前に全てのテーブル及びシステムのアクセスが完了したことが保証される。

最後に、デコードステージは、命令シーケンスをローカルに最適化するための最適化キュー４１２を含む。例えば、このキューは、書き込みを先行する命令に組み合わせることができるため、命令は、追加サイクルなしにＤＭＥＭに書き込みを行う副作用を有する。このキューは、乗算及び加算のシーケンスを混合して、積和命令に変換する事もできる。積和命令は、乗算及び加算（又は加算及び乗算）を別々に２サイクルで実行するのではなく、１サイクルで終了する。

デコードステージの出力は、Ｉ−バッファステージのデコードした命令である。

（Ｉ−バッファステージの概要）
図４の下部に示すハードウェア命令コンパイラのＩ−バッファステージは、スカラーレジスタとスカラー機能ユニットとを含み、専用プロセッサからスカラーデータを受信し、ホストプロセッサによって提供された他のスカラーオペランドを用いてスカラーデータに動作し、スカラー結果を記憶する。また、Ｉ−バッファステージは、最適化キューと命令再実行バッファとを含み、専用プロセッサによる命令の実行を管理する。タイルアレイを専用プロセッサとして有する実施形態では、Ｉ−バッファステージが、米国特許第９，１８３，６１４号に記載された「主プロセッサ」の命令取得及びシーケンシングオペレーションを実行する。タイルプロセッサを専用プロセッサとする実施形態では、Ｉ−バッファステージは、デコードステージの最適化キューから命令を受信し、２つの命令バッファを管理する。１つの命令バッファはベクトル命令用（べクトル命令再実行バッファ４１４）であって、もう一つの命令バッファはスカラー命令用（スカラー命令キュー４１６）である。ベクトル命令はタイルパスによって実行され、Ｉ−バッファステージは、ベクトルＩ−パイプへの命令のシーケンシングを管理する。スカラー命令は、例えばベクトル内の最大値を求めるオペレーションのようにベクトル内オペレーションで生成されるスカラーを必要とするいくつかの命令を除いて、ＩＧＵによって直接実行される。後者の命令は、スカラー結果とベクトルオペレーションとを同期させるために、ベクトルバッファとスカラバッファの両方に配置される。

ベクトル及びスカラー命令バッファは、異なる目的を果たす。ベクトル命令は、複数のタスク間隔にわたって連続していることが求められ、各タスク間隔は、各タイルパスの特定の位置におけるオペレーションを表す。マルチタスク処理は、共有データを通信する際のレイテンシペナルティを回避することと、データの書き込みと読み出しとの間の依存性を解決することとが基本であるから、タスク間隔は、共有データへのアクセスによって定義される。しかしながら、タスク間隔は、テーブル及びシステムアクセスのレイテンシをカバーするためにも定義され、デコードステージ又は結果的にホストから受信した命令の状態に関係無く命令が発行されるように、バッファ内の命令シーケンスの最後をマークするためにも定義される。後者の点は、命令バッファの別の利点を示している。それは、タイルアレイの性能は、ホストからのＶＰＸ命令の瞬間的なバンド幅から分離することができるということである。タイルアレイをピーク速度で実行し続けるには、ある時間間隔における平均バンド幅のみが必要となる。

スカラー命令バッファは、スカラーオペレーションをベクトルオペレーションに同期させる。スカラーオペレーションはベクトル全体に亘る処理が必要であって、このことは、全てのタイルパス及びタイルパス内の全てのローカル位置（領域）において、スカラーを生成する全ての命令を実行しなければならないことを意味する。このため、スカラー処理のレイテンシは、通常長い。クラスライブラリは、ホストの実行からこのレイテンシを分離するプログラムを許可するVectorSummaryオブジェクトを実行する。スカラーが生成されるのをホストが待機することを要求するのではなく、ホストによって何時でもアクセスされるように、スカラー結果をVectorSummaryオブジェクト内に配置する。ベクトルが如何なる幅も有し得るので、このレイテンシは、特定の変数の幅によって変化する。このため、スカラーは、スカラー同士に関して、又は、VectorSummaryオブジェクトへの如何なるオペレーション（例えば２つのスカラー値の加算等）に関しても、結果の自然な順序付けをせずに生成される。スカラー命令バッファは、キュー４１６として実装され、オペレーションを元の順序に維持している。スカラー結果を生成するベクトル内演算命令をＩ−バッファが発行すると、命令は、結果を受信するキューエントリを識別する。

Ｉ−バッファステージは、グローバル相互接続上で送信されるパケットに埋め込まれたサイドバンド情報を処理する。サイドバンド情報の一つは、読み出される最後のベクトル要素で共有データの読み出しが完了したときに、送信される。このことは、データへの書き込みが有効になったことを指示する。所定の書き込みに対して複数の読み出しオペレーションが存在し、この指示は、ＩＧＵによって追跡されているように、最近の読み出しに関連しているときのみ、書き込みを有効にする。他のサイドバンド信号は、結果がスカラーとなるベクトル内オペレーションを実行するために、最後のタイルパスによって送信される。なぜなら、スカラー結果は、全てのベクトル要素が処理された後にのみ生成されるからである。このスカラー結果は、他のスカラーオペレーションと適切なシーケンシングを行うために、スカラー命令キューに配置される。

最後に、Ｉ−バッファは、命令パイプラインの最後のタイルパスのＩ−パイプ出力に接続されている。これにより、ＩＧＵは、例えば無限停止状態等の中断がＩ−パイプに生じたのを検出することができる。これにより、かかるエラー状態を表す信号を送信するタイマを実装することが可能になり、回復が容易になる。Ｉ−バッファは、前述したタイルパスに関するバリアオペレーションも実行する。Ｉ−バッファは、Ｉ−パイプバリアオペレーションをＩ−パイプに発行し、Ｉ−パイプの最後でこの命令が検出されたときに、全てのタイルパスで完了したことを検出する。

（属性ステージのオペレーションの詳細）
図５及び図６は、属性ステージのオペレーションのトップレベルのフロー図である。このステージは、デコードステージが機能停止状態（ステップ５０２）でなく、属性ステージから情報を受信可能な場合（この指標は、Ｉ−バッファステージが、デコードステージから命令を受信する状態にあるか否かも反映し得る）にのみ動作する。このレベルでの主要なオペレーションは、属性テーブル（図５）の状態に直接影響を与える命令に応答することであって、デコードステージ（図６）に対してオペランドを設定することである。

属性テーブルの記述子に直接影響を与える４つの命令がある。コンストラクト命令（ステップ５０４）は、新たな記述子を有する新たなオブジェクトをテーブルに生成する（ステップ５０６）。コピーコンストラクト命令（ステップ５０８）は、既存のオブジェクトの設定を用いて新たなオブジェクトを生成し、その値を新たなオブジェクトにコピーする（ステップ５１０）。このとき、既存のオブジェクトのデータタイプを、新たなオブジェクトのデータタイプに変換することが可能である。デストラクト命令（ステップ５０８の「いいえ」分岐）は、オブジェクトと、当該オブジェクトが使用しているリソース（例えば、属性テーブルのエントリ、割り当てられた全てのＤＭＥＭ及びレジスタ等）とを消去する（ステップ５１２）。最後に、リサイズ命令（ステップ５１４）は、新たな幅をオブジェクトベクトルに設定する（ステップ５１６）。図における最後の命令（ステップ５１８）では、フレームの高さや領域のサイズ等のグローバルフレームパラメータを設定する（ステップ５２０）。領域のサイズは、各タイルパスが処理する隣接ベクトルの要素やピクセルの数を制御する。

２組目のオペレーション（図６）は、入力オペランドが必要とする記述子を属性テーブルから取り出し（ステップ６０２，６０４）、（ベクトル又はスカラーの）結果を有する命令に対して新たな記述子のエントリを生成する（ステップ６０６，６０８，６１０，６１２）。新たなエントリのアドレスはホストに返されるが、エントリのアドレスは予め分かっているので、これは、エントリの生成と並行して行われる。新たなエントリの記述子は、オペランドの記述子から得られる。例えば、浮動小数点の数値が整数に加えられると、その結果は浮動小数点の数値である。Ｃ＋＋で定義される標準変換及びデータタイプの優先順位の規則に従い、デコードステージは、加算を発行する前に整数から浮動小数点への形式の変換を発行する。もう一つの例は、ベクトルをより幅の広いベクトルに加算すると、その結果は幅の広いベクトルとなるが、幅の狭いベクトルによって定義される要素だけが変化する。

表３は、記述子に含まれる情報のタイプをオブジェクトのタイプごとに示す表である。この情報は、次の何れかである。１）属性テーブルから直接アクセスされる。２）命令の結果に対して属性ステージによって生成される。３）命令の副作用として、属性ステージによって記述子が更新されることを反映し、デコードステージに伝える前に属性ステージによって変更される。これは、図のフローチャートにおいて「副作用デコード」と表記されたフローチャートコネクタの一態様である。この種のオペレーションに対するフローチャートは、非常に詳細で機械的であるため、ここでは示さない。しかしながら、必要なオペレーションのタイプの一般的な概要は、次の通りである。

LineBufferの読み出しは、現在バッファに含まれるデータ量及び読み出しのオフセットに応じて、有効又は無効にする必要がある。バッファのデータ量は、境界処理を含む所定のオフセットでの読み出しを満たすのに十分な量であるべきである。また、結果のベクトルの幅は、水平と垂直のオフセットの両方又は何れかに対して定義される幅による。バッファが初期化された場合には、出力が直ちに得られる。

ムーブ命令が割り当てオペレーションを実施するので、割り当てられたオブジェクトの記述子の状態は、ムーブ命令が要求するように変更される。たとえば、DataVectorをより幅の広いベクトルで設定すると、幅が広い方のベクトルと同じ幅に変更される。また、この命令は、Ｉｎｄｅｘの数式等の一時的なオブジェクトを、非一時的なオブジェクトに変更する。

LineBuffer割り当ては、ベースライン、有効なライン数、次に割り当てられる新たなライン等を含むバッファの循環アドレス指定の状態を更新する。これにより、属性テーブル内の記述子と、デコードステージに伝えられる記述子と、が変更される。

Indexオブジェクトは、定義されていない幅又は定義されている幅の何れかを有している。定義されていない幅の場合、他の事項（例えばオブジェクト幅等）がアクセスの幅を定義する。定義されている幅の場合、オブジェクト幅を置き換える。幅が定義されていると、幅を直接定義するのではなく、例えばアップサンプリングやダウンサンプリング等のように、アクセスされたオブジェクトの幅を変更する場合がある。この状態は、Indexオブジェクトで動作する式によって定義される。そこで、属性ステージは、これらの式を追跡し、これに応じてIndexの記述子を変更する必要がある。

何らかの理由によりアクセスが無効である場合（例えば、アクセスするのに十分なコンテキストを有していないLineBufferオブジェクトにアクセスする場合等）、属性ステージは、このアクセスに関係する全ての式を、次の割り当ての時点まで無効にする。これは、割り当てを無効にすることも含まれる。これは、特定のオブジェクトのプログラミング及び再使用を著しく簡素化する。なぜなら、多くの境界条件をテストすることなくオブジェクトを使用できるからである。オブジェクトは、入力条件が満たされるまで、ただ単に沈黙（silent）しているだけである。また、終了の条件に達した後もオブジェクトは沈黙する。

（デコードステージのオペレーションの詳細）
図７は、デコードステージのオペレーション全般のフローチャートである。図７のページ外コネクタとして、レジスタ割り当てのフローチャートを図８に示す。デコードステージの主要なオペレーションは、「ＶＰＸ命令のデコード」（ステップ７０２）として示されている。このオペレーションは、ＶＰＸ命令のシーケンスを、例えばタイルパス命令等のように専用プロセッサ用と同等の命令シーケンスに変換する。この処理は、ほとんど機械的に行れ、この開示内容と、関連する専用プロセッサの命令セットの見地から、命令セットアーキテクチャの当業者には明白であろう（ただし、ＶＰＸ命令は標準であると想定されるが、ＩＧＵが実行する仮想化のために、タイルパス命令が固定である必要はない点に注意）。以下の議論では、この中心となるデコードタスクを取り巻く特定のタスクについて説明する。

前述したように、デコードステージは、機能停止しているか否かにかかわらず、テーブルシステムユニットへのインタフェースとして動作する（ステップ７０４）。そうでなければ、デコードステージは、Ｉ−バッファステージが、デコードした命令を受信する状態にある場合（例えば、ベクトル命令バッファに空き領域があり、機能停止していない場合）にのみ、動作する（ステップ７０６）。デコードステージは、属性ステージが新たな命令を供給しないようにさせ、デコードした命令のＩ−バッファステージへの流れを止めて、デコードステージ自身が機能停止状態に強制的に移行することができる。デコードステージが機能停止すると、後に述べる条件により、新たな命令を受け付けなくなり、代わりに前のデコードオペレーションを繰り返すか、継続する（ステップ７０８）。前のデコードが成功しなかった場合には、デコードが繰り返され、１つのＶＰＸが複数のタイルパス命令に変換された場合には継続する（ステップ７１０）。後者の例は、テーブルアクセスである。このテーブルアクセスは、アクセスが完了する前にテーブルアドレスをシフトしてマスクすることを要する。

図示した第１のオペレーションセットは、入力命令が、コンストラクトオペレーションか、又は、デストラクトオペレーションかを決定する。コンストラクト命令（ステップ７１２）は、レジスタベースの（共有されない）オブジェクトに対してのレジスタ割り当て（ステップ７１４）を必要とし、デストラクト命令（ステップ７１６の「いいえ」分岐）は、オブジェクトに関連する全てのレジスタの割り当てを解除する（ステップ７１８）。コピーコンストラクト（ステップ７１６）は、コピーされるオブジェクトの割り当てを残すが、新たなオブジェクトに対してレジスタを割り当て、ムーブオペレーションを発行して、タイルパス内のコピーされるオブジェクトの内容をコピーする（ステップ７２０）。レジスタ割り当ては、スピルを引き起こし得る。コンストラクト命令は、他の如何なるタイルパス命令も引き起こさないので、コンストラクトの場合には、デコーダが機能停止することなく当該スピルを発行する。コピーコンストラクトに対してスピルが発生すると、コピーは、スピルと、これに続くムーブによって実行されるため、２つの命令が生成されることになり、機能停止が必要となる（ステップ７２２）。割り当てられたレジスタは、オブジェクトトラッカによってアドレス指定されたオブジェクトレジスタテーブルに記憶される。

図８に示すように、他の命令は、必要に応じてレジスタを割り当てる。ほとんどの場合、これは単にオブジェクトレジスタテーブル内のレジスタ識別子を検索することを含むが、レジスタがスピルして再使用された場合、当該レジスタをフィルする必要があり、順に他のレジスタをスピルする必要が生じる場合がある。これは、デコードした命令が必要とするいくつか又は全てのレジスタで発生する場合がある。そのため、デコードした命令を続ける前に、全部で３つのスピルと３つのフィルが発生する場合があり、結果的に最大６サイクルの機能停止が起こり得る（結果が、一時的な結果ではなく、宣言された変数である場合には、結果がこれから書き込まれるにもかかわらず、割り当ての前にレジスタにフィルしなければならないことに注意する。なぜならば、オブジェクトには、より狭い幅のオブジェクトを割り当てることができ、狭い幅に関連する要素のみが影響を受けると定義されているからである）。しかしながら、スピルとフィルは非常に稀であるため、これは極端な場合である。このステージで行ったパスの数に関わらず、レジスタ割り当ては、結局、デコーダが進むことができる状態に到達することを示す具体例として、この場合を使った。ここでは、ハードウェアには少なくとも３つのレジスタが定義されていると仮定する。いくつかの命令は、複数のデコードした命令間で、中間状態のためのレジスタを必要とするが、この要求は、命令がさらにデコードされるまで分からないので、４番目のレジスタも仮定されている。

上述したように、デコーダの中心となるタスクは、ＶＰＸ命令をタイルパス命令に変換することである。このために、デコードステージは、オペレーションを行う前に、オペランドを互換性のあるデータタイプに変換する命令を発行することが必要となる場合があり、この結果、１サイクルの機能停止をもたらす。また、このために、テーブルシステムに対してアクセス要求を始める場合があり、依存関係情報及びアクセス識別子を、デコードした命令に加えることが必要となることがある。これらのオペレーションの概要をこれまでに見てきたが、詳細は本願の範囲を超える。しかし、本出願の開示内容に照らして、当業者は、これらのオペレーションが比較的簡単なマッピングであると理解できるだろう。

デコードステージの最後のタスクは、最適化キューを管理することである。このキューは、いくつかの命令のコンテキストを保持し、最適化できる可能性がある場合には、Ｉ−バッファステージからの命令を押さえておく。デコードステージは、最適化が行われた場合又は最適化が不可能だと分った場合、I‐バッファステージへ命令を伝える。

（Ｉ−バッファステージのオペレーションの詳細）
図９は、タイルプロセッサが専用プロセッサである場合におけるＩ−バッファステージのトップレベルでのオペレーションのフローチャートである。このステージは、機能停止状態に無い場合にのみ、新たな命令を最適化キューから取り込む（ステップ９０２，９０４）（そして、デコードステージが機能停止している場合には、新たな命令を受信しな可能性がある）。機能停止しているか否かにかかわらず、Ｉ−バッファステージは、上述したようにサイドバンド信号を常に提供し（ステップ９０６）、ベクトルＩ−パイプが異常に長い時間休止しているか否か、又は、バリア条件が満たされたか否かを検出する。

新たな命令を受信すると、第１のステップでは、ベクトル命令キューとスカラ命令キューの両方又は何れか一方に命令を配置する（ステップ９０８，９１０，９１２）（両方に配置するのは、スカラー値を生成するベクトル命令の場合である）。必要なキューのエントリが空でなければ、機能停止状態に陥る。Ｉ−バッファステージが入力命令を使用しなかったので、この状態は最後のステップで検出される（ステップ９１４，９１６）。

第２のステップは、入力命令とは無関係に、新たな命令を受信したか否かにかかわらず実行される。タイルアレイが以前のベクトル命令を受信し、ベクトル命令バッファに次の命令がある場合には、利用可能であれば、これを次に発行する命令として設定する。この命令の発行では、タイルパス領域にわたってマルチタスクが実行されるので、タスク間隔内の同じ命令シーケンスが領域毎に繰り返される。各タスク間隔が完了すると、（プログラムで定義される）最後の領域でタスク間隔が実行されるまで（ステップ９１８）、領域番号がインクリメントされる。この時点で、領域は第１の領域に設定され、命令の発行は次のタスク間隔に進む（ステップ９２０）。繰り返すが、これは命令がバッファに存在する場合にのみ適用される。

ベクトル命令の処理とは無関係に、Ｉ−バッファステージはスカラー命令も実行する。これらの命令には、１つ若しくは２つのスカラー値に対するオペレーションを行うこと、ベクトルオペレーション若しくはホストから受信したスカラー値をスカラーレジスタに設定すること、又は、スカラー値をホストへ返すこと、の何れかである。これらの全てのオペレーションは、スカラー命令キューの最初の命令に対して実行され、全てのオペランドが有効である場合にのみ実行される。ベクトル命令が生成したスカラーは、サイドバンドパケットで受信した結果として有効になり、適切なキューエントリに配置される。スカラーの実行がこのキューのエントリに達すると、その値はスカラーレジスタファイルに書き込まれ、その後の実行において利用可能になる。何らかの理由で、VectorSummaryオブジェクトの値が使われる前に同じオブジェクトに値が１回以上書き込まれると、スカラー命令キューは、この状態を認識し、最新の更新が有効になるまでスカラー値を使用しない。これは、特定のプログラム条件で起こり得る。

特定のシステム構成要素を参照するために、本開示を通じて、特定の用語が使用される。当業者が理解するように、実施者は、構成要素を異なる名称で呼ぶことがある。この文書では、機能ではなく名称が異なる構成要素を区別することを意図していない。以下の説明及び特許請求の範囲では、「含む」及び「備える」という用語は自由に使用され、これにより、「含むが、〜に限定されない」を意味すると解釈されるべきである。同様に、「接続する」という用語は、間接的又は直接的な電気的接続を意味することを意図している。このように、第１の装置が第２の装置に接続する場合、その接続は、直接的な電気的接続、又は、他の装置との接続を介した間接的な電気的接続である。

上記の説明は、本明細書で説明したシステム、プロセッサ及び方法の様々な実施形態に関する。開示された実施形態は、特許請求の範囲を含む本開示の範囲を限定するものとして解釈又は使用されるべきではない。さらに、当業者であれば、上記の説明が広範な用途を有し、如何なる実施形態の説明もその実施形態の単なる例示に過ぎないことを意味し、特許請求の範囲を含む本開示の範囲が実施形態に限定されることを示唆する意図がないことを理解するであろう。

本明細書で提供される説明は、本発明の原理及び様々な実施形態を例示することを意図している。上述の開示内容が十分に理解されると、当業者には多数の変形及び修正が明らかになるであろう。如何なる請求項も、かかる変形及び修正の全てを包含すると解釈するものとする。

Claims (13)

1. ホストコンピュータを専用プロセッサに接続するように構成された命令生成ユニットであって、
   ホストプログラムのオペレーションコードと、第１仮想ホストプログラムオペランドと、をホストコンピュータから受信し、第１仮想ホストプログラムオペランドに対応する第１オペランド記述子を識別するように構成された属性ステージであって、第１仮想ホストプログラムオペランドは、専用プロセッサの第１オペランドを表し、第１オペランド記述子は、１つ以上のオペランド属性に関して第１オペランドの記述を提供する、属性ステージと、
   第１オペランド記述子と、ホストプログラムのオペレーションコードと、を属性ステージから受信し、ホストプログラムのオペレーションコードと第１オペランド記述子とを用いて、専用プロセッサが実行するための１つ以上の変換された命令を形成し、変換された命令を専用プロセッサが実行するときに使用する記憶領域を割り当てるように構成されたデコードステージと、
   変換された命令をデコードステージから受信し、１つ以上の変換された命令を１つ以上の命令キューに配置し、専用プロセッサが実行するために、変換された命令を１つ以上の命令キューのうち少なくとも１つから発行するよう構成された命令バッファステージと、
   を備える、命令生成ユニット。
2. 専用プロセッサは、少なくとも２つの相互接続された処理ユニットのアレイを含み、
   各処理ユニットは、
   命令バッファと、
   少なくとも２つの領域に分割されたデータメモリと、を備える、
   請求項１の命令生成ユニット。
3. 第１オペランドは、専用プロセッサの１つ以上のデータメモリの複数の領域にわたって記憶された二次元データアレイを含む、
   請求項２の命令生成ユニット。
4. デコードステージによって割り当ててられた記憶領域は、専用プロセッサの処理ユニッ
   ト内に存在する、
   請求項２の命令生成ユニット。
5. 相互接続された処理ユニットの各々の命令バッファは、１つの処理ユニットから次の処理ユニットへ順次命令を伝えるように構成された命令パイプラインによって接続されており、
   １つ以上の命令キューは、ベクトル命令キューとスカラー命令キューとを備え、
   命令バッファステージは、変換された命令を１つ以上の命令キューから発行することに関連して、変換された命令をベクトル命令キューから命令パイプラインに配置するように構成されている、
   請求項２の命令生成ユニット。
6. 専用プロセッサ用の命令を生成する方法であって、
   ホストプログラムのオペレーションコードと、第１仮想ホストプログラムオペランドと、をホストプロセッサから受信することであって、第１仮想ホストプログラムオペランドは、専用プロセッサの第１オペランドを表す、ことと、
   第１仮想ホストプログラムオペランドに対応する第１オペランド記述子を識別することであって、第１オペランド記述子は、１つ以上のオペランド属性に関して第１オペランドの記述を提供する、ことと、
   ホストプログラムのオペレーションコードと第１オペランド記述子とを用いて、専用プロセッサが実行するための１つ以上の変換された命令を形成することと、
   変換された命令を実行するときに専用プロセッサによって使用される記憶領域を割り当てることと、
   １つ以上の変換された命令を１つ以上の命令キューに配置することと、
   変換された命令を、専用プロセッサが実行するために１つ以上の命令キューのうち少なくとも１つから発行することと、
   を含む、方法。
7. 専用プロセッサは、少なくとも２つの相互接続された処理ユニットのアレイを含み、
   各処理ユニットは、
   命令バッファと、
   少なくとも２つの領域に分割されたデータメモリと、を備える、
   請求項６の方法。
8. 第１オペランドは、専用プロセッサの１つ以上のデータメモリの複数の領域にわたって記憶された二次元データアレイを含む、
   請求項７の方法。
9. 記憶領域を割り当てることは、専用プロセッサの処理ユニット内に存在する記憶領域を割り当てることを含む、
   請求項７の方法。
10. 相互接続された処理ユニットの各々の命令バッファは、１つの処理ユニットから次の処理ユニットへ順次命令を伝えるように構成された命令パイプラインによって接続されており、
    １つ以上の命令キューは、ベクトル命令キューとスカラー命令キューとを備え、
    変換された命令を１つ以上の命令キューから発行することは、変換された命令をベクトル命令キューから命令パイプラインに配置することを含む、
    請求項７の方法。
11. コンパイルしたプログラムを実行するように構成されたホストプロセッサと、
    専用プロセッサと、
    ホストプロセッサ及び専用プロセッサと動作可能に接続された命令生成ユニットと、を備え、
    命令生成ユニットは、
    ホストプログラムのオペレーションコードと、仮想ホストプログラムオペランドとを、コンパイルしたプログラムから受信することであって、仮想ホストプログラムオペランドは、専用プロセッサのオペランドを表すことと、
    専用プロセッサが実行するために、ホストプログラムのオペレーションコードと仮想ホストプログラムオペランドとを用いて、１つ以上の変換された命令を形成することと、
    変換された命令を実行するときに専用プロセッサによって使用される記憶領域を割り当てることと、
    １つ以上の変換された命令を１つ以上の命令キューに配置することと、
    変換された命令を、専用プロセッサが実行するために１つ以上の命令キューのうち少なくと１つから発行することと、を実行するように構成されている、
    データ処理システム。
12. 専用プロセッサは、少なくとも２つの相互接続された処理ユニットのアレイを備え、
    各処理ユニットは、
    命令バッファと、
    少なくとも２つの領域に分割されたデータメモリと、を備える、
    請求項１１のデータ処理システム。
13. 相互接続された処理ユニットの各々の命令バッファは、１つの処理ユニットから次の処理ユニットへ順次命令を伝えるように構成された命令パイプラインによって接続されており、
    １つ以上の命令キューは、ベクトル命令キューとスカラー命令キューとを備え、
    命令生成ユニットは、変換された命令を１つ以上の命令キューから発行することに関連して、変換された命令をベクトル命令キューから命令パイプラインに配置するように構成されている、
    請求項１２のデータ処理システム。

Images