08/03/08 02:03:11 WLLvrqQ/
前スレ865
ｽﾚﾘﾝｸ(jisaku板:865番)
> ディスパッチされてからリタイアするまでキュー以外の何処にいるすかね。。。あなたの脳内にでも
> テレポートしてくるすか(笑)
> 強調しておくすけど「リタイアするまで」OoOの命令キューから取り除かれることわないす。
前スレ858
ｽﾚﾘﾝｸ(jisaku板:858番)
> OoO用の命令キューというモノわ、なるべく沢山の命令を放り込んで同時実行可能な組み合わせを
> 検索できることに意味があるす。ところが命令ごとに実行レイテンシわ異なるので、混在させると時間
> のかかるロード／ストアや浮動小数点命令ばかりがキューに居座ることいなるす。
> 早めに命令を分類することわ、効率の向上に繋がるすよ。
>
> 更に現代のプロセッサでわ、細粒度の電力管理のために各命令が使用するリソースを早めに確定
> して電力管理のスケジュールを立てることも重要す。
151:Socket774
08/03/08 02:03:59 WLLvrqQ/
>>86
> 命令キュー=RSからは、イシュー時に取り除かれるんだけどね
> インオーダー状態の回復に必要なものはROBに残す
>>87
> >>86
> ROBのことを書いたすけど。
>
> OoOEで消費電力や回路規模の問題が。。。という話の中でRSが出てくると思い込む妄想脳にわ
> あきれ果てるばかりす(笑)
>>96
> ｽﾚﾘﾝｸ(jisaku板:858番) (>>93参照)
> ｽﾚﾘﾝｸ(jisaku板:865番) (>>91参照)
> の中で、あえて「OoOの命令キュー」と書いたのわ、ROBもRSも含めた命令管理のためのキュー／
> バッファをまとめて述べたからす。
152:Socket774
08/03/08 09:39:25 s/9YKOXA
そろそろ別にスレたててくれよ
コテについて語れじゃないだろ、ここは
153:Socket774
08/03/08 09:46:26 pr20Xr0v
ウザ粘着もコテ付けてくれれば面倒が少なくて済むんだけどねぇ
スレ伸びてると思って見てNGID追加ってのがルーチン化してる
ホントうざい
154:Socket774
08/03/08 11:37:52 WzqnQ1on
ないす と からす をNGワードにするか。
155:Socket774
08/03/08 12:46:45 L9dGnrme
野生生物板
156:Socket774
08/03/08 15:37:24 WLLvrqQ/
とわいえ脳内妄想などと失礼なことを言われて黙っているわけにもいかないす
迷惑をかけて申しわけないとわ思うが、MACオタが頭を下げるまで辛抱してください
157:Socket774
08/03/08 15:40:26 WLLvrqQ/
MACオタの、明かな間違いを訂正することわ、このスレにとっても有益だと思うす。
援護射撃をしてもらえれば、早く終わると思うんすけどね。
158:Socket774
08/03/08 15:45:21 3dWGar8e
>>145
レジスタ値を次（指定）コアに送るパイプライン
159:Socket774
08/03/08 15:46:15 WLLvrqQ/
コテについてわ検討したすが、肝心のMACオタが見なくなってしまうと困るので、止めることにしたす。
160:Socket774
08/03/08 16:12:29 GSpJqCS9
スレタイ嫁ボケ
糞なレスでリソース消費させるな屑
慎でワビいれろカス
161:Socket774
08/03/08 16:26:36 d8v7fm2z
> とわいえ脳内妄想などと失礼なことを言われて黙っているわけにもいかないす
私怨でスレを私物化されてもねえ…
162:Socket774
08/03/08 16:29:58 WLLvrqQ/
人に物事を頼むなら、それなりの口調でお願いするす(笑)
163:Socket774
08/03/08 16:31:41 WLLvrqQ/
>>161
じゃあ、MACオタわ詫びを入れなくてもいいけど、自分の間違いだけ訂正してくれれば勘弁するす
164:Socket774
08/03/08 16:36:33 WLLvrqQ/
MACオタわCPUアーキテクチャの根幹部分を理解せず、大きな間違いを書きちらしているす。
ここの住人のレベルわMACオタと五十歩百歩のようなので、MACオタの間違いを訂正させるのわ、
スレにとっても非常に有益だと確信してるす。
165:Socket774
08/03/08 16:38:26 WLLvrqQ/
わたし以外の住人が、MACオタの間違いをきっちり訂正するのでも構わないすよ(笑)
166:Socket774
08/03/08 16:43:05 s/9YKOXA
間違いがわかってるなら自分でサクっと正解書けばいいだろ
えんえんと同じことばかり書いてスレ荒らすなクズ
167:Socket774
08/03/08 16:52:35 WLLvrqQ/
>>166
正解わ何度も自分で書いてわMACオタに脳内妄想扱いされているす。
MACオタが苦しまぎれに>>96みたいなのを書いているのが唯一の反応す(笑)
やはりここわ本人の手で訂正して欲しいす。
あと、相手を罵ってもいい事など一つもないすよ(笑)
168:Socket774
08/03/08 16:54:55 WLLvrqQ/
>>166さんが、正解をわかっているのなら、書いてくれると助かるす。
そうでないなら、ここで正解を学習して欲しいす。
169:MACオタ
08/03/08 21:42:43 xLYlIju9
元TransmetaのDavid DitzelがIntelに入社したとのことす。
URLﾘﾝｸ(www.theregister.co.uk)
--------------------
Our sources reveal that Intel acquired Ditzel as a member of the Digital Enterprise Group (DEG),
which tackles both server and PC products. Ditzel will work with Stephen Pawlowski, an Intel senior
fellow and CTO of DEG.
--------------------
元ElbrusのBabaianと共に商用汎用VLIWプロセッサの指導的技術者わ全てIntelに集まったことになるす。
170:Socket774
08/03/08 22:10:35 WLLvrqQ/
>>166
> 間違いがわかってるなら自分でサクっと正解書けばいいだろ
わたしわ何度も「正解」を書いていたのに、今さらこんなことを言うところを見ると、
あなたもMACオタ並の理解だったわけすか。
171:Socket774
08/03/08 22:55:17 rzNY5VPk
>>169
さっさとPARROT作ってほしいす
172:Socket774
08/03/08 23:01:39 s/9YKOXA
>170
「間違いのほう」を延々と書くのがうざいって言ってるの
同じネタは一度で十分
173:Socket774
08/03/08 23:26:16 WLLvrqQ/
>>172
「正解」のほうも延々書いてるんすが、理解してもらえていないようで残念す。
174:Socket774
08/03/08 23:33:55 s/9YKOXA
>173
「荒らしがまた同じネタ書いてるよ」と思ってるだけだから内容見てないしな
まともなライターや研究者でさえ間違うことはあるんだから、たかがコテ程度なら
間違いくらいあって当たり前だろ。なにはしゃいでるんだよクズ
175:Socket774
08/03/08 23:46:11 WLLvrqQ/
>>174
残念ながら、MACオタのわそういうレベルの間違いでわなく、
CPUアーキテクチャの根幹についての重大な無理解す。
あと、他人を罵倒してもいいことわ一つもないす。
176:MACオタ
08/03/09 00:06:13 lSXgkkSe
ストーカーのヒトわ対象に相手にされないと、とりあえず相手をしてくれたヒトに憑き替わることがある
すから、放置がお勧めす。
>>175 さん
------------------
CPUアーキテクチャの根幹についての重大な無理解す。
------------------
私にわ、あなたの脳内に勝手に構築されたイメージにしか見えないす。
そもそもそんな重大な無理解なら、指摘するヒトがあなただけってコトが変だ思わないすか？
中二病特有の『ぼくちゃんわ２ちゃんに正義をもたらすために神に選ばれた特別な人物』てな
思い込みなんすかね。。。
177:Socket774
08/03/09 00:08:05 H29jm950
もしあれが、まともなライターや研究者でも犯すような誤りと考えられているのなら、
スレのレベルの低下わかなり深刻だと言わざるを得ないす。
益々がんばらねばす。
178:Socket774
08/03/09 00:08:45 H29jm950
>>176
指摘してくれた人わ、前スレに一人だけいるす。
179:MACオタ＠補足
08/03/09 00:09:14 lSXgkkSe
プロセッサやらスーパーコンピュータやらを語るスレッドにわ、少しヘンなヒトが寄ってくるのわ
良くある話なんで、気にすると負けかと思うす。
かつてのPowerPCスレッドや2年ほど前のIntel次世代スレッドなんて、コピペの間を縫って話題が
続くなんてのが普通だったかと。。。
180:Socket774
08/03/09 00:12:16 H29jm950
>>176
あなたも、>>96みたいなみっともない言い逃れをしているところを見ると、
自分の間違いにわそこそこ気がついているように思えるす。
間違いわ素直に訂正したほうが恥しくないすよ(笑)
181:MACオタ＞177 さん
08/03/09 00:13:03 lSXgkkSe
>>177
---------------
益々がんばらねばす。
---------------
願わくば、コピペ以外の方法をお願いするす(笑)
182:MACオタ
08/03/09 00:15:51 H29jm950
よく考えたら、MACオタをあぼーんしている人にわ関係ない話ですので、
コテはこれで行くのがよさそうす。
どちらが本人か判断に迷うことわないと思うす。
183:Socket774
08/03/09 00:32:29 H29jm950
>>176
OoOプロセッサのアーキテクチャわ、実際のところ理解するのわかなり大変なものなので、
MACオタみたいにきちんと理解できていないアマチュアが多いのわなんの不思議もないす。
もっとも、神に選ばれなくても理解わできる程度のものすけど(笑)
それでも、用語がきちんと使えない上に、RSとROBの機能の区別があやふやで、しかも間違って理解しているのはヒドイと思うすが。
184:Socket774
08/03/09 00:37:26 v0lKyMkB
何だかんだ言ってx64を
AKIBA PC Hotline! HotHot REVIEW
URLﾘﾝｸ(pc.watch.impress.co.jp)
185:MACオタ
08/03/09 00:44:21 H29jm950
うう、失敗したす。
レジスタリネーミング、RS、ROBの三つがOoOプロセッサの中核をなすものす。
これら三つわ通常わインオーダプロセッサにわないものす。
MACオタの理解わ、RSについてわ完全に間違い、ROBについてもあわてて学習したようだがまだどうも怪しい状態す。
186:MACオタ
08/03/09 00:54:11 H29jm950
MACオタわ、
> ROBのことを書いたすけど。
>
> OoOEで消費電力や回路規模の問題が。。。という話の中でRSが出てくると思い込む妄想脳にわ
> あきれ果てるばかりす(笑)
とか
> の中で、あえて「OoOの命令キュー」と書いたのわ、ROBもRSも含めた命令管理のためのキュー／
> バッファをまとめて述べたからす。
とか、苦しまぎれにちぐはぐなことを書いてるす(笑)ので、意図するところがわかりにくいすが、
ROBもRSも含めた命令管理のためのキュー／バッファ、というものがいかにナンセンスなものかわ言わずもがなす。
> OoO用の命令キューというモノわ、なるべく沢山の命令を放り込んで同時実行可能な組み合わせを
> 検索できることに意味があるす。ところが命令ごとに実行レイテンシわ異なるので、混在させると時間
> のかかるロード／ストアや浮動小数点命令ばかりがキューに居座ることいなるす。
これわ、RSの説明としても、ROBの説明としても、プロセッサ内のどんなユニットの説明としても、間違っているす。
187:MACオタ
08/03/09 01:24:48 H29jm950
>>186
どこが間違っているか、正しいのわ何かについてわ、前スレから書いてきているすが、
MACオタのみならず、パクマンなどのスレ住人にもなかなか理解してもらえなくて残念す。
表現を変えつつ、あきらめずに続けるす。
188:Socket774
08/03/09 01:35:34 Sqo3p2HO
>>176
> 指摘するヒトがあなただけ
もう何度目か知らないが、お前がトチ狂うたびに毎回誰かが
見過ごせないと感じて指摘してくるだろう？
サイレントマジョリティがお前の見方だとでも思ってるのか？ｗ
浅薄な知識で選択的に情報投下して他人を嘲笑するその人格が、
ROMや通りすがりにまで不快を催させてることをいい加減自覚しろ。
それと、煙たがられてるにも関わらず自作板に擦り寄ってくるお前
のほうが既にストーカーだから。他人を貶められるような身分かよ。
189:Socket774
08/03/09 01:49:29 Ic833tIi
＞プロセッサやらスーパーコンピュータやらを語るスレッドにわ、少しヘンなヒトが寄ってくるのわ
＞良くある話なんで、気にすると負けかと思うす。
とりあえずいろんな人にあやまれ。
190:Socket774
08/03/09 02:07:17 dwJAPgJb
自分のこと言ってるんだろ
191:Socket774
08/03/09 02:17:35 H29jm950
典型的なOoOプロセッサについての説明です。
各実行ユニットのRSをまとめて命令キューや命令ウィンドウといいます。
フェッチした命令を溜めておくものも命令キューといったりしますが、意味的に混同するようなものではないでしょう。
OoOプロセッサでは、各命令はフェッチ、デコード、レジスタリネームのステージを経由して、
ディスパッチステージで、命令の機能に対応した実行ユニットのリザベーションステーション(RS)に送られます。
RS内の命令は、オペランドが揃うまで待たされます。
オペランドが揃った命令は、順次実行ユニットに送られます。これをイシューといいます。
プログラム順で先行する命令が、オペランドが揃わずに待たされ、後続の命令が先にイシューされることがあります。
OoOの由縁です。
イシューされた命令は、ただちにRSから削除されます。
ロードや浮動小数点命令などの長レイテンシ命令であっても、オペランドが揃っていればただちにイシューされます。
長レイテンシ命令に直接あるいは間接的に依存する命令は、オペランドが揃わず待たされることが多いです。
ディスパッチもイシューも発行と訳されることがあるので、読むときはきちんと区別しましょう。
192:Socket774
08/03/09 02:58:25 H29jm950
ROBの説明です。
ROBはかなり異なった実装があるので、一番シンプルなものの説明をします。
ディスパッチステージ以前のどこかで、リオーダバッファ(=ROB)のエントリの確保が行われます。
ROBは、分岐予測ミスやメモリアクセス例外などのイベントが発生した場合に、
プロセッサ状態をインオーダ状態に、つまりイベントが発生したプログラム地点まで巻き戻すために存在します。
ROBの各エントリは、一命令や一物理レジスタに対応することが多いのですが、実装によって異なります。
ROBの各エントリは、出力先レジスタやストアバッファエントリ、例外情報など、
インオーダ状態の更新に必要な情報を保持しています。
ROBのエントリは、プログラム順に確保され、解放されます。
ROBのエントリが解放され、プロセッサ状態が更新されることを、
命令がリタイアする、といいます。コミットする、も同じ意味です。
OoO実行で後続の命令が先に実行が終わっていても、先行の命令がリタイアしていなければ、
後続の命令はリタイアが待たされます。
分岐ミスや例外が発生すると、ROBエントリは無効化され、OoO状態が破棄されます。
ページフォールトなどが起きた場合、ただちに例外を起すのではなく、いったん対応するROBエントリに例外情報が書きこまれます。
そのエントリが解放される時に、例外処理が発生します。
193:MACオタ
08/03/09 03:02:36 H29jm950
というわけで、↓がいかにトンチキなのか理解してもらえるといいんすが。
特に、キューに居座る命令について完全に誤解しているところとか、訂正して欲しいす。
前スレ858
ｽﾚﾘﾝｸ(jisaku板:858番)
> OoO用の命令キューというモノわ、なるべく沢山の命令を放り込んで同時実行可能な組み合わせを
> 検索できることに意味があるす。ところが命令ごとに実行レイテンシわ異なるので、混在させると時間
> のかかるロード／ストアや浮動小数点命令ばかりがキューに居座ることいなるす。
> 早めに命令を分類することわ、効率の向上に繋がるすよ。
>
> 更に現代のプロセッサでわ、細粒度の電力管理のために各命令が使用するリソースを早めに確定
> して電力管理のスケジュールを立てることも重要す。
前スレ865
ｽﾚﾘﾝｸ(jisaku板:865番)
> ディスパッチされてからリタイアするまでキュー以外の何処にいるすかね。。。あなたの脳内にでも
> テレポートしてくるすか(笑)
> 強調しておくすけど「リタイアするまで」OoOの命令キューから取り除かれることわないす。
194:MACオタ
08/03/09 03:13:01 H29jm950
> OoO用の命令キューというモノわ、なるべく沢山の命令を放り込んで同時実行可能な組み合わせを
> 検索できることに意味があるす。
これわ明らかにRSのことについて書いてあるとしか思えないす。
> ところが命令ごとに実行レイテンシわ異なるので、混在させると時間
> のかかるロード／ストアや浮動小数点命令ばかりがキューに居座ることいなるす。
これはRSについてわ間違いす。
居座るかどうかは依存関係によるのであって、命令自身のレイテンシとは無関係す。
ROBについてだとしても間違いす。
リタイアするまではなかよく居座ってるす。長レイテンシ命令ばかりが居座るなんてことはありえないす。
そもそも、こんな性質のキューはCPU内のどこにもないす。MACオタの脳内キューすかね。
> ディスパッチされてからリタイアするまでキュー以外の何処にいるすかね。。。あなたの脳内にでも
> テレポートしてくるすか(笑)
> 強調しておくすけど「リタイアするまで」OoOの命令キューから取り除かれることわないす。
あらあら、こっちでわROBの話になっちゃったみたいすね(笑)
で、苦しまぎれにこんなことを書いてるす。
> の中で、あえて「OoOの命令キュー」と書いたのわ、ROBもRSも含めた命令管理のためのキュー／
> バッファをまとめて述べたからす。
そのちょっと前に、こんなことを書いて妄想扱いしてたんすけどね(笑)
> ROBのことを書いたすけど。
>
> OoOEで消費電力や回路規模の問題が。。。という話の中でRSが出てくると思い込む妄想脳にわ
> あきれ果てるばかりす(笑)
195:MACオタ
08/03/09 06:37:23 H29jm950
RS、ROB、レジスタリネームわOoO実行を実現するCPUアーキテクチャの根幹す。
そのRS、ROBについて大間違いを書いた上に、今になっても訂正しないMACオタわ、
CPUアーキテクチャについて何も理解していないと言わざるを得ないす。
断じて、研究者やライターでもするような勘違いやミスといったレベルの間違いでわないす。
そもそもROBをx86用語と言っているようでわ。。。
MACオタが他にも大嘘を書きちらかしたことわ推して知るべしす。
実際、今までさんざん大嘘を書いてわつっこまれていたす。
事が枝葉末節であれば、わたしもここまで粘着しなかったすし、過去にわ放置してきたすが、
さすがに今回の間違いわあまりにも重大なので、見過すわけにわいかなかったす。
196:MACオタ
08/03/09 06:53:27 H29jm950
RSやROBについての正しい理解がなければ、そもそもCPUアーキテクチャについて語ることなど不可能す。
その意味で、わたしわスレタイに忠実に行動してきたす。
ちなみに、MACオタの間違いわ即座に指摘したすが脳内妄想扱いされましてね。。。
859 名前： Socket774 [sage] 投稿日： 2008/01/30(水) 14:05:46 ID:/JD5n/hb
>>858
> フュージョンして扱える条件わ、もっと限定されたモノなのでわ？
？？MACオタこそどういう理解をしているんだ？
何を考えているのか見当もつかないが、それこそどこにそういう記述があるんだ？
> OoO用の命令キューというモノわ、なるべく沢山の命令を放り込んで同時実行可能な組み合わせを
> 検索できることに意味があるす。ところが命令ごとに実行レイテンシわ異なるので、混在させると時間
> のかかるロード／ストアや浮動小数点命令ばかりがキューに居座ることいなるす。
大丈夫か？
命令キューに居座るのは、長レイテンシ命令に直接・間接的に依存した命令だよ。
具体的には、キャッシュミスしたロード命令の結果に依存している命令群とか。
スループットが十分あれば、浮動小数点命令だろうがメモリアクセス命令だろうが、依存性のない限りはどんどん出ていくよ
868 名前： Socket774 [sage] 投稿日： 2008/01/31(木) 23:32:50 ID:9700t1FF
>>865
だからインテルは関係ないだろ…
イシューされてからリタイアするまでの間も命令キューに残してどうしたいんだ。
リオーダバッファは何のためにあると思ってるんだよ。
197:Socket774
08/03/09 07:37:24 zwtASq42
区別つかねーから、なんか文字列を付与しろや
198:MACオタ
08/03/09 07:40:53 H29jm950
区別つかねーようにしてるす。
もっと早く>>191や>>192のような解説を書きたかったすが、
MACオタが揚げ足をとって話をそらそうとするのが目に見えるすからね。
199:MACオタ
08/03/09 07:48:23 H29jm950
ウザイのわ重々承知してるすし、申し訳なく思ってもいるすが、
スレタイに忠実に行動している以上、改めることわないす。
200:MACオタ
08/03/09 08:10:20 H29jm950
>>176
> ------------------
> CPUアーキテクチャの根幹についての重大な無理解す。
> ------------------
> 私にわ、あなたの脳内に勝手に構築されたイメージにしか見えないす。
> そもそもそんな重大な無理解なら、指摘するヒトがあなただけってコトが変だ思わないすか？
他にも指摘する人が出てきたら、MACオタに自分の間違いを認めさせることができるかも知れないす。
(できないかも知れないすが。。。)
MACオタが自分の間違いを認め訂正したら、わたしもコピペや連投も終わらすことができて、万事解決なんすが。
201:Socket774
08/03/09 08:13:41 MY0Y+OtV
道端のウンコをワザワザいじりにいくのは
アラレちゃんくらいだ
202:Socket774
08/03/09 08:47:36 6jEAprDC
というか、いいかげんよそでやれや
203:MACオタ＞妄想のヒト
08/03/09 09:10:42 lSXgkkSe
やっと話が繋がりだしたので、お付き合いするす。
私の立場わ『ROBもRSも含めた命令管理のためのキュー／ バッファをまとめて述べた』(>>96)なんす
けど、命令がパイプライン内をどのように進むかを考えた場合、
>>191
------------------
ディスパッチステージ以前のどこかで、リオーダバッファ(=ROB)のエントリの確保が行われます。
------------------
という必要があるす。
ここで重要な点わ、以下の全ての条件が満たされない限りROBへの登録の前で止まることす。
・ROBの空き
・リネームレジスタの空き
・RSの空き
そして、この中で最も開放が遅いのわリタイアまで空かないROBということになるす。
RSさえ空いていれば何でもできると考えていないすか？
204:Socket774
08/03/09 10:00:51 KkWUtwbU
よそいけ
205:Socket774
08/03/09 12:41:41 dwJAPgJb
このスレでいい
206:MACオタ
08/03/09 13:37:02 H29jm950
>>203
最初に確保され、最後に解放されるのがROBエントリすが、
通常わRSエントリ数よりもROBエントリ数のほうが多いす。
パイプラインの流れからいっても、RSに空きがないのでROBエントリを確保しないということわ絶対にないす。
Issaiahでわ、ROBエントリを確保してからレジスタリネームが行なわれるす。
多くのRISCでわ、ROBエントリと物理レジスタわ同じ数だけあって、平行して同時に確保されるす。
ROBエントリを複数の命令・レジスタに対応させるプロセッサもあるすが、
そういうものでわ、物理レジスタに対して十分な数のROBエントリが確保されているすので、
物理レジスタに空きがなくても、ROBエントリわ確保することが可能す。
いずれにしろ、どんなプロセッサでも物理レジスタに対して十分なエントリ数をもつROBを備えているす。
なぜなら、ROBエントリの確保わ演算パイプラインの一部でわないので、
こんなところがネックになってパイプラインを止めるのわ馬鹿げているからす。
だから、
> ここで重要な点わ、以下の全ての条件が満たされない限りROBへの登録の前で止まることす。
> ・ROBの空き
> ・リネームレジスタの空き
> ・RSの空き
ROB自身に空きがなければ止まるのわ当然として、あとの二つわ端的に言って間違いす。
特に、RSに空きがなければ、ROBエントリを確保してからディスパッチステージで止まるだけす。
> そして、この中で最も開放が遅いのわリタイアまで空かないROBということになるす。
この三つのユニットの解放時期を比較してどういう意味があるすか。
> RSさえ空いていれば何でもできると考えていないすか？
どこからこういう難癖が出てくるのか。。。
MACオタの被害妄想は底が知れないす(笑)
207:MACオタ
08/03/09 14:57:32 H29jm950
> 私の立場わ『ROBもRSも含めた命令管理のためのキュー／ バッファをまとめて述べた』(>>96)なんす
そもそもこれわどういう立場なんすか。
ROBもRSも含めて一緒くたに述べて、>>203みたいな大嘘を書きちらす以外のどういう利益があるすか。
あなたわこんなことも書いていたすよね。
> ROBのことを書いたすけど。
>
> OoOEで消費電力や回路規模の問題が。。。という話の中でRSが出てくると思い込む妄想脳にわ
> あきれ果てるばかりす(笑)
これが、「私の立場わ『ROBもRSも含めた命令管理のためのキュー／ バッファをまとめて述べた』」と、どう整合するすか。
208:Socket774
08/03/09 18:23:55 MY0Y+OtV
URLﾘﾝｸ(microboy.seesaa.net)
VIA Isaiah Architecture 1
この続き早く書いてください
209:MACオタ＞妄想のヒト
08/03/09 18:32:18 lSXgkkSe
>>206
------------------
なぜなら、ROBエントリの確保わ演算パイプラインの一部でわないので、
こんなところがネックになってパイプラインを止めるのわ馬鹿げているからす。
------------------
でわ、実際の実装例を示すす。
URLﾘﾝｸ(www.research.ibm.com)
===================
As an example, if one thread encounters multiple L2 cache misses, dependent instructions can back
up in the issue queues. This can inhibit the dispatching of additional groups, causing the second thread
to slow down. Resource-balancing logic detects the point at which a thread reaches a threshold of load
misses in the L2 cache and translation misses in the TLB. When this happens, thread performance is
throttled. Similarly, resource-balancing logic monitors the GCT to determine the number of entries each
thread is using. If the balancing logic detects that one thread is beginning to use too many GCT entries,
potentially blocking the other thread, it throttles back the thread that is using excessive GCT entries.
===================
実際に問題視されていて対策の実装例があるのに、『絶対ない』に『馬鹿げている』すか(笑)
>>207
『ディスパッチされてからリタイアするまでリタイアするまで空かないキューわRSとROBのどちらか？』という
質問に,ROBだと答えたまですけど？(>>85-87参照)
210:Socket774
08/03/09 19:18:38 MY0Y+OtV
URLﾘﾝｸ(microboy.seesaa.net)
VIA Isaiah Architecture 2
つづきサンクス
211:MACオタ
08/03/09 19:39:31 H29jm950
>>209
GCTがROBだということを、ようやく理解してくれたようでうれしいす(笑)
前スレ
877 名前： MACオタ＞875 さん [sage] 投稿日： 2008/02/01(金) 01:07:39 ID:JA4OoS/6
>>875
語るに落ちると言うか何と言うべきか。。。
-------------------
二番目のPOWER5は、Global completion tableというのがROBそのものだよ。
IBMの好きな独自用語だね。
-------------------
URLﾘﾝｸ(www.research.ibm.com)
===================
An entry is de-allocated from the GCT when the group is committed.
===================
"commit"がどの段階か理解できないのが心配になってきたので、この図もつけておくす(笑)
URLﾘﾝｸ(www.research.ibm.com)
212:MACオタ
08/03/09 19:44:14 H29jm950
>>209
> If the balancing logic detects that one thread is beginning to use too many GCT entries,
> potentially blocking the other thread, it throttles back the thread that is using excessive GCT entries.
これのどこが、
>>206
> いずれにしろ、どんなプロセッサでも物理レジスタに対して十分なエントリ数をもつROBを備えているす。
> なぜなら、ROBエントリの確保わ演算パイプラインの一部でわないので、
> こんなところがネックになってパイプラインを止めるのわ馬鹿げているからす。
「物理レジスタに空きがないので」パイプラインを止めることの対策なのか、説明して欲しいす。
わたしにわ、SMTのロードバランシング機構にしか見えないすけどね。
213:MACオタ
08/03/09 19:59:34 H29jm950
>>207
『ディスパッチされてからリタイアするまでリタイアするまで空かないキューわRSとROBのどちらか？』という
質問に,ROBだと答えたまですけど？(>>85-87参照)
ということわ、
前スレ865
> ディスパッチされてからリタイアするまでキュー以外の何処にいるすかね。。。あなたの脳内にでも
> テレポートしてくるすか(笑)
> 強調しておくすけど「リタイアするまで」OoOの命令キューから取り除かれることわないす。
これのキューわ、ROBでいいんすか？
214:MACオタ
08/03/09 21:20:42 H29jm950
>>209
> Similarly, resource-balancing logic monitors the GCT to determine the number of entries each
> thread is using. If the balancing logic detects that one thread is beginning to use too many GCT entries,
> potentially blocking the other thread, it throttles back the thread that is using excessive GCT entries.
一応、日本語で要約しておくと、
(2way SMTのPOWER5において)、一方のスレッドがGCTエントリを大量に占有するようなことがあると、
他方のスレッドをブロックしてしまうことがあるので、
負荷分散機構がGCTエントリを占有しているスレッドを止めてしまう、ということ。
SMTにおいて負荷分散のために「一方の」スレッドが止められてしまうだけの話で、
他方のスレッドわ動いたまます。
つまり、全体としてわパイプラインわ動いたままで、ROBエントリ不足でパイプラインが停止するようなことわないす。
215:MACオタ
08/03/09 21:30:14 H29jm950
素直に、シングルスレッドCPUでROBエントリ不足が原因でパイプラインが止まるような実装を探してくればいいと思うすが、
もちろんそんなものは見つかるはずもないので、
苦しまぎれにSMTの例を持ち出してきたに相違ないす。
もっともMACオタは結局のところ何も理解していないので、トンチンカンすぎて反論にもなっていないわけすが(笑)
216:Socket774
08/03/10 01:04:55 LDD2ACQC
>>192
補足です。過不足なく書くのは難しい。
物理レジスタはインオーダーに確保され、命令のリタイア時にインオーダーに解放されます。
ROBエントリも同様にインオーダーに確保され、インオーダーに解放されます。
実装を簡易化するため、物理レジスタとROBエントリを一対一で対応させることが多いのですが、
必ずしもそうだとは限りません。
Isaiahのように、ROBエントリが複数のuopを持つようなプロセッサでは、
ROBエントリが複数の物理レジスタに対応することになります。
ROBエントリの確保は、主パイプラインステージ上にはありません。
命令のデコード後であれば、とくに依存関係もなくROBエントリの確保をすることができます。
ROB自体は大きなユニットですが、クリティカルパス上にあるわけではないで、
ここが性能上のネックになることは(あまり)ありません。
217:MACオタ
08/03/10 02:06:28 LDD2ACQC
>>203
> ここで重要な点わ、以下の全ての条件が満たされない限りROBへの登録の前で止まることす。
> ・ROBの空き
> ・リネームレジスタの空き
> ・RSの空き
ROBわインフライトな命令をすべて抱える構造体す。
RSわインフライトな命令の一部のみを保持する構造体す。
したがって、RSに空きがあるのにROBに空きがないような状況わありえないす。
つまり
> ・RSの空き
この条件わナンセンスす。
出来るものなら、反例、つまりRSサイズのほうがROBサイズより大きい実例を探してくればいいす。
同じく、ROBよりも物理レジスタのほうがクリティカルなリソースす。
物理レジスタわ、主パイプライン上にのっかっている性能的にクリティカルなリソースす。
物理レジスタに空きがあるのに、主パイプラインから外れたところにあって性能的に余裕のあるROBが満杯になったがために
主パイプラインが止まるようなアフォな設計をするやつわいないす。
ROBサイズと物理レジスタサイズが同じであるような実装わ存在するすが、
そういうCPUでわ、
ROBが満杯==物理レジスタが満杯
なので、結局
> ・ROBの空き
この条件もナンセンスす。
出来るものなら、反例、つまり物理レジスタに空きがあるのにROBが満杯のためにパイプラインが止まるような実例を探してくればいいす。
>>209わ、ロードバランサーがスレッドを止めるSMT固有の実装で、全然関係ない話す。
218:MACオタ
08/03/10 02:16:54 LDD2ACQC
そもそも>>209の引用部にわ、物理レジスタのブの字もでてこないす。
> ------------------
> なぜなら、ROBエントリの確保わ演算パイプラインの一部でわないので、
> こんなところがネックになってパイプラインを止めるのわ馬鹿げているからす。
> ------------------
MACオタわ、意図的に最初の行を削って引用したぽいすが、
もとの書き込みはこうす。
> いずれにしろ、どんなプロセッサでも物理レジスタに対して十分なエントリ数をもつROBを備えているす。
> なぜなら、ROBエントリの確保わ演算パイプラインの一部でわないので、
> こんなところがネックになってパイプラインを止めるのわ馬鹿げているからす。
MACオタわ、よくこういう話のそらし方をするすが、いいかげんにして欲しいものす。
219:MACオタ
08/03/10 02:18:36 LDD2ACQC
ところで、ROBわx86用語というのわ、まだ訂正しないすか。
前スレ
869 名前： MACオタ＞868 さん [sage] 投稿日： 2008/01/31(木) 23:47:00 ID:0C6GGRXK
>>868
---------------
リオーダバッファは何のためにあると思ってるんだよ。
---------------
ROBわx86用語なんすけど。。。
OoOを実装したRISCのブロック図でも見て用語を確認することをお勧めするす。
220:MACオタ
08/03/10 02:32:10 LDD2ACQC
>>212
> 「物理レジスタに空きがないので」パイプラインを止めることの対策なのか、説明して欲しいす。
「物理レジスタに空きがあるのに」の間違いす。
221:MACオタ
08/03/10 02:41:11 LDD2ACQC
>>217
> ROBが満杯==物理レジスタが満杯
> なので、結局
> > ・ROBの空き
> この条件もナンセンスす。
訂正す。
ナンセンスな条件わ
> ・リネームレジスタの空き
こちらのほうす。
222:Socket774
08/03/10 03:02:53 ApV6NyrU
ﾜﾛｽ。こうやって見るとｵﾀ言葉も面白れーな。
とっても勉強になるす。＞ 偽MACｵﾀ ｗ
223:MACオタ
08/03/10 03:09:59 LDD2ACQC
>>217
補足す。
>>203
> ここで重要な点わ、以下の全ての条件が満たされない限りROBへの登録の前で止まることす。
> ・ROBの空き
> ・リネームレジスタの空き
> ・RSの空き
必要な物理レジスタが確保できない場合にわ、主パイプラインわそこで止まるす。
物理レジスタを必要としない命令の場合わ、物理レジスタに空きがなくても止める必要わないす。
ROBエントリの確保わ、主パイプラインと平行して行われるす。
レジスタリネームとROBエントリの確保にわ依存関係がないすから、
物理レジスタが確保できない場合でも、ROBエントリを確保した「後」で止まるような実装もありえるす。
224:Socket774
08/03/10 03:29:34 1jT1hkTg
うぜーよ
普通の日本語で要約して書け
なにふざけてんだガキが
225:Socket774
08/03/10 03:33:52 1jT1hkTg
どいう場合にそれが性能向上に寄与があるか
書いて見ろよ
226:Socket774
08/03/10 03:37:58 1jT1hkTg
ゴチャゴチャやっても単体性能は頭打ち
227:MACオタ
08/03/10 03:39:40 LDD2ACQC
他人を罵ってもいいことわ一つもないす(笑)
228:Socket774
08/03/10 03:42:23 1jT1hkTg
2chに粘着しててもいいことは一つもない罠
あばよ
229:Socket774
08/03/10 03:48:53 nILofm3E
（ ﾟдﾟ）ﾎﾟｶｰﾝ… ＞ 1jT1hkTg
230:Socket774
08/03/10 06:30:06 1+kOv0MB
別コアのレジスタ参照出来るようになったら
アーキテクチャの系統樹は互換性の失われた新しい枝になるね。
231:Socket774
08/03/10 08:49:39 LDD2ACQC
>>230
TILE64というマルチコアプロセッサがそんな感じです。
ただし同期の問題があるので、送信側コアが受信側コアの特殊レジスタに直接書き込む形になりますが。
232:Socket774
08/03/10 09:29:14 LDD2ACQC
ちなみにTILE64は、1970年代のMITスタティックデータフローに始まる長い系譜の末裔です。
233:Socket774
08/03/10 12:22:25 92YWVTYz
ID抽出してみる限り、 ID:lSXgkkSeよりはID:LDD2ACQC/ID:H29jm950のほうが
ただしげなことをいっているように見えるな。
234:Socket774
08/03/10 18:02:14 KOIlyuCa
しかしin-orderのSMTって相方のスレッドがメインメモリ待ちに入ったところで
その分のリソース使って並列実行できるわけでもないのに
何がおいしいのかさっぱりわかんない
235:Socket774
08/03/10 19:12:42 LDD2ACQC
>>234
一般的には演算器数>>シングルスレッドIPCなので、インオーダーでも他スレッドから命令を供給するのは意味があります。
236:MACオタ
08/03/11 08:05:33 pjF7vJ+t
ハイエンドPOWER6サーバーがSysem iのユーザーグループ会議COMMONに合わせて、来月頭にも発表とのことす。
URLﾘﾝｸ(www.itjungle.com)
---------------------
So here are the two news items. First, the high-end of the Power6 server line, presumably to still be
called the System p 590 and 595 and the System i 595, are being launched at the beginning of April.
---------------------
当然従来通りMCM版を搭載していると予想されるす。>>121にz6 MCMのせいで遅れたとか書いたすけど、
開発わ同時進行だった模様す。
237:MACオタ
08/03/11 15:37:50 Zash/Icg
丸一日たっても反論なしすか。
ついに、屁理屈をこねて言い逃れすることもできなくなったようすね(笑)
238:Socket774
08/03/11 16:02:51 5GooBwMw
ググってるところだからもうちょい待て
239:MACオタ
08/03/11 16:24:37 Zash/Icg
前スレ869
> ROBわx86用語なんすけど。。。
ググるのにも疲れたか頃かと思うので、とりあえずこれわ正しいのか誤りなのか答えて欲しいす。
こんなものに即答できないようでわ、MACオタわCPUアーキテクチャについて何も理解していないと言わざるを得ないす。
もちろん誤答も言わずもがなす。
240:Socket774
08/03/11 16:43:50 Zash/Icg
レジスタわ、x86用語ですか
RSわ、x86用語ですか
キャッシュわ、どうですか
教えてください(笑)
241:MACオタ
08/03/11 16:58:01 Zash/Icg
>>209
のような例を持ち出すところをみると、
もしかしてMACオタわ、POWER5のGlobal Completion TableわROB相当品だと認めたすか？
認めたのなら、↓を撤回して謝罪して欲しいすね(笑)
あるいわ、あくまでGCTわROBでわないと主張するすか？
前スレ
877 名前： MACオタ＞875 さん [sage] 投稿日： 2008/02/01(金) 01:07:39 ID:JA4OoS/6
>>875
語るに落ちると言うか何と言うべきか。。。
-------------------
二番目のPOWER5は、Global completion tableというのがROBそのものだよ。
IBMの好きな独自用語だね。
-------------------
URLﾘﾝｸ(www.research.ibm.com)
===================
An entry is de-allocated from the GCT when the group is committed.
===================
"commit"がどの段階か理解できないのが心配になってきたので、この図もつけておくす(笑)
URLﾘﾝｸ(www.research.ibm.com)
242:MACオタ
08/03/11 17:04:29 Zash/Icg
>>241
これも即答できる筈すね。
自らの投稿の意図についてyes/noの質問をされて即答できないようでわ、
やはりMACオタわ何も理解せずに書きちらしていたことの証左になるす。
243:MACオタ
08/03/11 17:37:03 Zash/Icg
前スレ885
> 更に命令の流れの上で「ROB -> RS」となっているすから、ROBが長レイテンシの命令で詰まれば、
> RSに命令供給することすらできないす。
> この辺の事情と対策わ、先のPOWER5論文の"Dynamic Resource Balancing"の節でも述べられているす。
命令の流れが「ROB->RS」となっているのを、先のPOWER5論文に即して解説してください(笑)
URLﾘﾝｸ(www.research.ibm.com)
この図もつけておくすので、参考にしてください(笑)
URLﾘﾝｸ(www.research.ibm.com)
244:MACオタ
08/03/11 17:44:04 Zash/Icg
わたしにわ、"Group formation, instruction decode, dispatch"からGlobal completion table(=ROB)に流れていて、
GCTとShared issue queues(=RS)の間にわ、何の流れも見えないすね。
GCTとShared register mappers間にも、何の流れも見えないす。
「ROB->RS」の命令の流れわ、どこから来たんすかね。
やはりMACオタの脳内フローすか。
245:MACオタ
08/03/11 17:51:47 Zash/Icg
それとももしかしてMACオタわ、
IBMが、あえて「Global completion table」と書いたのわ、ROBもRSも含めた命令管理のためのキュー／ バッファをまとめて述べたからす。
とでも主張するすかね(笑)
246:MACオタ
08/03/11 19:34:46 Zash/Icg
MACオタわ、少なくとも2000年からCPU関係のスレに常駐していたわけすが、
8年たってもこの程度というかまるっきり何も理解していないことにわ、恐怖すら覚えるす。
当時の小学生ももう大学生になる頃すが、間違った知識を植えつけられたまま育っていないことを心から祈るす。
247:MACオタ
08/03/11 21:41:52 Zash/Icg
>>21は朝
>>25は昼
>>11は夕方
>>121は夜
>>18は深夜
>>49は未明
と、ざっと見ただけでも、丸一日このスレに張り付いている様子が伺えるす。
夜の書き込みが少なめなのわ、ググるのに忙殺されているからすかね。
とりあえず、即答できる簡単な質問を二つ出しといたので、早く答えて欲しいす。
答えられなくてバックレているなんてことはないと思うすが。
248:どうていだいまおう
08/03/11 21:43:03 6LaD4XAx
昔とくらべるとMacヲタもくわしくなったよ
249:どうていだいまおう
08/03/11 21:55:11 6LaD4XAx
生まれて初めて買った月刊アスキーのPentium特集は
すごくわかりやすいOoOの説明をやってた
250:MACオタ
08/03/12 00:26:38 SEi8tyfB
>>247
バックレないように念を押しとくす。
MACオタが即答できるはずの簡単な二つの質問わ以下の通りす。
・ROBはx86用語か否か？
・POWER5のGCTはROB相当か否か？
CPUアーキテクチャについてそれなりに理解している人間なら、正解を即答できるす。
わたしが上のほうで正解を書いたので、それを拾ってきてくれてもかまわないす。
251:MACオタ
08/03/12 00:30:12 SEi8tyfB
>>250
現時点では、MACオタわ、「ROBわx86用語なんすけど」と主張しているす。
前スレ
869 名前： MACオタ＞868 さん [sage] 投稿日： 2008/01/31(木) 23:47:00 ID:0C6GGRXK
>>868
---------------
リオーダバッファは何のためにあると思ってるんだよ。
---------------
ROBわx86用語なんすけど。。。
OoOを実装したRISCのブロック図でも見て用語を確認することをお勧めするす。
252:MACオタ
08/03/12 00:34:25 SEi8tyfB
>>250
現時点でわ、MACオタわ、「POWER5のGCTはROB相当である」という意見を否定してるす。
前スレ
877 名前： MACオタ＞875 さん [sage] 投稿日： 2008/02/01(金) 01:07:39 ID:JA4OoS/6
>>875
語るに落ちると言うか何と言うべきか。。。
-------------------
二番目のPOWER5は、Global completion tableというのがROBそのものだよ。
IBMの好きな独自用語だね。
-------------------
URLﾘﾝｸ(www.research.ibm.com)
===================
An entry is de-allocated from the GCT when the group is committed.
===================
"commit"がどの段階か理解できないのが心配になってきたので、この図もつけておくす(笑)
URLﾘﾝｸ(www.research.ibm.com)
253:MACオタ
08/03/12 00:39:57 SEi8tyfB
>>250
かようにMACオタわ、一度わ以下の二つの質問の答えを述べているのだから、(>>251と>>252)
今さらググったりしなくても、すぐに同じ答えをもう一度書けばすむす。
> ・ROBはx86用語か否か？
> ・POWER5のGCTはROB相当か否か？
254:MACオタ
08/03/12 01:00:13 SEi8tyfB
MACオタわ自分の主張をもう一度繰替えせばすむだけのことす。
それすらできないのわ、自分を無知や無理解をつきつけられて身動きがとれなくなったからすかね？
255:MACオタ
08/03/12 01:02:06 SEi8tyfB
答えられないのわ、イエスノーで質問されたので、必死でググって探しだしてきた記事で話をそらすことすらできないからすね？
256:MACオタ
08/03/12 01:06:50 SEi8tyfB
「ROBわx86用語なんすけど」「GCTがROBとわ語るに落ると言うか何と言うべきか」
と言えないのわ、言ってしまえば恥の上塗りになることがわかっているからすか？
「ROBわx86用語でわないす」「GCTわROB相当す」
と言えないのわ、自分の誤りを認めることになるからすか？
ググった記事で質問をそらせないのわ、イエスノーで尋ねられたからすか？
257:MACオタ
08/03/12 01:11:57 SEi8tyfB
イエスと答えても、ノーと答えても、質問をそらしても恥をかく、
それ以外に、MACオタさん、あなたが黙っている理由わあるんすか？
258:Socket774
08/03/12 01:13:19 ONkczARM
連レスせずに一つにまとめろ。長すぎるなら分けてもいいけど無意味に分けるな。
259:Socket774
08/03/12 01:14:39 fKgIJCVM
必死でググってるから
ちょっと待ってあげて下さい
260:MACオタ
08/03/12 01:28:19 SEi8tyfB
わたしの質問わ、答えるまでもないくだらない質問でわないすよ。
「ROBはx86用語か？」というのわ、決してトリビアでわないす。
間違って覚えると、「レジスタはx86用語である」「キャッシュはx86用語である」と言ったときと同じような恥をかくす。
POWER5のGCTわ、ブロック図にも載っていてそれなりの量の解説もついている重要なユニットす。
POWER5のアーキテクチャを理解するためにわ、GCTが他のプロセッサのどの部分に相当するのか、
どうしても正しく答えられなければならないす。
>>258
IDがARM
>>259
MACオタが間違いを訂正するまでわ死なないす。
261:Socket774
08/03/12 01:41:31 TbOU0m0v
ID:SEi8tyfB
GJ!
262:Socket774
08/03/12 02:06:55 z2LKrPUY
このスレ終わった
263:Socket774
08/03/12 02:59:48 obVLZn4j
バカが二人に増えやがった…
おっとダンゴも入れて三人か。
もう、うんざり
264:MACオタ
08/03/12 03:28:18 SEi8tyfB
人を罵ってもいいことわ一つもないす。
265:Socket774
08/03/12 03:33:24 sAfUR4oV
AMD次世代スレには現れたみたいだがこっちには来ないようだ。
266:Socket774
08/03/12 04:12:43 eJTBluH0
よそでやれよクズ共
267:MACオタ
08/03/12 08:25:23 SEi8tyfB
人を罵ってもいいことわ一つもないす。
スレタイに忠実に行動しているので、よそでやるわけにわいかないす。
268:Socket774
08/03/12 10:40:17 axaGRY6e
NGしやすいように行動してるようだし、ここでやっててくれ
269:Socket774
08/03/12 10:48:03 bro9h7lz
ここでオナニーすんな
blogでも作ってそん中でやれや
270:Socket774
08/03/12 13:35:46 pBlNIhsw
目的が正しければ、正論であれば、悪人を懲らしめるためであれば、
どんな手段を採っても許される。というわけではないよ。
ID:SEi8tyfBがやっていることは、どんな正当性があって内容が正しかろうが、
結局のところ荒しだよ。荒しはスルーか削除依頼で。
271:Socket774
08/03/12 14:51:29 TbOU0m0v
俺は ID:SEi8tyfB は必ずしも荒らしとは思わない。
元々ＭＡＣオタが常に不必要に人を馬鹿にした口調で書いてるのが悪い。
ただ、何レスにも渡って同じことを繰り返さず、簡潔にはすべき。
272:Socket774
08/03/12 14:56:00 xMxQkgIa
確かに本MACオタも偽MACオタも荒らしなのは事実だがw
本MACオタの禅問答&ソースコピへ情報は文章が下手ですぐに枝葉末節に逃げ込み過ぎて
何が言いたいかわからないのばかりだったけど、偽MACオタの書き込みは読んでて解りやすいw
偽MACオタはもう本MACオタの方なんか放置して普通にCPUについて語ってくれないかな。
273:Socket774
08/03/12 15:37:40 KrRG2kaq
どちらも死んで、普通に話のできる人間だけ集まればよいのに。
274:Socket774
08/03/12 17:16:56 SEi8tyfB
そもそもの発端となったIssaiahだけど
URLﾘﾝｸ(www.extremetech.com)
ブロック図の解説をしてみる。
だいたい見ての通りだけど、補足が必要そうなのは
・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
08/03/12 18:05:56 SEi8tyfB
Isaiahでは、micro-op(s)と呼ばれるものは
executable micro-op そのまま実行ユニットで実行できるもの
fused micro-ops 0から3命令のexecutable micro-opsをfuseしたもの
と二種類あるので、たんに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
08/03/12 18:07:50 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
08/03/12 18:14:07 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
08/03/12 18:45:27 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オタ
08/03/12 23:03:47 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-opsがx86命令にそれぞれ対応するという記述わ「一切」無いすけど。。。
フュージョンして扱える条件わ、もっと限定されたモノなのでわ？
このように書く理由わ、下記の問いに対する説明にもなるかと思うす。
-------------------
早め、というのが何を言っているのかわからんが、ディスパッチステージより前ということか？
どういう意味があるんだ？
-------------------
端的にわ、そもそもRISCの設計がそのように最適化されているす。
OoO用の命令キューというモノわ、なるべく沢山の命令を放り込んで同時実行可能な組み合わせを
検索できることに意味があるす。ところが命令ごとに実行レイテンシわ異なるので、混在させると時間
のかかるロード／ストアや浮動小数点命令ばかりがキューに居座ることいなるす。
早めに命令を分類することわ、効率の向上に繋がるすよ。
更に現代のプロセッサでわ、細粒度の電力管理のために各命令が使用するリソースを早めに確定
して電力管理のスケジュールを立てることも重要す。
280:Socket774
08/03/13 02:18:04 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
08/03/13 02:19:09 VO25v4Yv
ところで、こんな記述もあるすね。
URLﾘﾝｸ(pc.watch.impress.co.jp)
> 知られているように、Fusion(融合)と呼んでいるのは、複数のRISC風uOPsを1個のuOPsに融合させるという概念からだ。
> だから、Core MAでの、複合uOPsは「Fused uOPs」と呼ばれている。しかし、実態は、比較的単純なCISC型x86命令を、1対1でFused uOPsに変換しているに過ぎない。
> つまり、CISC命令を分解しないことがMicro-OPs Fusionの本質だ。
「比較的単純なCISC型x86命令を、1対1でFused uOPsに変換しているに過ぎない。」
Core MAでもそうなんすね(笑)
282:Socket774
08/03/13 16:44:24 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周辺の実装を
理解していたので勝ちと言うことにしよう。
283:Socket774
08/03/13 16:55:47 vo3HrKRv
>>282
おっと、マイクロコード命令は3つのfused uopsでしたね。
しかも24000命令もある。
もっともROMはクリティカルリソースではないと思います。
昔からマイクロ命令はスカスカででかかったし。
284:Socket774
08/03/13 16:58:20 Ms5JHxpt
WinChipC6まんせー。
200MHz定格動作なのに昇圧、倍率変換下駄無しで240MHz駆動で安定しているんだぜ。
冷却ファンも元のSANYOでそのままだと熱暴走したっぽいけどグリス塗りなおしたら超安定！
こりゃ、Intelの非MMXODPいらんよ。第一150MHz(あれ？180MHzだったかな？)とまりなんて魅力ないし。
あ、元のマシンはPentium90MHzでベースクロックの変更も難しいPC-9821An。
メモリアクセスが激遅だけどCPUでごまかしている。
あれ？肝心のアーキテクチャはよく知らんや。すまん。
285:Socket774
08/03/13 22:48:05 o9/X92P/
本物はすっかり逃げ出したのかな？
ほとぼり冷めるまでこないつもりか。
286:Socket774
08/03/14 01:43:06 E+MP1PoW
面白い事言うなぁ…
ぶっちゃけどっちも"本物"だろ。
一生懸命の方には悪いが、一度リアルに精神鑑定してもらった方が良いと思われ。
287:Socket774
08/03/14 02:18:46 gCsheBix
人格はともかく書いている内容はどうか
だけで見るしかないな、掲示板のﾚｽは。
ﾚｽを書くﾔｼの労力は消耗品だから。ﾎﾞｿ
288:Socket774
08/03/14 04:04:50 P7fagJMP
無駄に元文引用を駆使する奴って大抵文書構成力が一般より劣っていて
Mailの返信等で顕著に被害を被るんだが読んでて見苦しいんだよ
289:MACオタ
08/03/14 09:05:52 9073HDjT
内容に文句がつけられないからといって、人格攻撃に走るのわどうかと思うす。
290:MACオタ
08/03/14 09:14:56 9073HDjT
おつむの弱い人が
前スレ904
> 例の脳内妄想のヒトだったすか(笑)
> ご自分の主張をソースをつけて判りやすく説明できるようになったら、お相手させていただくす。
とうるさいので、引用過剰になってしまったす。
291:Socket774
08/03/14 12:45:38 vtbB8uGB
>>288
同意。
292:MACオタ
08/03/14 16:46:12 9073HDjT
一体あなたがたわ何のためにわたしを挑発して召喚するすかね。
「もう出てくるな」と呼び出してるんすか？
理解に苦しむす。
293:MACオタ
08/03/14 16:49:57 9073HDjT
>>288
>>291
こんなことを書かれると、自己弁護せざるを得ないす。
前スレを見ればわかるように、もともとわたしわ引用わあまりしない文体だったすよ。
スレの趣旨から外れるような投稿わなるべく控えて欲しいす、と言っていいすか？(笑)
294:Socket774
08/03/14 20:26:58 6rwTJbZJ
連投以外は概ね問題ない。技術的正当性があるのだから
些細なことに反応せず鷹揚に構えてればいい。
ハンドルをMACオタにしているのはNG指定の面で良いが
MACオタ口調は率直にキモい。
295:Socket774
08/03/14 23:15:29 nMNacj8S
これはあれだ、二代目MACオタということだな。
初代は引退ということで。
296:Socket774
08/03/15 00:07:36 3vkLP90G
襲名の瞬間を目撃してるわけかｗ
297:Socket774
08/03/15 01:03:45 pY01e/6O
ﾜﾛｽｗ
いや初代より、もうチョい技術に明るいカモよ
がしかしもうちょい粘着質の人格障害かもよｗ
いずれにせよﾜﾛﾀ。完全にネタｽﾚ化したな
298:Socket774
08/03/15 01:08:58 cwVOEncT
ゴキブリをアシダカグモが駆除したような感覚
299:Socket774
08/03/15 01:17:32 C1abkQj+
なんという絶妙な表現。
300:Socket774
08/03/15 20:23:55 u0wVzvoR
>>294
概ね問題なしといいつつ最後にキモいなんて、きついこといいますねｗ
301:Socket774
08/03/15 23:42:02 TiqzmaT2
別にキツくないだろ
どうせキモいという自覚すら持てず「これは自分のキャラすから」とか強弁し続けるだけだろうし
302:MACオタ
08/03/15 23:43:41 Eyxtk4rd
荒らしの皆さん、スレの趣旨から外れる投稿わ「MACオタ」のコテでお願いするす。
303:MACオタ
08/03/15 23:47:50 8cXVsqlk
昔のmac板みたいだな。
みんなMACオタで書き込もうキャンペーン実施中。
304:MACオタ
08/03/16 01:40:07 uj4/GBWM
了解
305:Socket774
08/03/16 04:01:03 rq5Xt5if
「MACオタ」のコテでカキコする場合は MACオタ語 (～わ、～す) でお願いするす。
306:Socket774
08/03/16 15:51:17 u7sby0tU
よそでやれ
307:MACオタ
08/03/16 19:17:30 sdsGm9Ip
MACオタは共有コテハンだということを知らなかったすか。
これだから低学歴な人たちわ理解に苦しむす。
308:MACオタ
08/03/16 23:41:58 x9G7mlh0
>>305
まごにわやさしい
URLﾘﾝｸ(railf.jp)
309:Socket774
08/03/17 19:08:51 8/49Vvyd
役に立つ情報が無いんですが・・・？
310:Socket774
08/03/17 21:21:07 jpYI9Obn
MACオタの知識はトリビアの泉ですw
311:MACオタ
08/03/17 21:27:57 fxzpMqR2
OoO実行を最初に実装したマシン、360/91は、非常に高価だったことと、アーキテクチャ状態のサポートがなく互換性を欠いていたため、ちっとも売れなかった
312:Socket774
08/03/18 00:24:51 oVZrn41S
ちょっと興味を惹く無駄知識ってか
313:Socket774
08/03/18 00:34:52 5h44yPIA
Nehalemスレには出没した気配なのにこっちには来ず、か。
314:MACオタ
08/03/18 01:53:47 wYtpruHj
先日インテル入りしたTransmetaの旧ボスDavid R. Ditzelは、
かつてOS、言語からエディタまですべてハード化した究極のCISCマシン、SYMBOLプロジェクトに参加していた。
その後師匠のDavid A. Pattersonと共に深く反省し、SPARCプロジェクトを立ち上げた。
315:ヽ・´∀｀・,,）っ━━━━━━┓
08/03/18 02:22:43 Uja+Iq/H
おお、ディツェルが入ってようやくPARROTが動き出すのか。
316:Socket774
08/03/18 14:27:14 rJAfEmOL
NECと東工大、面発光レーザーを用いた20Tbpsクラスの光接続技術
URLﾘﾝｸ(pc.watch.impress.co.jp)
317:Socket774
08/03/18 15:02:21 zRqFE8yL
昨日IBMの似たような記事あったけど華麗にスルー？
318:Socket774
08/03/18 15:09:03 5h44yPIA
IBMはまだ要素技術。
NECのは京速計算機には使われるだろうな。
319:Socket774
08/03/19 05:56:42 xhgfyvgL
史上最も奇妙なアーキテクチャといわれるRekursivを開発したのは、有名な高級オーディオメーカーのLINNであった。
320:Socket774
08/03/19 13:19:08 1rdUG9T0
MicrosoftとIntel、コンシューマ向け並列コンピューティング研究所を設立
URLﾘﾝｸ(pc.watch.impress.co.jp)
321:Socket774
08/03/19 19:23:42 xhgfyvgL
へぇとかフーンとかアッソとか言ってくれよ
322:Socket774
08/03/19 22:19:27 aPYcnbfr
へぇ
323:Socket774
08/03/19 22:35:08 7UfRKTZX
フーン
324:Socket774
08/03/19 22:41:42 9y8WnOif
アッソ
325:MACオタ
08/03/19 22:53:38 qW6DaiHr
複雑なアドレッシングモードやレジスタ-メモリ間演算命令などCISCらしい特徴を持つZ8000は、
マイクロコードを使わずハードワイヤードロジックで実装されていた
326:MACオタ
08/03/21 22:42:17 wrZchGRS
なんかリクエストある？
327:Socket774
08/03/22 02:59:44 nMJCD8LJ
Nehalemはつまらん
328:Socket774
08/03/22 07:23:58 Pbkvpv2H
>>326
Isaiahについて解説してくれ
329:Socket774
08/03/22 08:45:13 eHIXG+AG
トランスピューターはどうなったんだ？
330:MACオタ
08/03/22 20:08:24 9GP1BGwz
>>328
ここはトリビアの泉なので解説は不可
>>329
T9000が出荷されたのが最後
331:MACオタ
08/03/22 20:41:40 9GP1BGwz
トランスピュータは、CRCの計算を一命令で行うなど、非常に複雑な命令を持つCISCであった
332:MACオタ
08/03/22 23:49:04 9GP1BGwz
トランスピュータの命令セットの詳細もあるよ
URLﾘﾝｸ(www.transputer.net)
疑問点があれば解説ちまつ
333:MACオタ
08/03/22 23:49:45 9GP1BGwz
次は、世界最初のVLIWについての小話でいい？
334:Socket774
08/03/25 22:34:03 mzFKqImm
Sun、チップ技術の研究で4400万ドルの資金を獲得
URLﾘﾝｸ(www.itmedia.co.jp)
サン、高性能・低消費電力の光配線チップ開発を推進
近接チップ間をレーザーで結び「マクロチップ」を開発
URLﾘﾝｸ(www.computerworld.jp)
335:Socket774
08/03/30 04:28:57 xzCcTr1Z
【レポート】次世代スパコン開発の進捗状況
URLﾘﾝｸ(journal.mycom.co.jp)
336:Socket774
08/03/31 00:56:31 ni41qHis
627 名前：MACオタ＞626 さん[sage] 投稿日：2008/03/31(月) 00:35:01 ID:qfrBvVBg
>>626
ご本尊を奉ることで懸命な信者さん達にわ気の毒すけど、当人わ過去の解説を
適当にごまかすということす(笑)
書いている内容わ>>175のリンク先の単なる後追い。。。
-------------------------------
●QPIは、実はシリアルではない
-------------------------------
337:Socket774
08/04/01 19:40:35 hnPf1iFe
いいかげん、ゲハに帰ってくれないかな
ここは自作板なんだけど
338:Socket774
08/04/02 21:42:11 rkpE8FUW
URLﾘﾝｸ(softwareprojects.intel.com)
Intel? AVX (Intel? Advanced Vector Extensions) is a 256 bit instruction set extension
to SSE and is designed for applications that are floating point intensive.
339:Socket774
08/04/03 19:50:19 R6FUfA/H
MIPS社、4コア構成が可能な
プロセッサ・コア「1004K」を発表 (2008/04/02)
URLﾘﾝｸ(www.eetimes.jp)
340:Socket774
08/04/04 13:49:52 6f1bdEAp
Hynix社、Grandis社から
「STT-RAM」技術を導入へ (2008/04/02)
URLﾘﾝｸ(www.eetimes.jp)
「STT-RAM技術は、既存のMRAM技術の限界を超える次世代の不揮発性メモリー技術だ」
「STT-RAM技術は微細化に柔軟に対応できるスケーラビリティを備えている。このため
微細化を進めることで、ダイ当たりの素子密度を高めてコストを削減することが可能に
なる。さらに現在主流のメモリー・チップと比べて、消費電力が低く、耐久性が高く、
読み出し/書き込み速度が高い」
341:Socket774
08/04/04 21:11:37 zAXRbtzn
Silverthorneってさ実はPen4を省電力に改良しただけのCPUなんじゃねーの
342:Socket774
08/04/04 21:12:55 VyzW9JDZ
てけとーな事ぬかすな
343:Socket774
08/04/05 13:33:55 Cj5c67T+
春休みも明日までだから、それまで我慢我慢。
344:Socket774
08/04/05 22:03:24 9nvzG5mh
じゅぴたんの事も忘れないでください。
345:Socket774
08/04/06 22:43:58 Vh7evTTf
じゅぴたん？
346:Socket774
08/04/07 21:54:07 YtErmd1H
SPARC64 VI+のことか>じゅぴたん
347:Socket774
08/04/07 23:12:45 beiRI0g1
>>346
VII だがね
348:Socket774
08/04/08 13:25:43 NFW6gwm3
東芝、CellのSPEを搭載したストリーミングプロセッサ「SpursEngine」
URLﾘﾝｸ(pc.watch.impress.co.jp)
349:Socket774
08/04/08 14:15:34 b8pK6mU5
>>348
これってPC向けには微妙な位置づけだよね。
HD対応なGPUが今後主流になりつつ有るから、デコーダ機能が重複するし。
350:ヽ・´∀｀・,,）っ━━━━━━┓
08/04/08 14:21:01 HaA4JWsP
まずVista 64に対応してくれ
351:Socket774
08/04/08 14:36:44 uRpG6v1y
「廃物利用」なんだからもちっと勉強してよｗ
352:Socket774
08/04/08 16:49:10 2mRPoaDc
アップコンバータには良いと思う
REGZAに搭載されるのもこれかね
353:ヽ・´∀｀・,,）っ━━━━━━┓
08/04/08 17:22:15 HaA4JWsP
SDソースのアップスケールには当分需要がありそうだな