fused micro OPsの考察

CPUアーキテクチャについて語れ 9より
確かめてもいないのでただしいのか不明。単純なx86命令を実行できる3つ以下のmicro OPに分け、そのまま3つ入るフォーマットへ入れる。これをROSへ持って行き、実行されるデータの場所を保存しておく。micro OPはRSへ行く。全て実行し終わったらデータが埋まるので実行完了にする。らしい。
メリットは命令実行のスケジュール管理が楽になること。
デメリットは保持しておくデータが大きくなること。
レジスタリネームさえ賢くやれば、意外と並列に行える命令数はかわらなそう。各実行ユニットの前で、もう一度すぐに実行できないデータを保持しなければならない?それともストールしても、結局ストールしているステップが違うだけなので問題にならない?ROSがin orderなのだから後者かな。

274 :Socket774:2008/03/12(水) 17:16:56 id:SEi8tyfB
そもそもの発端となったIssaiahだけど
http://www.extremetech.com/article2/0,1697,2252201,00.asp

ブロック図の解説をしてみる。
だいたい見ての通りだけど、補足が必要そうなのは

・Rename & allocate into Reservation Stations から ROB, MOB(=Memory Order Buffer), arch regs へのフロー

ROBエントリはレジスタリネームがらみの情報を保持しているので
(ROBエントリ解放時に、物理レジスタを何個解放すべきか)
そういうフローだと思う。

実装がどうなっているか知る由もないが、ROBエントリの確保自体はFIQと平行させることも可能ではある。


・ROBのブロックからOoOブロックへのフロー
arch regs(x86レジスタ)から読み出したデータのフロー。


OoOブロックからROBブロックへのフロー
result forwarding network経由で、実行結果をROBエントリに書き込むフロー。

命令のリタイア時に、ROBエントリからarch regsに書き込みが行われる。1ページ前の↓これ。
> Retirement means that the x86 registers are updated, memory changes are committed,
> x86 exceptions are taken, and so forth.

275 :Socket774:2008/03/12(水) 18:05:56 id:SEi8tyfB
Isaiahでは、micro-op(s)と呼ばれるものは

executable micro-op そのまま実行ユニットで実行できるもの
fused micro-ops 0から3命令のexecutable micro-opsfuseしたもの

と二種類あるので、たんにmicro-opsと書いてある場合には、どちらを指すのかきちんと区別することが重要。
でないとMA(略)

X86 INSTRUCTION TRANSLATIONの

> The next stage translates the x86 instructions from the FIQ into micro-ops.
> Each x86 instruction can be directly translated into zero, one, two or three micro-ops (in the initial implementation)
> and an optional ROM address.

micro-opsは、二箇所ともexecutable micro-ops
そもそもこの時点ではfused micro-opsはまだ出て来ていない。

> Also, each micro-op generated by the translator can represent functions to be performed by more than one execution unit.
> This combining of execution unit micro-ops into more powerful micro-ops is called micro-op fusion.

execution unit micro-ops == executable micro-opsはただの言い換え。
いつexecutable micro-opsをmore powerful micro-opsにcombiningするのか明示されていないが、
> each micro-op generated by the translator(以下略)
とあるので、変換器から出てきた時点ですでにfused micro-opsだと読める。


276 :Socket774:2008/03/12(水) 18:07:50 id:SEi8tyfB
で、変換器によって(マイクロコードを使わない)x86命令は、

・常にただ1つのfused micro-opsに変換されるか、つまりx86命令とfused micro-opsは一対一に対応しているか

が問題だったわけだが、
マイクロコードを使わないx86命令は、高々3つのexecutable micro-opsに変換されるため、
わざわざ複数のfused micro-opsに変換する必要性が考えにくいこと、

MICRO-OP RENAMEの
> The translator and microcode subsystem can each produce three fused micro-ops
> (corresponding to up to three x86 instructions) each clock.
変換器のバンド幅が3 x86命令なので、1つのx86命令が1つのfused micro-opsに変換されるとちょうど釣り合うこと、

> The three incoming fused micro-ops are placed in the reorder buffer (ROB)
MICRO-OP RETIREMENTの
> Up to three fused micro-ops can be retired each clock corresponding to up to three x86 instructions.
ROBのバンド幅も3 x86命令であり、
ROBにはfused micro-opsのまま格納されリタイアすること、ROBがx86のインオーダー状態を管理することを思えば、

「マイクロコードを使わない1つのx86命令は、変換器によって1つのfused micro-opsに変換される」

というのが、ごく自然な考え方だと思います。

277 :Socket774:2008/03/12(水) 18:14:07 id:SEi8tyfB
>>208
訳、大助かりです。

> 最終的なqueueのuop出力では3 uop/cycleに律速される?まあ平均の話だけど。

ここは、3 fused uop/cycleだと思うので、

> 3つのfused-uopは、reorder buffer(ROB)へと移され、そこで最大6つの実行可能uopへ展開される。

理論的には、ここの最大6つの実行可能uopへの展開が律速だと思います。
もっとも、fused micro-opsが平均2個未満の実行可能uopしか持たないのであれば律速しませんが。

278 :Socket774:2008/03/12(水) 18:45:27 id:SEi8tyfB
訂正

>>276
> > Up to three fused micro-ops can be retired each clock corresponding to up to three x86 instructions.
> ROBのバンド幅も3 x86命令であり、

ROBのバンド幅は「3 fused micro-ops」であり、


279 :MACオタ:2008/03/12(水) 23:03:47 id:SEi8tyfB
さて、以上を踏まえた上で、もう一度この主張をお願いするす>MACオタさん

前スレ
858 名前: MACオタ [sage] 投稿日: 2008/01/30(水) 08:12:50 ID:X/E3HbLz
>>854 団子 さん
micro-opsの正体に関する話題わ、全然聞いたことが無いす。
ただK8とK10で命令処理のフロントエンドを開発し直す実力がAMDにあったとわ、思えないす。

>>855 さん
  ------------------
  実際にはトランスレータは一つのfused micro-opsに変換しているというのは以下の通り。
  ------------------
その文章にfused micro-opsx86命令にそれぞれ対応するという記述わ「一切」無いすけど。。。
フュージョンして扱える条件わ、もっと限定されたモノなのでわ?
このように書く理由わ、下記の問いに対する説明にもなるかと思うす。
  -------------------
  早め、というのが何を言っているのかわからんが、ディスパッチステージより前ということか?
  どういう意味があるんだ?
  -------------------
端的にわ、そもそもRISCの設計がそのように最適化されているす。
OoO用の命令キューというモノわ、なるべく沢山の命令を放り込んで同時実行可能な組み合わせを
検索できることに意味があるす。ところが命令ごとに実行レイテンシわ異なるので、混在させると時間
のかかるロード/ストアや浮動小数点命令ばかりがキューに居座ることいなるす。
早めに命令を分類することわ、効率の向上に繋がるすよ。

更に現代のプロセッサでわ、細粒度の電力管理のために各命令が使用するリソースを早めに確定
して電力管理のスケジュールを立てることも重要す。


280 :Socket774:2008/03/13(木) 02:18:04 id:VO25v4Yv
かわいらしい人がいるのかな。

MICRO-OP RENAME
> The three incoming fused micro-ops are placed in the reorder buffer (ROB)
> and are then expanded into up to six executable micro-ops, each of which is targeted for a single execution unit.

素直に読めば、fused micro-opsがROBにplaceされて
そしてその後(and then)、最大6つのexecutable micro-opsに展開される、と読めます。

> The registers used in the executable micro-ops are mapped (renamed) into the larger internal set of registers
> and then placed in the seven micro-op "reservation stations" (RS) associated with the seven issue ports.

素直に読めば、executable micro-opsで使われているレジスタがリネームされて、
そしてその後(and then)、7つのRSにplacceされる、と読めます。

MACオタは、前スレ843で
> ちなみにあなたわMacro-ops fusionとMicro-ops fusionの区別が理解できなくて私に噛み付いている
> ように見えるす。私の疑問わ、 各実行ユニットに対応した最小単位のmicro-opsへの分解がROBで
> 行われるのか、RSで行われるのか?。。。というモノなんすけど。
と書いていますが、これは意味の通らない疑問です。

本文には、fused micro-opsがexecutable micro-opsに展開されて、それぞれのexecutable micro-opsがRSに分配されると書いているので、
> RSで行われるのか?
はナンセンスだし、
もし「ROBがfused micro-opsを分解する」のなら、パイプラインステージの一部となるはずですが、そういう記述はない。

281 :Socket774:2008/03/13(木) 02:19:09 id:VO25v4Yv
ところで、こんな記述もあるすね。
ttp://pc.watch.impress.co.jp/docs/2006/0626/kaigai285.htm
> 知られているように、Fusion(融合)と呼んでいるのは、複数のRISC風uOPsを1個のuOPsに融合させるという概念からだ。
> だから、Core MAでの、複合uOPsは「Fused uOPs」と呼ばれている。しかし、実態は、比較的単純なCISCx86命令を、1対1でFused uOPsに変換しているに過ぎない。
> つまり、CISC命令を分解しないことがMicro-OPs Fusionの本質だ。

「比較的単純なCISCx86命令を、1対1でFused uOPsに変換しているに過ぎない。」
Core MAでもそうなんすね(笑)

282 :Socket774:2008/03/13(木) 16:44:24 id:vo3HrKRv
Isaiahの命令の流れは、結局のところ

FIQ→変換器またはマイクロコード→uopキュー→ROB→レジスタリネーム→RS

となっています。
このうち、fused uopsを保持するのは、uopキューとROBだけですが、
前スレ992のパクマン氏の言う通り

> そもそもROBにはx86命令もmicro-opもそのものは入らないだろ。この辺はMACオタも勘違いしているようだが。
> ROBはインデックス化された命令のアドレスとその実行結果etcを保持しているのが普通だが。
> つまり制御情報を保持しているのであって、命令そのものを保持しているRSと違うので混同しないでほしい。

ROBには命令そのものは入りません。
(パクマン氏の992の書き込み「自体」は、まったく正しいものです)

ところで
・fused uopsをexecutable uopsに変換するパイプラインステージは存在しない
ので
・fused opsは、ワイヤリングと簡単なロジックでexecutable uopsに分解できる簡単なフォーマットである
ことが推測されます。

そうすると、fused opsは比較的スカスカな命令フォーマットになりそうですが
・fused uopsを保持するのはuopキューのみ
なので、キューのエントリ数にもよりますが複雑で高密度なfused uopsフォーマットを採用する必要性は低いと思われます。

結局、前スレ845
> fused micro-opsというのは、実装上はおそらく単に3つのmicro-opsをパックしただけのものだと思う
は、妥当な推測だと思います。

パクマン先生、いかがすか?
前スレ
986 名前: パクマン [sage] 投稿日: 2008/02/13(水) 23:09:32 ID:6U5Xr+1Q
MACオタの
・ROBはIntel用語
は確かにイタイが、粘着くんの
・ ROBにはx86命令が入る
・ fused micro-opsというのは、実装上はおそらく単に3つのmicro-opsをパックしただけのものだと思う
・ fused micro-opsがROBに入れられて、その後ではじめて分解されて各実行ユニットのRSに送られる
この辺のまちがいもあるからな。どちらも間違いがあったが、総合ではMACオタの方がx86周辺の実装を
理解していたので勝ちと言うことにしよう。