YAMAGUTIseisei wrote:
> Google 翻訳
> 
> これは、ファイル http://microsoft.com/en-us/research/wp-content/uploads/2016/02/e2-heart2010.pdf
> の html版です。 Googleはウェブをクロールする際に自動的にドキュメントのHTMLバージョンを生成します。
> 
> 
> Page 1 
> 
> E2ダイナミックマルチコアアーキテクチャにおける動的ベクトル化
> 2010 HEART 2010の議事に出席する
> 
> アンドリュー・パトナム
> マイクロソフトリサーチ
> anputnamATmicrosoft。
> 
> アーロン・スミス
> マイクロソフトリサーチ
> aasmithATmicrosoft。
> 
> ダグ・バーガー
> マイクロソフトリサーチ
> dburgerATmicrosoft。
> 
> ABSTRACT抽象
> これまでの研究では、明示的データグラフ実行（EDGE）命令セットアーキテクチャ（ISA）が電力効率の良い性能スケーリングを可能にすることが示されています。
> 本稿では、物理コアを論理プロセッサに動的に合成するために、EDGE ISAを使用するE2という新しい動的マルチコアプロセッサの初期設計について説明します。
> 動的再構成可能性に対するE2のサポートの詳細を提供し、EDGE ISAがアウトオブオーダーのベクトル実行をどのように備えているかを示します。
> 
> カテゴリと主題記述子
> C.1.2 [コンピュータシステムの組織]：
> 複数のデータストリームアーキテクチャ -- 単一命令ストリーム、複数データストリームプロセッサ（SIMD）、アレイプロセッサおよびベクトルプロセッサ、
> C.1.3 [コンピュータシステムの組織]：
> その他のアーキテクチャスタイル -- 適応可能なアーキテクチャ、データフローアーキテクチャ
> 
> 一般条件 デザイン、パフォーマンス
> 
> キーワード 明示的データグラフ実行（EDGE）
> 
> 1. 前書き
> 　チップ設計者は、性能のために電力をトレードオフするために、動的電圧と周波数スケーリング（DVFS）に長く依存してきました。
> しかし、Vminでの周波数スケーリングが電力と性能の両方を直線的に低下させ、エネルギーの削減を達成しないため、プロセッサが最小スレッショルド電圧（Vmin）に近づくにつれて、電圧スケーリングはもはや機能しません。
> 電力と性能のトレードオフは、マイクロアーキテクチャまたはシステムソフトウェアのいずれかに委ねられます。
> 　DVFSがほとんどないアーキテクチャを設計する場合、設計者はシリコンリソースの使用方法を選択する必要があります。
> HillとMarty [6]は、デザイナーがこれらのリソースを使用できる4つの方法を説明しました。
> (1) 多くの小型、低性能、電力効率の高いコア、 (2) ,大規模で電力効率の低い高性能コアはほとんどありませんが、
> (3) 小コアと大コアの異種混在、 and (4) コアを結合または分割して所定のワークロードに適合させることができる動的アーキテクチャ。
> これらの代替案の中でも、最高のパフォーマンスとエネルギー効率の高い設計は、ダイナミックなアーキテクチャです。
> Hill氏とMarty氏は、このようなダイナミックプロセッサーは何ができるのかを特徴づけたが、そのようなアーキテクチャーの詳細は記述しなかった。
> 　TFlex [9]は、
> 明示的データグラフ実行（EDGE）命令セットアーキテクチャ（ISA）を使用することにより、電力効率が高く軽量のプロセッサコアをより大きくより強力なコアに組み合わせることによって、
> 大きなダイナミックレンジと性能を実証したアーキテクチャの1つです
> TFlexは、小さなエンベデッドプロセッサと同じ性能とエネルギー効率を提供するために、またはシングルスレッドアプリケーションでアウトオブオーダーのスーパースカラの高性能を提供するように動的に構成可能です。
> 　これらの有望な結果に動機づけられ、我々は現在、高性能な電力を効率的に達成するためにEDGE ISAを使用するE2という新しい動的アーキテクチャを設計している[3]。
> EDGEモデルは、プログラムをアトミックに実行する命令のブロックに分割します。
> ブロックは、従来のISAで行われたようにレジスタを介して通信するのではなく、プロデューサ - コンシューマ命令間の関係を明示的に符号化する一連のデータフロー命令からなる。
> これらの明示的な符号化は、各命令のオペランドをプライベート・リザベーション・ステーション（オペランド・バッファと呼ばれる）にルーティングするために使用されます。
> レジスタおよびメモリは、あまり頻繁でないブロック間通信を処理するためにのみ使用されます。
> 　以前の動的アーキテクチャ[7,9]は、タスクとスレッドレベルの並列性を利用する能力を実証しましたが、データレベルの並列性を扱うには、データを独立したセットに分割し、スレッドレベルの並列性を使用する必要があります。
> このホワイトペーパーでは、スレッディングがなくてもデータレベルの並列処理を効率的に活用することに焦点を当て、E2の予備ベクタユニット設計について説明します。
> 以前のイン・オーダー・ベクトル・マシンとは異なり、E2では、ベクトルとスカラーの両方のアウト・オブ・オーダー実行が可能です。
> 　E2命令セットと実行モデルは、幅広いコードにわたって効率的なベクトル化を可能にする3つの新しい機能をサポートしています。
> 第1に、静的にプログラムされた問題ウィンドウをベクトルレーンにスライスすることにより、スケーラモードよりも低いエネルギーオーバーヘッドで高度に並行したアウトオブオーダーの混合スカラーおよびベクトル演算の問題を達成することができます。
> 第2に、静的に割り当てられた予約ステーションは、発行ウィンドウをベクトルレジスタファイルとして扱うことを可能にし、ワイドフェッチをメモリに、ベクトルロードとベクトル演算との間のコピーを制限する。
> 第3に、E2のアトミックブロックベースモデルは、リザベーションステーションにマップされたベクトル（およびスカラー）命令ブロックのリフレッシュを可能にし、最初のループ反復の後にフェッチまたはデコードエネルギーオーバヘッドなしで発行する反復ベクトル演算を可能にする。
> まとめると、これらの最適化は、幅広いコードにわたって多くのサイズのベクトルを見つけて実行することに関連するエネルギーを削減します。
> 
> 
> ページ2
> 
> ALU
> 命令ウィンドウ 32×54b
> ALU
> 命令ウィンドウ 32×54b
> ALU
> 命令ウィンドウ 32 x 54b
> ALU
> 命令ウィンドウ 32×54b
> L1命令キャッシュ32 KB
> L1データキャッシュ32 KB
> コントロール
> 分岐予測器
> レジスタ[0-15] 16 x 64b
> レジスタ[16-31] 16 x 64b
> レジスタ[32-47] 16 x 64b
> レジスタ[48-63] 16 x 64b
> メモリインタフェースコントローラ
> ロード/ストア・キュー
> オペランド・バッファ 32×64b
> オペランド・バッファ 32×64b
> オペランド・バッファ 32×64b
> オペランド・バッファ 32×64b
> オペランド・バッファ 32×64b
> オペランド・バッファ 32×64b
> オペランド・バッファ 32×64b
> オペランド・バッファ 32×64b
> レーン1 レーン2 レーン3 レーン4
> コア コア コア コア コア コア コア コア    コア コア コア コア コア コア コア コア         L2 L2 L2 L2
> コア コア コア コア コア コア コア コア    コア コア コア コア コア コア コア コア         L2 L2 L2 L2
> 
> 図1： E2マイクロアーキテクチャブロック図
> ベクタモードでは、各コアは4つの独立したベクタレーンで構成され、それぞれが32命令ウィンドウ、2つの64ビットオペランドバッファ、整数および浮動小数点演算のALU、16レジスタを備えています。
> スカラーモードでは、レーン3および4のALUはパワーダウンされ、命令ウィンドウ、オペランドバッファおよびレジスタは他の2つのレーンで使用可能になります。
> 
> 2. E2アーキテクチャ
> 　E2は、オンチップネットワークで接続された低電力、高性能、分散処理コアで構成されたタイル型アーキテクチャです。
> この設計により、E2には他のタイル型アーキテクチャ、つまりシンプルさ、スケーラビリティ、フォールトトレランスのメリットがもたらされます。
> 図1は、32コアを含むE2プロセッサの基本アーキテクチャと、1つの物理コアの内部構造のブロック図を示しています。
> 　コアにはNレーンが含まれています（このペーパーでは4つ選択します）。各レーンは64ビットALUと命令ウィンドウ、オペランドバッファ、レジスタファイルの1つのバンクで構成されています。
> ALUは、整数および浮動小数点演算、およびファイングレインSIMD実行（サイクルごとに8つの8ビット、4つの16ビット、または2つの32ビット整数演算、または1サイクルあたり2つの単精度浮動小数点演算）をサポートします。
> ウィンドウをレーンに分割するこの革新により、ハードウェアの複雑さはほとんどなく高いベクトルスループットが可能になります。
> 　E2のEDGE ISAは、ブロックを実行サブシステムにマップするハードウェアを簡略化し、ブロックの実行が完了したことを検出するために、ブロックをいくつかの方法で制限します。
> ブロックは可変サイズであり、4から128の命令を含み、多くとも32のロードおよびストアを実行することができる。
> ハードウェアは、プログラムをデータフロー命令のブロックに分割し、シーケンシャルメモリセマンティクス[12]を実行するためのロードおよびストア識別子を割り当てるために、コンパイラに依存しています。
> パフォーマンスを向上させるために、コンパイラは、述語を使用して、有用な命令で満たされた大きなブロックを形成します。
> コミットを単純化するために、アーキテクチャはコンパイラに依存して、すべてのブロックから単一の分岐が生成され、レジスタの書き込みと使用されるストア識別子のセットをエンコードします。
> 　E2コアは、スカラーモードとベクトルモードの2つの実行モードで動作します。
> ? ry 他の命令にオペランドを送信でき、 ry ALUのうち2つを除くすべての命令がオフ ry 。
> スカラーモードでは、どの命令もブロック内の他の回路にオペランドを送信でき、電力を節約するためにALUのうち2つを除くすべてがオフになります。
> ? ry 、命令は同じベクタレーンの命令にオペランドのみを送信できます。
>     ベクタモードでは、すべてのN個のALUはオンになっていますが、回路は同じベクタレーンの回路にのみオペランドを送信できます。
> モードは、ブロックヘッダのビットからブロックごとに決定されます。
> これにより、各コアは、ブロックごとに異なるアプリケーションフェーズに迅速に適応することができます。
> 2.1 コアの作成
> ? ry 、コアを構成して分解することによって、 ry 。
> 　E2と他のプロセッサを区別する重要な特性の1つは、コアの構成と分解によって、特定の作業負荷に対してアーキテクチャを動的に適応させることです。
> 設計時にコアのサイズと数を固定するのではなく、実行時に1つ以上の物理コアを結合して、より大きな、より強力な論理コアを形成することができます。
> たとえば、すべての物理コアを積極的なスーパースカラのように機能する1つの大きな論理プロセッサにまとめることで、ワークロードのシリアル部分を処理できます。
> また、十分なスレッドレベルの並列処理が可能な場合、同じ大きな論理プロセッサを分割して、各物理プロセッサが独立して動作し、独立したスレッドから命令ブロックを実行することができます。
> ? コアをまとめてコアを合成し、分割するコアを分解コアと呼びます。
> コアをマージしまとめる事をコア合成 ( 融合 構成 形成 ) と、コアを分割する事をコア分解 ( 分割 分離 ) と呼びます。
> 　論理コアは、物理コア間のレジスタおよびメモリへのアクセスをインターリーブして、論理コアに、合成されたすべての物理コアの結合された計算リソースを与えます。
> たとえば、2つの物理コアで構成される論理コアは、アドレスの追加ビットを使用して2つの物理キャッシュ間で選択し、L1キャッシュ容量を効果的に2倍にします。
> ? 、追加のレジスタファイル容量に電力が供給され、 ry 。
> レジスタファイルも同様にインターリーブされますが、64個のレジスタだけがISAによってサポートされているため、追加のレジスタファイル分の電源は遮断され、消費電力が削減されます。
> 　各命令ブロックは、単一の物理プロセッサにマッピングされます。
> 
> 
> Page 3
> 
> 構成時に、アーキテクチャは投機的命令ブロックを実行するために追加のコアを使用します。
> ? 非推測ブロック非投機ブロックがコミットすると、 ry 。
> 非投機ブロックがコミットすると、コミット信号が出口分岐アドレスと共に論理プロセッサ内の他のすべてのコアに送信されます。
> 正しいパス上の投機的ブロックは実行を継続し、非取得パス上のブロックは押しつぶされる。
> このプロセスの詳細については、2.2.1項で詳しく説明します。
> 　コア構成は、構成を変更するオーバーヘッドが、より効率的な構成のパフォーマンス向上によって上回る場合にのみ実行されます。
> 合成は常にブロック境界で行われ、ランタイムシステムによって開始されます。
> 構成が有益なシナリオの数を増やすために、E2はコアを構成する2つの異なる方法を提供し、それぞれがオーバーヘッドと効率のトレードオフを提供します。
> 　フルコンポジションは、論理コア内の物理コアの数を変更し、レジスタファイルとキャッシュのマッピングを変更します。
> ダーティなキャッシュ・ラインは、遅延してメイン・メモリに書き込まれます。
> 論理レジスタとキャッシュの位置は、物理コア全体に均等に分散されます。
> ? ry 、より大きな論理キャッシュ（すべての物理コアのキャッシュ容量の合計）につながります。
> キャッシュラインは、単純なハッシュ関数を介してマッピングされ、より大きな論理キャッシュ（すべての物理コアのキャッシュ容量の合計）になります。
> 　クイックコンポジションは、追加のコアを論理プロセッサに追加しますが、同じL1データキャッシュとレジスタのマッピングを保持し、ダーティキャッシュラインをメインメモリに書き出しません。
> ? ry 可能なよりも小さな ry 。
> これにより、論理プロセッサは完全なコンポジションで可能な大きさよりも小さなデータキャッシュになりますが、作成した後もキャッシュに既に存在するデータへのアクセスが確実に行われます。
> ? ry 、実行ユニットを追加すると有効ですが、キャッシュを再構成するオーバーヘッドがより大きい、より効率的なキャッシュ構成の節約よりも大きい場合に、短期間のアクティビティバーストに最も役立ちます。
> クイックコンポジションは、実行ユニット追加が優位になる短期間バーストアクティビティに最も役立ちますが、
> キャッシュを再構成するオーバーヘッドの節約が、より効率的キャッシュ構成時を上回る場合にです。
> ? 　電力を節約するように電力を供給します。
> 　分解は、論理プロセッサから物理コアを削除し、除去されたコアへの電力供給は電力を節約する形で行われます。
> 実行は残りの物理コアで継続されます。
> 分解するには、論理プロセッサから落とされる各キャッシュのダーティラインをフラッシュし、キャッシュマッピングを更新する必要があります。
> ? ry が追い出されたときにのみ書き戻されます。
> 残りのコアのダーティー・キャッシュ・ラインは、キャッシュ・ラインが追出される時点でライトバックされます。
> 2.2 投機
> ?　スペキュレーションは、 ry 。
> 　投機は、シリアルワークロードで優れたパフォーマンスを達成するために不可欠な要素であることは長い間認識されています。
> E2は、パフォーマンスを向上させるために推測を積極的に使用します。
> 結合述語分岐予測子[5]は、2つのレベルで推測する。
> まず、ブロック間の推測のために各ブロックの分岐出口アドレスを予測します。
> 第2に、述語値を予測することによって、ブロック内の制御フロー経路を予測する。
> 2.2.1 ブロック間の推測
> 　分岐出口アドレスを予測することにより、現在のブロックが完了する前に命令ブロックをフェッチして実行を開始することができます。
> ? ry 、非推論としてマークされ、 ry 。
> 最も古い命令ブロックは、非投機としてマークされ、分岐出口アドレスを予測する。
> このアドレスはフェッチされ、命令ウィンドウ内に使用可能なスペースがある場合、論理プロセッサ内の別の物理コアまたは同じ物理コア上で実行を開始します。
> 　実行された分岐アドレスは、ブロックが完了する前に解決されることがよくあります。
> ? ry 、取られたアドレスを ry 。
> この場合、非投機ブロックは、得られたアドレスを論理プロセッサ内の他のコアに通知する。
> 
> 最も古い命令ブロックは、非投機的ブロックになる。
> 正しく推測されなかったブロックは押しつぶされます。
> ? ry 取られた分岐信号 ry 。
> この得られた分岐信号は、コミット信号とは異なる。
>     The taken branch allows the next block to continue speculation and begin fetching new instruction blocks.
>?  取られたブランチは、 ry 推測を続行し、 ry 。
>得られたブランチは、次のブロックが投機を続行し、新しい命令ブロックのフェッチを開始することを可能にする。
> しかし、レジスタ値とメモリ値は、コミット信号の後まで有効ではありません。
> 
> コンポーネント    パラメータ   領域（mm2） ％領域
> 
>命令ウィンドウ             32x54b          0.08            2％
>分岐予測器                               0.12            3％
>オペランドバッファ   32x64b          0.19            5％
>ALU 4 SIMD、Int + FP         0.77            20％
>レジスタファイル    64 x 64b        0.08            2％
>ロード・ストア・キュー                 0.19            5％
>L1 Iキャッシュ           32kB            1.08            28％
>L1 Dキャッシュ           32kB            1.08            28％
>コントロール                              0.19            5％
> 
>コア                                  3.87            100％
> 
>L2キャッシュ             4MB             100
> 
> 表1： E2コアのコンポーネント、設計パラメータ、および領域
> 
> ? ブロック内の推測
> 2.2.2 Blockブロック内での投機
> 　命令ブロック内には3つのタイプの投機がある。
> 述語推測は、述語の値を予測するために結合述語分岐予測子を使用する。
> ? 投機的ブロックが投機的ブロックによって変更される可能性のあるL1キャッシュから ry 。
> 軽投機的なブロックが投機的ブロックによって変更される可能性のあるL1キャッシュから値をロードするとき、投機的ブロック内でメモリ投機が発生する。
> ? ry ロード・スペキュレーションが発生します。
> ロード・ストア・キュー（LSQ）によって、ロード・ストア識別子の低いストアが実行される前にロードを実行できるようになると、ロード投機が発生します。
> ? ry 、誤った推測は、 ry 。
> 　3つすべての場合において、誤った投機は、命令ブロック全体の再実行を必要とする。
> これは比較的軽量であり、すべてのオペランドバッファ内の有効ビットを無効にし、ゼロオペランド命令を再ロードするだけでよい。
> ? 2.3 ry と頻度
> 2.3 面積と周波数
> 　ChipEstimate InCyte [4]と業界平均の65nmプロセステクノロジライブラリを使用して、E2プロセッサのエリアモデルを開発しました。
> 設計パラメータとコンポーネント領域を表1に示します。
> 各E2コアにはL1キャッシュを含む3.87 mm2が必要です。
> ? 　InCyteのバージョンでは、頻度 ry 。
> 　InCyteの我々のバージョンでは、周波数の見積りは利用できません。
> しかし、マイクロアーキテクチャは、大規模でグローバルな構造を持たず、チップ全体にわたる分散制御を使用します。
> このため、E2は65nmで600?1000MHzの標準ARMマルチコアプロセッサ設計と同等の周波数を達成することが期待されています[2]。
> 
> 3. 実行パイプライン
> 　E2の実行は、命令フェッチ、実行、コミットの3つの主要段階に分かれています。
> このセクションでは、最初にスカラーモードで動作するときの各ステージの動作について説明し、次にスカラーモードとベクトルモードの違いについて説明します。
> 3.1 フェッチ
> 　E2と従来のアーキテクチャとの主な違いの1つは、E2が単一命令を連続的にフェッチするのではなく、一度に多くの命令をフェッチすることです。
> 
> 
> Page 4 
> 
> ? 命令最大128命令のブロック ry 一度にフェッチ ry 。
> 総合計128以内の命令を持つブロックがL1命令キャッシュから一度にフェッチされ、命令ウィンドウにロードされます。
> 命令は、ブロックコミット（または、セクション3.3.1で説明されているように、おそらく長くなる）まで、ウィンドウに常駐しています。
> 　物理コアは、同時に1つの128命令ブロック、2つの64命令ブロック、または4つの32命令ブロックをウィンドウ内でサポートします。
> 命令ブロックは、ブロック内の命令数、特殊ブロック動作用のフラグ、およびブロックによって書き込まれたグローバルレジスタを符号化するビットベクトルおよび使用されるストア識別子を含む128ビットブロックヘッダから始まる。
> 命令は32ビット幅であり、一般に少なくとも4つのフィールドを含む：
> 
>  ? ry 数とともに実行する命令。
>  * オペコード[9ビット]： 受け取る入力オペランドの数付きで実行する命令。
>  * 述語[2ビット]： 命令が述語ビットで待機する必要があるかどうか、およびそのビットがtrueまたはfalseの場合に実行するかどうかを示します。
>  * ターゲット1 [9ビット]： 命令の結果のコンシューマの識別子。コンシューマがレジスタの場合、このフィールドはレジスタ番号です。コンシューマが別の命令である場合、このフィールドにはコンシューマの命令番号（オペランドバッファへのインデックスとして使用される）と、結果がオペランド0、オペランド1、または述語として使用されるかどうかが含まれます。
>  ? ry 即時[9ビット]： ry 即時命令 ry 。
>  * ターゲット2 /即値[9ビット]： 2番目の命令ターゲット、または即値命令の定数値のいずれか。
> 
> 　命令ウィンドウは4つの等しいバンクに分割され、各バンクは1サイクルにつき2つの命令をロードする。
> 定数生成命令などの入力オペランドを必要としない命令は、命令番号をレディキューにプッシュすることによって直ちに実行するようにスケジューリングされる。
> 3.2 実行する
> 　実行は、レディキューからレディ命令番号を読み取ることによって開始される。
> オペランド、オペコード、および命令ターゲットフィールドは、ALU、レジスタファイル（読み出し命令用）、またはロードストアキュー（ロードおよびストア用）のいずれかに転送されます。
> ターゲットフィールドは、結果が（もしあれば）適切なオペランドバッファ（または書き込みの場合はレジスタファイル）に戻すために使用されます。
> ? 結果がオペランドバッファに転送されると、 ry 。
> 　結果がオペランドバッファに戻されると、ターゲットとなる命令がチェックされ、どの入力が必要であり、どのオペランドが既に到着しているかがわかります。
> 命令のすべてのオペランドが到着した場合、命令番号がレディキューに追加されます。
> ブロックが完了するまで、このデータ駆動方式で実行が継続されます。
> 　他のEDGEやデータ・フロー・アーキテクチャーと同様に、メモリー操作が命令型言語プログラムのプログラム順序のセマンティクスに確実に従うように、ロードとストアに特別な処理が必要です。
> ? ry 使用します。 ry 。
> E2は[10]で説明した方法を使用し、コンパイラはシーケンシャルメモリセマンティクスを実施するためにマイクロアーキテクチャが使用するプログラム順序を示すシーケンス識別子で各メモリ操作をエンコードします。
> ? プレディケートのためにブロック内のすべての命令が ry 。
> 予測のためにブロック内のすべての命令が必ず実行されるわけではないため、マイクロアーキテクチャはブロックの完了を検出する必要があります。
> ? ry （1）唯一の分岐 ry 。
> ブロックは、（1）一つ ( 又唯一 ) の分岐が実行されたとき、および（2）外部状態を変更するすべての命令（レジスタ書き込みおよびストア）が実行されたときに完了したとみなされる。
> ? ry criteria（2）が満たされた ry 。
> コンパイラはレジスタの書き込みとストア識別子を命令ブロックヘッダにエンコードし、マイクロアーキテクチャが上記（2）の判定が満たされたときを識別できるようにします。
> 3.3 コミット
> 　実行中、命令はアーキテクチャ状態を変更しません。
> 代わりに、すべての変更がバッファリングされ、ブロック完了時に一緒にコミットされます。
> ? ry 最も低いシーケンス識別子 ry 。
> コアがコミット・フェーズに入ると、レジスタ・ファイルはすべてのレジスタ書き込みで更新され、ロード・ストア・キュー内のすべてのストアは、最小のシーケンス識別子で始まるL1キャッシュに送信されます。
> すべてのレジスタ書き込みおよびストアがコミットされると、コアは同じ論理プロセッサ内の他のすべてのコアにコミット信号を送信します。
> 3.3.1 リフレッシュ
> 　リフレッシュと呼ばれる重要なコミット最適化の1つは、命令ブロックが自身に分岐するときに発生します。
> 命令をL1命令キャッシュから再びロードするのではなく、命令をそのまま残し、オペランド・バッファおよびロード・ストア・キュー内の有効ビットのみをクリアする。
> これにより、命令フェッチフェーズを完全にバイパスすることができます。
> ?  ry 実行されるたびに再生成されないようにする ry 。
> 定数を生成する命令は、オペランドバッファの値をリフレッシュ後も有効なままにしておき、命令ブロックが実行されるたびに再生成される事がないようにすることもできます。
> 
>要素サイズ       最小値（1 ALU）              最大値（4 ALU）
> 
>8ビット        8                       32
>16ビット       4                       16
> 32ビット      2（1つのシングルfp）    8（4つのシングルfp）
>64ビット       1                       4
> 
> 表2： サポートされているベクトル演算
> 
> 3.4 ベクトルモード
> 　ベクトルモードの実行は、各プロセッサコアをN個（このペーパーでは4つ）の独立したベクトルレーンに分割します。
> ベクタ・モードで動作する場合、命令は同じベクタ・レーン内の他の命令のみをターゲットにすることができ、オペランド・バッファとALU間にフル・クロス・バーを必要としません。
> 各レーンは、32エントリ命令ウィンドウ、2つの64ビットオペランドバッファ、16レジスタ、および1つのALUで構成されています。
> 　E2は、64ビット、128ビット（256ビットにパディングされた）、および256ビット幅のベクトルに対するベクトル演算をサポートしています。
> 各ALUは、8つの8ビット、4つの16ビット、または2つの32ビット・ベクタ・オペレーションをサポートします。
> ? ry 1コアあたり最大32 ry 。
> 4つのALUにより、E2は1コア1サイクルあたり最大32のベクトル演算をサポートできます。
> 64ビット・ベクタ・オペレーションは単一のALUを使用し、128ビット・オペレーションと256ビット・ベクタ・オペレーションは4つのALUすべてを使用します。
> 表2に、各ベクトル長とデータ要素サイズでサポートされる並列ベクトル演算の数を示します。
> 　ベクトル命令を含む命令ブロックは、各ベクトルレーンの命令ウィンドウのサイズである32命令に制限される。
> レーン1で発行されるベクトル命令は、他の3つのレーンで自動的に発行され、スカラー命令は常にレーン1に割り当てられます。
> ?　 ry 形成するために別名が付けられます。
> 　ベクタモードでは、64個の64ビット物理レジスタ（R0^ZR63）に16個の256ビットベクタレジスタ（V0^ZV15）を形成するためにエイリアスされます。
> 物理レジスタファイルを4つのバンクに分割して、ベクトルの単一サイクルアクセスをサポートします。
> ? 3.4.ベクトル ry
> 3.4.1 ベクトルモードでのメモリアクセス
> 　E2コアは、256ビットのチャンクで動作し、中小長のベクトルでデータレベルの並列処理を効率的に利用できます。
> ? より大きなベクトルでの操作は、効率的なリフレッシュモードを使用して命令フェッチと定数の生成（セクション3.3）をバイパスするループ内の複数の命令ブロックを使用して実行されます。
> ループ内の複数の命令ブロックでのより大きなベクトル操作に於ては、効率的なリフレッシュモードを使用する事で命令フェッチと定数の生成がバイパスされます（セクション3.3）。
> 
> 
> Page 5 
> 
> 　複数の命令ブロック間で大きなベクトルを分割すると、同じベクトルの隣接するチャンクのロード間に遅延が発生する可能性があります。これらのロードは複数の命令ブロックに分割されるためです。
> この遅延を軽減するために、E2はメモリインタフェースコントローラ（MIC）と呼ばれる特殊なユニットを採用しています。
> MICはL1データキャッシュの制御を引き継ぎ、キャッシュの一部をプリフェッチストリームバッファに変更します[8,11]。
> ストリームバッファは、次のベクトルロードのアドレスを予測し、そのデータをキャッシュに早期に持ち込む。
> これにより、後続の命令ブロックのベクタロードが常にL1キャッシュにヒットすることが保証されます。
> ? 　 ry 従来のキャッシュとして動作 ry 。
> 　ベクトルおよびスカラー演算は命令ブロックで混合されるので、キャッシュの一部は依然として従来型キャッシュとして動作する必要があります。
> ? ry 半減させますか？ それらの方法をスト??リームバッファ用のメモリに変換する。
> キャッシュのサイズを半分にするのではなく、キャッシュのセットアソシアティビティを半減させますか？ つまりそれらのウェイをストリームバッファ用のメモリに転換する。
> ベクタロード時に、キャッシュはストリームバッファをチェックします。
> スカラのロードとストアでは、チェックするセットの数は少なくなりますが、キャッシュは同じ方法でキャッシュをチェックします。
> 　ベクタストア命令は、ブロックコミットまでストリームバッファにバッファされ、その時点でメインメモリに直接書き込まれます。
> 
> 4. 例：RGBからYへの変換
> 　このセクションでは、E2でプログラムをベクトル化する方法を説明する例を示します。
> 図2は、カラー画像をグレースケールに変換するために一般的に使用されるRGBからYへの輝度変換のためのCコードおよび対応するベクトル化されたアセンブリを示す。
> 
> 1 // numVectors > 0
> 2 // y = r * .299 + g * .587 + b * .114;
> 3 void rgb2y(int numVectors,
> 4  __vector float *r, __vector float *g,
> 5  __vector float *b, __vector float *y)
> 6 {
> 7 __vector float yr = { 0.299f, 0.299f,
> 8  0.299f, 0.299f };
> 9 __vector float yg = { 0.587f, 0.587f,
> 10         0.587f, 0.587f } ;
> 11 __vector float yb = { 0.114f, 0.114f,
> 12         0.114f, 0.114f };
> 13 
> 14 for (int i = 0; i < numVectors; i++)
> 15         y[i] = r[i] * yr + g[i] * yg + b[i] * yb;
> 16 }
> 17 
> 18 _rgb2y:
> 19         read t30, r3    // numVectors
> 20         read t20, r4    // next rのアドレス
> 21         read t21, r5    // 次のgのアドレス
> 22         read t22, r6    // 次のアドレスb
> 23         read t32, r7    // yのアドレス
> 24         read t31, r8    // i
> 25         read t1, v0     // vector yr
> 26         read t3, v1     // ベクトルyg
> 27         read t5, v2     // vector yb
> 28 
> 29 // RGBからYへの変換
> 30         vl t0, t20 [0]  // ベクトルロード
> 31         vl t2, t21 [1]
> 32         vl t4, t22 [2]
> 33         vfmul t6, t0, t1        // ? ベクトルfp mul ベクトル 乗算 fp
> 34         vfmul t7, t2, t3
> 35         vfmul t8, t4, t5
> 36         vfadd t9, t6, t7        // ? ベクトルfp add ベクトル 加算 fp
> 37         vfadd t10, t8, t9
> 38 
> 39 // 結果をYに格納する
> 40         multi t40, t31, #32
> 41         add t41, t32, t40
> 42         vs 0(t41), t10 [3]      // ベクトルストア
> 43 
> 44 // ループテスト
> 45         tlt t14, t31, t30
> 46         ret_t<t14>
> 47         br_f<t14> rgb2y
> 48         addi r8, t31, #1
> 49         addi r4, t20, #32
> 50         addi r5, t21, #32
> 51         addi r6, t22, #32 
> 
> 図2： ベクトル化されたRGBからYへの輝度変換のためのCソースコードおよびE2アセンブリリスト。
> 
> 画像の各ピクセルは、赤、緑、および青の色成分に対応する三重線を有する。
> 輝度（Y）は、各RGB値に定数を掛け、3つの結果を合計することによって計算される。
> このプログラムは、各変換が独立しているため、並行して複数の変換を実行するために、並行して並列化することができます。
> 4.1 Cソース
> ? 　ry 、これらのベクトルへのポインタ、 ry Yへのポインタ、変換するベクトルの数 ry 。
> 　各RGBコンポーネントはベクトルで表され、これらの三つのベクトルへのポインタ、事前に割り当てられた結果ベクトルYへのポインタ、そして変換するベクトルの数が引数として関数に渡されます（行4-5）。
> 変換の定数もベクトルに格納されます（7-12行目）。
> 各ベクトルは256ビット幅で、個々のデータ要素は32ビット単精度浮動小数点型なので64ビットにパディングされます。
> 変換は単純なforループを使用して行われます（14^Z16行目）。
> ? この例 ry 、ループを展開してブロックを埋めるわけではありません。
> 例を単純化するために、ループ展開でブロックを埋める事を避けます。
> 4.2 アセンブリ
> 　アセンブリリストは、18^Z51行目に記載されています。
> ?  ry 、新しいブロックはすべてのラベル（ライン18）で開始されます。
> 命令はコンパイラ（この例では1つのブロック）によってブロックにグループ化され、全てのラベルは新しいブロックの先頭を意味します（ライン18）。
> アーキテクチャは、ブロックをアトミックにフェッチ、実行、およびコミットします。
> 慣習的には、スカラーレジスタを表すためにRn、ベクトルレジスタを表すVn、テンポラリオペランドを表すTnを使用します。
> ? ry 、すべてのブロックで参照できるグローバル状態の一部です。
> スカラーレジスタとベクタレジスタは、全てのブロックでグローバルステートとして参照できる構成要素です。
> ?  ただし、一時的なオペランドは、 ry 表示されます。
> 但し、テンポラリオペランドは、定義されたブロック内でのみ参照可能です。
> ? ry 19行目???卸行目 ry 。
> グローバルレジスタファイルから読み取ることができる命令は、レジスタREAD命令（19行目 - 27行目）のみです。
> ただし、ほとんどの命令はグローバルレジスタファイルに書き込むことができます。
> 
> 　ベクトル命令は 'v'で始まります（行30-37と42）。
> すべてのロード命令とストア命令には、ロード・ストア識別子が割り当てられ、シーケンシャル・メモリ・セマンティクスが確実に行なわれます（30^Z32行目と42行目）。
>   That is a load assigned ID0 must complete before a store with ID1.
> ? これは、割り当てられた負荷ID0は、ID1のストアの前に ry 。
> ここで割り当てられた処理ID0は、ID1のストアの前に完了する必要があります。
> 　ほとんどの命令は述語になり得、述語は定義されたブロック内でしか見ることができない。
> 述語命令は、述語命令に符号化された極性と比較される真または偽を表すオペランドを取る（_tおよび_fで示される）。
> 45行目のテスト命令は、受信命令（行46^Z47）が自身の符号化された述語と比較する述語を作成する。
> 一致する述部を持つ命令だけが実行されます。
> 
> 
> Page 6 
> 
> 　ブロックは最大で128個のスカラ命令に制限されています。
> ベクトル命令を使用する場合、ブロックは合計32個のスカラ命令とベクトル命令に制限されます。
>     Block _rgb2y contains a mix of 27 scalar and vector instructions.ブロック_rgb2yには27種類のスカラー命令とベクトル命令が混在しています。
> 
>サイクル        1 2 3 4 5 6 7 8 9 1011121314151617
>FETCH               IF IF IF IF
>READ                  R R R R R 
>READ                  R R R R 
>MEM             L L L                       S 
>EX              A A A M M M M M M M M M A A B 
>EX              M A T M M M M M M M M M A A A 
>EX                    M M M M M M M M M A A 
>EX                    M M M M M M M M M A A 
> 
> 図3： 図2の1つの可能なスケジュール。
> 
> ? 4.3 指導スケジュール
> 4.3 命令スケジュール
> 　図3は、図2の例の1つの可能なスケジュールを示しています。
> 我々は、3サイクルの32ビット浮動小数点乗算を仮定し、すべてのロードがL1キャッシュでヒットし、3サイクルが必要となる。
> アーキテクチャは1サイクルにつき8命令をフェッチすることが可能であり、したがって、27命令ブロックをフェッチするために4サイクルを必要とする。
> サイクル1では、8つのレジスタ読み出し命令がフェッチされ、これらの命令は依存性がないので、次のサイクルですべて実行可能である。
> ? すべてのグローバル・レジスタを読み出すために5サイクルを必要とする1サイクルにつき2回のレジスタ・リードが実行できます。
> 1サイクルに付き 2 つのレジスタの読出しが実行でき 5 サイクルですべてのグローバル・レジスタを読出せます。
> サイクル2では、レジスタR4（20行目）とR8（24行目）が読み出され、ベクタロード（30行目）、即値乗算（40行目）、および即値（48行目）命令に送られます。
> これらの命令はそれぞれ1つのオペランドで待機しているため、すべて準備ができてサイクル3で実行を開始します。
> サイクル17でブロックがコミットする準備ができるまで、このデータフローの形で実行が継続されます。
> 
> 5. 結論
> ? 　 ry 、E2アーキテクチャについて説明しましたか？ 高性能な電力を効率的に達成するために設計されたExplicit Data Graph Execution（EDGE）ISAを利用した新しい動的マルチコア。
> 　この論文では、E2アーキテクチャ -- 演算性能が高く電力を効率的に達成するために設計されたExplicit Data Graph Execution（EDGE）ISAを利用した新しい動的マルチコアに付いて説明しました
> EDGEアーキテクチャとして、E2はデータフローの実行と攻撃的な投機によって命令レベルの並列性を効率的に活用します。
> さらに、ベクトルとSIMDのサポートによって、データ・レベルの並列性を処理するためにアーキテクチャがどのように適応するかを説明しました。
> このベクトルのサポートにはスカラー命令が散在しているため、E2は従来のベクトルプロセッサよりも柔軟性があり、従来のスカラーアーキテクチャよりも優れています。
> ? 　 ry 、SystemCとMicrosoft Phoenixソフトウェアの最適化と分析フレームワークで新しいコンパイラバックエンドを使用してE2用の ry 。
> 　我々は、最適化と分析のフレームワークであるMicrosoft Phoenixソフトウェア付きの新しいコンパイラバックエンドと SystemC とを使用して E2用のアーキテクチャシミュレータを開発しました[1]。
> ? 、産業強度コンパイラ ry 。
> 私たちは現在、我々の産業強度コンパイラと組み合わせることで、アーキテクチャの詳細な調査と評価を実行できるサイクル精度の高いFPGA実装を開発中です。
> ? ry 先行しています。
> 　多くの課題が待受けています。
> アクセラレータとして説得するためには、GPUや専用ベクトルプロセッサなどの特殊なアクセラレータよりも優れた性能、電力効率、プログラマビリティを提供することを示す必要があります。
> E2は汎用プロセッサとしても優れている可能性があります。その場合、新しいISAへの移行を正当化するために、現在の静的マルチコア・アーキテクチャに比べて十分な電力/性能の向上が得られることを示す必要があります。
> 　E2のパフォーマンスと電力効率は、コアを動的に構成および分解する能力を基盤としているため、動的構成を管理するための正しいポリシーとメカニズムには慎重な検討が必要です。
> ? ry プログラマーが基盤となるハードウェアについて推論 ry 。
> 理想的には、コンポジションに関するすべての決定をランタイムシステムに任せることで、プログラマーがこのハードウェアの根本に付いて推論することを完全に免れます。
> 　最後に、組み込みデバイスからデータセンターまで、E2のパワーとパフォーマンスのトレードオフの能力が役立つさまざまなアプリケーションドメインがあります。
> 今後数か月間に、さまざまな作業負荷を検討し、E2プロセッサがどの程度電力性能スペクトルに及ぶかを調査する予定です。
> 
> 6. 参考文献
>  [1] Microsoft Phoenix。
>  http://research.microsoft.com/phoenix/
>  [2] ARM。 Cortex-A9 MPCoreテクニカルリファレンスマニュアル、2009年11月
>  [3] D. Burger、SW Keckler、KS McKinley、M. Dahlin、LK John、C. Lin、CR Moore、J. Burrill、RG McDonald、W. Yoder、およびTRIPSチーム。 EDGEアーキテクチャを使用したSilicon Endへのスケーリング IEEE Computer、37（7）：44？55、2004年7月。
>  [4]ケイデンス。 Cadence InCyte Chip Estimator、2009年9月。
>  [5] H. EsmaeilzadehおよびD. Burger。.階層的制御予測：積極的な予測のサポート。.マルチコアアーキテクチャにおけるシーケンシャルプログラムの並列実行に関する2009ワークショップの講演会、2009年。
>  [6] MD HillとMR Marty。 マルチコア時代のアムダールの法則。 IEEE COMPUTER、2008。
>  [7] E.？Ipek、M. K？rman、N. K？rman、およびJF Mart？ez。 コア・フュージョン：チップ・マルチプロセッサにおけるソフトウェア・ダイバシティの適応。 コンピュータアーキテクチャに関する国際シンポジウム（ISCA）、サンディエゴ、CA、2007年6月。
> ? [8] ry 小さな完全連想キャッシュ ry 。
>  [8] NP Jouppi。 小さなフルアソシエイティブキャッシュとプリフェッチ・バッファを追加することで、ダイレクト・マップ・キャッシュのパフォーマンスを向上させます。 SIGARCH Computer Architecture News、18（3a）、1990を参照されたい。
> ? [9] ry マイクロシンポジウム ry 。
>  [9] C.Kim、S.Sethumadhavan、D.Gulati、D.Burger、M.Govindan、N.Ranganathan、およびS.Keckler。 構成可能な軽量プロセッサ。.第40回IEEE / ACMマイクロアーキテクチャ国際シンポジウム議事録、2007年。
>  [10] S. Sethumadhavan、F. Roesner、JS Emer、D. Burger、およびSW Keckler。 遅延バインディング：順序なしロード・ストア・キューを使用可能にします。 2007.第34回国際コンピュータシンポジウム講演予稿集、347^Z357頁、ニューヨーク、 NY 、米国、2007年。 ACM。
> ? [11] ry 国際シンポジウム ry 。
>  [11] T.シャーウッド、S。セア、B.カルダー。 予測子指示ストリームバッファ。    In Proceedings of the 33rd Annual ACM/IEEE International Symposium on Microarchitecture, 2000.第33回ACM / IEEE国際マイクロアーキテクチャシンポジウム講演予稿集、2000年。
>  [12] A.スミス。 明示的なデータグラフのコンパイル。 博士論文、テキサス大学、オースティン、2009年。
> 
> 
> 
> http://theregister.co.uk/2018/06/18/microsoft_e2_edge_windows_10/
> http://gigazine.net/news/20180620-microsoft-e2/
> http://web.archive.org/web/20110119204947/research.microsoft.com:80/en-us/projects/e2/
> 
> 
> 
>> PR : シンギュラリティ系有料メールマガジン発行を構想致しております
>> 無料メールマガジン版 ( 別途有料版開始時打切 )
>> http://mailux.com/mm_dsp.php?mm_id=MM53D8AF3589BC7
>> 
>> 
>> 
>> YAMAGUTIseisei wrote:
> :
>>>>>>                                        意味スレッド有機分散普遍浸透
> :
>>>>71>  YAMAGUTIseisei wrote ( <53F85930.1000209@hello.to> ) :
>>>>>>>  マルチ PC 的スーパスカラ マルチ PC 的順序外実行
>>>>>71> ↓
>>>>>>>>01>  フェイルレストランザクション ( 普遍浸透有機スレッド Aperios BeOS PalmOS6 DfBSD ) 
>>>>>71> ↓
>>>71>  フェイルレストランザクションベース細粒度分散 VM
>>>>71> 
>>>>71> 
>>>>>>>v1> メインメモリ細粒度ページ ( キャッシュライン投影 ) ※1
>>>>>>>v1> ↓
>>>>>>>71>  細粒度ページ単位普遍マルチスレッド ( 完全掌握 ) ※2
>>>>>>>v1> ↓
>>>>>>>71>  キャッシュ対応疑似分散 UMA ( コヒーレントレスコヒーレント 浸透スレッド ) ※3
>>>>>>>v1> ↓
>>>>>>>71>  透過可視マルチプロセッサベース論理物理ユニプロセッサ ( 256KB-SPE 込 ) ※4 
>>>>>>>v1> 
>>>>>>>v1>  ↓↑ ( VM 策 ↑ / ↓ 環境策 1 ) 
>>>>>>>v1> 
> :
>>>>>>>v1> 
>>>>>>f1>  
>>>>>f>  ※1 ROM 化オブジェクト 多段実身仮身 TRONCHIP キュー ( MMU )
>>>>>f>  → 自律 機能メモリ
>>>>>>>>>v>  
>>>>>>>>>v>  ※2 選別 波及 浸透 仮身 高低 細胞
>>>>>>   競合自動回避 分配済オブジェクト投影 ( 必然分配 上流 Ru?y )
>>>>>>7>  API 内外 鏡像 → API 内部 API 外部 ( 内宇宙 外宇宙 )
>>>>>v>  
>>>>>>>71>  ※3 BeBox : キャッシュ非対応 ( 環境 ) 
>>>>>>f1> 
>>>>>>>71>  ※4 MPU 機構直交融合動的普遍オーバライド 
>>>>>>f1>  ( 加算器 レジスタ トラップ・ベクタ・ブレークポイント ) 
>>>>>>f1> 
>>>>>>71>  ※5 Rite : スタック 分散 ( Amoeba : 生バイナリ )
>>>>71>  
> :
>>>f>  細粒度スレッドレベル部品分散 VM / MTRON WinnyOS ( Aperios/MuseOS ) 
> :
> 
> 
> 
> -- 
> フリーソフトウエア関連ボランティアの皆様に感謝申上げますと共に
> 当原稿執筆の多大なるコストへの御配慮に厚く御礼申上げます
> 三菱 UFJ 銀行 平針支店 ( 普 ) 0111481 ヤマグチセイセイ
> 郵便局 218普2449768 ヤマグチセイセイ
> Yahoo pt 1362821068616323 Rakuten pt 1100-3310-4065-1717
> http://yahoo.jp/HsDIGs?#_2TB_0S03224
> 
> 
> 
> :
>>>>>>f1> ↓
>>>>>f>  有機無機ハイブリッドコンピュータ ( 有機分子 返り値 互換 )
>>>>>>f1> ↓
> :
>>>>>f1> 
>>>>>f1> 
>>>>>f1> 
>>>>>>>>71> YAMAGUTIseisei wrote ( <538AEA82.4040806@hello.to> ) :
>>>>>>>>>>71> YAMAGUTIseisei wrote ( <52597E0B.3040207@x68k.net> ) :
>>>f1>  AAP/SPE AI/AL クラスタ
>>>>>>f1> ↓
>>>f1>  AAP/SPE 有機コンパイル ( 自生 / 3D プリンタ )
>>>>>7>  細粒度ライブラリベース回路 ( 最適化 )
>>>>>7> 平面有機回路 積層有機回路
>>>>>>f1> ↓
> :



-- 
YAMAGUTIseisei ( str_h__namae = { :sei => "山口" , :mei => "青星" } )
http://hello.to/seisei/ mailto:seisei@.68..net  tel:081-70-5152-1104
heiwa furiisekkusu 1t