問題タブ [vliw]

GCCコンパイラインフラストラクチャにVLIWアーキテクチャのサポートがどれほど強力であるか知っていますか？GCCでサポートされているVLIWアーキテクチャがいくつかあることを私は知っています。それらを見ると、パイプラインの最適化は別の最適化レイヤーに任されているようです。これに関する良い（GCC内部ドキュメントではない）資料はありますか？

以下の機能を提供する組み込みプロセッサ アーキテクチャの評価に取り組んでいます。

• 8 つの SIMD コプロセッシング DSP 種類のコア、
• 各コアは 8 ウェイ SIMD を実行できます
• 各コアも 8 実行スロット VLIW です。

このプロセッサー/ハードウェアで実行するために、高ビデオ エンコーダー (H.264、1080p、60fps) または 3D ビデオ エンコーダーを使用したいと考えています。私は建築調査を実行して見つけようとしています

• マルチメディア（ビデオ/画像）信号処理アプリケーションを電力/サイクル/メモリ効率の良い方法で実行するのに役立つプロセッサの優れた機能は何ですか。

• 周辺機器、メモリ構造、キャッシュ メモリまたは内部メモリのいずれか。追加のアセンブリ命令は、マルチメディア アプリケーションのコードの効率的な実行に役立ちます。

• マルチメディア (ビデオ/画像) 処理アプリケーション向けの最も電力効率が高く高速なプロセッサ アーキテクチャは何ですか?

PS: ポータブル アプリケーションのため、低電力である必要があります。

ポインタ（論文/ブログ）は役に立ちます。

ありがとうございました。

-広告。

VLIWアーキテクチャ (またはItanium のようなEPIC ) の強力なサポートが LLVM コンパイラ インフラストラクチャに存在することをご存知ですか?

これに関する適切なドキュメント/スライド資料はありますか?

ILPに関する質問をしたいと思います。

• スーパースカラープロセッサは、スカラープロセッサとベクトルプロセッサを組み合わせたものです。では、ベクトルプロセッサのアーキテクチャはスーパースカラーに従っていると言えますか？

• 複数の命令を同時に処理しても、パイプライン、マルチプロセッサ、またはマルチコアアーキテクチャでも実現されるため、アーキテクチャはスーパースカラーにはなりません。これはどういう意味ですか？

• 私は読んだことがあります'スーパースカラーCPUアーキテクチャは、単一のプロセッサ内で命令レベルの並列性と呼ばれる並列処理の形式を実装します'、スーパースカラーは複数のプロセッサを使用できませんか？スーパースカラーが使用されている例を誰かに教えてもらえますか？

• VLIW、私はこの記事を読みました。9ページの図4があります。これは、複雑なリオーダーバッファとデコードおよびディスパッチロジックを含まない一般的なVLIW実装を示しています。デコードしないという用語は私を混乱させます。

よろしく、anas anjaria

発行幅がNに等しいVLIW プロセッサを考えてみましょう。これは、 N 個の操作を同時に開始できることを意味します。したがって、非常に長い各命令は、最大N 個の操作で構成できます。

VLIW プロセッサが、さまざまな待ち時間の操作で構成される非常に長い命令をロードするとします。同じ非常に長い命令に属する操作は、異なる時点で終了する可能性があります。同じ非常に長い命令に属する他の操作の前に操作が実行を終了するとどうなりますか? 後続の操作 (つまり、次の非常に長い命令に属する操作) は、現在の非常に長い命令の残りの操作が実行される前に実行を開始できますか? または、非常に長い命令は、現在の非常に長い命令に属するすべての操作の完了を待機しますか?

HD5850 を持っていませんが、opencl の最大ワークグループ サイズを知るにはどうすればよいですか? HD5850 で推奨される浮動小数点ベクトル幅は? 私はそれが 5 だと思ったが、5850 を持っている友人のコンピュータでは動かなかった。25k 50k および 100k パーティクルの NBody の実行は、x、y、z、vx、vy、vz の float8 変数で構成されます。

ありがとう。

I understand the need for re-order buffer in speculative execution. However, given a sequence of non-speculative instructions without any branches, why is it that all these instructions still have to go through the ROB and then commit in order? Since there is no control hazard and assuming the presence of register renaming to avoid WAR and WAW hazards, is ROB a necessity in such a case?

One reason I could think of, is for handling imprecise exceptions. Is there any other reason?

OpenCL プログラミングについて質問したいことがあります。ウェーブフロントの 4 分の 1 が各サイクル クロックに対して命令を発行でき、ウェーブフロントを呼び出すには 4 サイクル クロックが必要であることを理解しています。VLIW アーキテクチャで命令を完了するには、8 サイクル クロックが必要です。したがって、別の波面を呼び出すことが解決策です。2 つの波面を呼び出すと、8 サイクル クロックになります。したがって、ウェーブフロント A が実行された後 (4 サイクル クロック)、ウェーブフロント B が実行されます (別の 4 サイクル クロック)。ウェーブフロント B が実行された後 (合計サイクル クロックは 8)、ウェーブフロント A は別の命令で再度実行されます。

質問は：

処理要素ごとに 4 つの ALU が別の命令を実行するために既に使用されている場合、どのように ALU は別の命令を実行しますか??

例: サイクル 1 で、作業項目 0 ～ 15 が命令「ADD」の実行を開始します。各プロセッシング エレメントの最初の ALU (SIMD/計算ユニットの合計 16 PE) は、「ADD」命令を計算します。
これは、ウェーブフロントのサイクル 2、3、および 4 で発生します (各 PE には、「ADD」命令を実行するためにビジー状態を維持する 4 つの ALU があります)。サイクル 5 では、ウェーブフロント 2 の 4 分の 1 が命令「SUBTRACT」の実行を開始します。最初のウェーブフロントから「ADD」命令を計算するためにビジーであるため、処理要素の ALU はどのように命令を計算するか (8 サイクル クロックかかるため、最初のサイクルのウェーブフロントの 4 分の 1 に対する命令「ADD」の実行は未完了であることを思い出してください)??

更新: 8 サイクル クロックは、書き込み後の読み取りのレイテンシを意味します。

現在、スーパースカラー RISC CPU は通常、分岐予測と投機的実行によるアウトオブオーダー実行をサポートしています。彼らは仕事を動的にスケジュールします。

アウトオブオーダー CPU の動的スケジューリングと比較して、コンパイラ命令スケジューリングの利点は何ですか? コンパイル時の静的スケジューリングは、順不同の CPU の場合、または単純な順序の CPU の場合にのみ問題になりますか?

現在、ほとんどのソフトウェア命令スケジューリング作業は、VLIW または単純な CPU に焦点を当てているようです。GCC wiki のスケジューリング ページも、gcc のスケジューリング アルゴリズムの更新にあまり関心を示していません。

命令レベルの並列処理で使用される方法と、それらの違いについて学習しようとしています。ここでの私の質問は、最初は命令レベルの並列処理なしでプロセッサで実行するように作成された命令セットを考えると、新しいプロセッサで命令レベルの並列処理を実現するためにこれらの方法のどれを使用できるか、およびその理由と方法です。新しいプロセッサは、元のプロセッサと同じ命令セットを実行し、同じプログラム バイナリを実行しますが、パフォーマンスは向上します。オプションは次のとおりです。

1)アウトオブオーダー実行(トマスロアルゴリズム)

2)パイプライン

3)スーパースカラー

4)VLIW