08/08/28 09:50:30 vX5clrui
テンプレが時代錯誤っぽかったんで勝手ながらアレンジしちゃいました。
元のやつ↓
---------------------------------------------------
おいお前らいい加減、無能なAMD房・Intel房・GKに振りまわされず、
エンコ時間がどうとかPIがどうとかPS3がどうとかじゃなく、
CPUコアのアーキテクチャについて語りましょう。
x86/RISC/CISC/スーパースカラ/VLIW/MIMD/SIMD
等について語ってもよし、
フリップフロップ回路が小さいPentium Mマンセー、
CISCなのに内部はRISCなPentium 4マンセー、
x86なのに32/64bitコンパチなOpteronマンセー、
昔々8086の時代は(以下略・・・等もよし。
さあ、不毛な争いを止めてCPUアーキテクチャについて語ろう！
---------------------------------------------------
3:,,・´∀｀・,,
08/08/28 09:53:25 vX5clrui
つか「Cell B.E.」って書こうとしたら間違えたし
4:Socket774
08/08/28 12:48:00 Xw90vCMb
12スレ目にもなると流石に飽ーきてくっちゃ、ダーリン
5:Socket774
08/08/29 01:45:30 Yk6PbdtE
これもテンプレにしたほうがいいな
--
fenceってのは、ストア1が完了したことを別のストア(ストア2)で他のプロ
セッサお知らせしたりするようなときに二つのストアの間に置くものだよ。
このとき、、
つまり、ストア1とストア2のアドレスは別。他のプロセッサがロードによっ
てストア2への書き込みを知った後、ストア1の結果を読み取ろうとしたと
き、それがメモリシステムのごたごたによってまだ読めなかったりすると
困る。
そんなことが無いように保証するのがfenceの役割。
6:,,・´∀`・,,）っ-○●◎
08/08/29 01:46:22 XA+DpWi/
中途半端に完了させるのがフェンスの役割だろ。
いまさらまともなこというな
7:,,・´∀`・,,）っ-○●◎
08/08/29 01:47:29 XA+DpWi/
これもテンプレ追加で
595 名前：Socket774[sage] 投稿日：2008/08/25(月) 01:15:00 ID:O2J1PAxv
>>590
> メモリコンシステンシ遵守で走ってるときは1命令が完了するまで次の命令はフェッチできない。
どうしてそう性能を落したがるのかなあ
8:,,・´∀`・,,）っ-○●◎
08/08/29 01:51:11 XA+DpWi/
どうしてそう性能を落したがるのかなあ
どうしてそう性能を落したがるのかなあ
どうしてそう性能を落したがるのかなあ
どうしてそう性能を落したがるのかなあ
データに信頼がなくなるからです
9:Socket774
08/08/29 02:01:02 Yk6PbdtE
これもテンプレ
--
> フェンス命令をしないといけないのはアクセスするアドレスが重なるときだよ。やっぱり君は解ってないな。
これは「間違い」
10:,,・´∀`・,,）っ-○●◎
08/08/29 02:03:52 XA+DpWi/
488 名前：Socket774[sage] 投稿日：2008/08/24(日) 16:48:54 ID:dxY2QGlA
>>486
> HPC用に用意されるソケット版はXeonとプラットフォーム互換で、QPIで相互インターコネクトされる。
だからそれはLarrabeeじゃねえって何度も言ってるだろ
11:,,・´∀`・,,）っ-○●◎
08/08/29 02:04:42 XA+DpWi/
x64非互換な脳内Larrabeeの話はよそでどうぞ
完全準拠は確定してます。
12:,,・´∀`・,,）っ-○●◎
08/08/29 02:06:33 XA+DpWi/
488 名前：Socket774[sage] 投稿日：2008/08/24(日) 16:48:54 ID:dxY2QGlA
>>486
> HPC用に用意されるソケット版はXeonとプラットフォーム互換で、QPIで相互インターコネクトされる。
だからそれはLarrabeeじゃねえって何度も言ってるだろ
488 名前：Socket774[sage] 投稿日：2008/08/24(日) 16:48:54 ID:dxY2QGlA
>>486
> HPC用に用意されるソケット版はXeonとプラットフォーム互換で、QPIで相互インターコネクトされる。
だからそれはLarrabeeじゃねえって何度も言ってるだろ
488 名前：Socket774[sage] 投稿日：2008/08/24(日) 16:48:54 ID:dxY2QGlA
>>486
> HPC用に用意されるソケット版はXeonとプラットフォーム互換で、QPIで相互インターコネクトされる。
だからそれはLarrabeeじゃねえって何度も言ってるだろ
あーあ、このスレもフェンスに中途半端に完了させられるみたいだな。
13:Socket774
08/08/29 02:15:22 Yk6PbdtE
どうした団子、勇ましく>>5を否定したらどうだ
14:,,・´∀`・,,）っ-○●◎
08/08/29 02:16:20 XA+DpWi/
ところでさ、面白いもの見つけたんだがｗｗｗｗ
中途半端にフェンスに完了させられる（笑）ってのはこんなニーモニックの命令かね？
↓
vscatvps/vscatvpd/vpscatvb/vpscatvw/vpscatvd
ククククク
お前は死ぬよ。確実に。
15:,,・´∀`・,,）っ-○●◎
08/08/29 02:16:47 XA+DpWi/
>>13
否定しないよ。ようやく解ったようだね。
16:,,・´∀`・,,）っ-○●◎
08/08/29 02:17:56 XA+DpWi/
ただ、フェンス命令があってはならない理由って結局何なんだね？
何かわからないけど他に互換でない要因があるに違いない
と思い込みたい状態？
17:Socket774
08/08/29 02:19:06 Yk6PbdtE
んじゃ、これも否定してくれ
団子> フェンス命令をしないといけないのはアクセスするアドレスが重なるときだよ。やっぱり君は解ってないな。
18:,,・´∀`・,,）っ-○●◎
08/08/29 02:20:31 XA+DpWi/
488 名前：Socket774[sage] 投稿日：2008/08/24(日) 16:48:54 ID:dxY2QGlA
>>486
> HPC用に用意されるソケット版はXeonとプラットフォーム互換で、QPIで相互インターコネクトされる。
だからそれはLarrabeeじゃねえって何度も言ってるだろ
これ撤回するならな。
いい加減Larrabee＝EM64T準拠を認めてくれよ
19:,,・´∀`・,,）っ-○●◎
08/08/29 02:23:12 XA+DpWi/
>>17
で、スキャタ命令は、フェンス命令をせずにどうやってコンシステンシを守るんだい？
後続命令からのメモリ汚染をどうやって防ぐの？
君の仮想世界に存在する脳内Larrabeeの話はいいから
20:Socket774
08/08/29 02:23:18 Yk6PbdtE
>>18
やなこった
んで、まだ
団子> フェンス命令をしないといけないのはアクセスするアドレスが重なるときだよ。やっぱり君は解ってないな。
こんなアホみたいな主張を続けるのか
21:,,・´∀`・,,）っ-○●◎
08/08/29 02:24:16 XA+DpWi/
20 名前：Socket774[sage] 投稿日：2008/08/29(金) 02:23:18 ID:Yk6PbdtE
>>18
やなこった
現実から逃げるなｗｗｗｗ
22:,,・´∀`・,,）っ-○●◎
08/08/29 02:24:42 XA+DpWi/
>>20
撤回済みだけど前スレで
23:Socket774
08/08/29 02:25:54 Yk6PbdtE
これは認めてくれるのかなぁ？
826 名前： Socket774 [sage] 投稿日： 2008/08/27(水) 10:44:10 ID:qWNCgzHN
団子> フェンス命令をしないといけないのはアクセスするアドレスが重なるときだよ。やっぱり君は解ってないな。
メモリマップドI/Oで
a番地にデータを書きこみ、b番地へのライトでI/O開始
といった場合に
I/O開始時に、I/Oユニットがa番地のデータを正しく読めるよう
a番地へのライトとb番地へのライトの間にフェンス命令を挟むのが典型的な使い方の一つ
なので、アクセスする番地が重なるとは限らない
といったことを書いたはずだが…
24:Socket774
08/08/29 02:26:46 Yk6PbdtE
>>22
本当に撤回してたんならアンカー出してコピペしてくれよw
25:,,・´∀`・,,）っ-○●◎
08/08/29 02:26:53 XA+DpWi/
キャッシュライン管理の特性上、確実に汚されない組み合わせが存在するのも事実だよ
でも君が指定したあのアドレス指定だと普通セグメンテーションフォルトだからどのみちフェンスの必要がない。
絶対アドレス指定であれはありえない。
26:,,・´∀`・,,）っ-○●◎
08/08/29 02:27:51 XA+DpWi/
先生！ID:Yk6PbdtEはLarrabeeがEM64T準拠でないといってます。
27:Socket774
08/08/29 02:27:53 Yk6PbdtE
ついでにおれが最初から正しくフェンス命令の動作を理解していたのも認めるかね？
28:,,・´∀`・,,）っ-○●◎
08/08/29 02:28:11 XA+DpWi/
最初から誤解してた
29:,,・´∀`・,,）っ-○●◎
08/08/29 02:29:24 XA+DpWi/
理解してたらこんな馬鹿なことは書かない
＞ LarrabeeにはScatter/Gatherがあるだろ、
＞ 1命令で16要素のメモリアクセスするから、スレッド数にあわせて4段のパイプラインだと、
＞ 全部で64アクセスをバッファにためないといけない
＞
＞ それをSSE的にフェンスするとなると、下手すれば全スレッドが止まる
そしてこれ
488 名前：Socket774[sage] 投稿日：2008/08/24(日) 16:48:54 ID:dxY2QGlA
>>486
> HPC用に用意されるソケット版はXeonとプラットフォーム互換で、QPIで相互インターコネクトされる。
だからそれはLarrabeeじゃねえって何度も言ってるだろ
30:Socket774
08/08/29 02:29:46 Yk6PbdtE
団子はフェンスの動作を完全に誤解していたが、いまとけつつある？
おれは最初から完全に正しい動作を説明していた
これでOK?
31:Socket774
08/08/29 02:32:57 Yk6PbdtE
フェンスの動作を全く理解していなかったことを認めざるを得ない団子がファビョッて
なんの関係もないレスを、しかもコメントを何もつけられずにコピペするだけで
難局を乗り切ろうと足掻く様は愉快だな
32:,,・´∀`・,,）っ-○●◎
08/08/29 02:33:42 XA+DpWi/
SSEは厳しいモデルだと言ってた奴がフェンス命令の仕様を理解しているわけがない。
CPUIDにフェンスの効果があることすら知らなかったんだからな
33:,,・´∀`・,,）っ-○●◎
08/08/29 02:35:05 XA+DpWi/
CPUID命令って、CPUのバージョンやベンダー名、対応命令を取得するだけでなく
副作用としてフェンスする効果もある。
CPUIDからeax:edx:ecx:ebxを汚さず、フェンス機能のみを使うのが、*FENCE
*FENCEが動作に干渉する命令は当然CPUIDを使っても干渉する。
ID:Yk6PbdtEの主張
「CPUIDの場合はフェンスをスルーすればいい」
34:,,・´∀`・,,）っ-○●◎
08/08/29 02:39:11 XA+DpWi/
561 名前：Socket774[sage] 投稿日：2008/08/24(日) 23:19:19 ID:dxY2QGlA
>>552
CPUID等の直列化作用のほうをVPUには緩めると思う
が、直列化以外の意義のないフェンス命令はナンセンス
どうみてもフェンス理解してない人の発言
俺が指摘してから調べたんだろ
35:Socket774
08/08/29 02:39:39 Yk6PbdtE
868 名前： 728-729 [sage] 投稿日： 2008/08/27(水) 16:11:10 ID:54ZJgqnI
団子は団子で、教科書的知識に対する理解不足を晒しているところがある
というのを理解しなよ。
と指摘されて
972 名前： ,,・´∀｀・,, 投稿日： 2008/08/28(木) 23:13:49 ID:vX5clrui
(略)
ストア対象のアドレスが一部でも重なる場合にフェンスが必要なわけで
前後でロード・ストア対象のアドレスが重ならないことが最初から
解ってればフェンスを挟む必要がない。
マニュアルにも載ってる 常 識 で す。
975 名前： ,,・´∀｀・,, [sage] 投稿日： 2008/08/28(木) 23:39:13 ID:vX5clrui
アドレスが重複しないのに、
どうしてフェンスが必要だと思ったんですか？
それは仕様書が、というよりは文章が読めてないってことですよね。
868で指摘されて972や975でもこんな勇ましいことを言っていた君が、どこで無理解に気付いたのかな
978のnminoru氏のプレゼン読んでようやく分ったか？www
それでもまだトンチンカンなことを言っているが
36:,,・´∀`・,,）っ-○●◎
08/08/29 02:40:21 XA+DpWi/
「中途半端にフェンスに完了させられる」
これはフェンスを理解してる人の発言ではない
37:Socket774
08/08/29 02:41:42 Yk6PbdtE
フェンスを理解していなかった団子
フェンスを理解していなかった団子
フェンスを理解していなかった団子
認めざるを得なくなった団子
くやしいのう くやしいのうwwwwwww
38:,,・´∀`・,,）っ-○●◎
08/08/29 02:42:07 XA+DpWi/
> LarrabeeにはScatter/Gatherがあるだろ、
> 1命令で16要素のメモリアクセスするから、スレッド数にあわせて4段のパイプラインだと、
> 全部で64アクセスをバッファにためないといけない
ところが全部ページ内に収まるかを解決してしまえばバッファリングそのものが不要です
39:Socket774
08/08/29 02:44:30 Yk6PbdtE
知識も素養もないのにマニュアルだけ読んで フェンスを理解できなかった団子
しかも1スレにわたって偉そうな態度で大間違いを吹聴していた団子
くやしいっ…でも気持ちいいっ…
40:Socket774
08/08/29 02:47:03 Yk6PbdtE
ま、MACオタよりよっぽどマシな態度なんで、いじめるのはここまでにします
今日は団子が理解を深めたことと、素直ではないが自分の間違いを受け入れられるような人間に成長したことを素直に祝いましょう
41:,,・´∀`・,,）っ-○●◎
08/08/29 02:47:22 XA+DpWi/
↓彼はこの時点までライトコンバインを知らない
ちなみにCPUIDがフェンス作用があるのも俺が指摘して気づいた
763 名前：Socket774[sage] 投稿日：2008/08/26(火) 20:56:01 ID:JnmrWmO4
>>761
> リタイアまでは見届けてもデータの正しさには保証がない。
リタイアしたストア命令が、データを正しくストアしている保証はない、という意味か？
766 名前：Socket774[sage] 投稿日：2008/08/26(火) 21:17:10 ID:JnmrWmO4
>>765
すまないが、君と話すことはもうなにもない
「リタイアしたストア命令が、データを正しくストアしている保証はない」
なんて、x86に限らず、ありえない
42:,,・´∀`・,,）っ-○●◎
08/08/29 02:48:12 XA+DpWi/
勝利宣言ｗｗｗｗ
でも君は死ぬんだ。確実に。
Larrabeeは完全なEM64T準拠ですから。
43:Socket774
08/08/29 02:48:35 Yk6PbdtE
これに懲りたらちゃんと最新の分厚い教科書読んでね
どういうプライドから読まないのか知らないが、読んで損はしないよ
44:,,・´∀`・,,）っ-○●◎
08/08/29 02:50:14 XA+DpWi/
っていうかライトコンバイン命令のリタイヤ条件を把握してない奴が
フェンス命令の仕様を理解してるわけがないしさ。
766 名前：Socket774[sage] 投稿日：2008/08/26(火) 21:17:10 ID:JnmrWmO4
>>765
すまないが、君と話すことはもうなにもない
「リタイアしたストア命令が、データを正しくストアしている保証はない」
なんて、x86に限らず、ありえない
45:,,・´∀`・,,）っ-○●◎
08/08/29 02:50:59 XA+DpWi/
>>43
懲りるのはお前だよ。
なぜならLarrabeeにSSE*は実装されることは確定なのだから。
46:Socket774
08/08/29 02:57:29 Yk6PbdtE
>>44
> っていうかライトコンバイン命令のリタイヤ条件を把握してない奴が
そもそもライトコンバイン命令のリタイヤ条件というのがどういう意味かわからんが、よかったら説明してくれ
リタイヤするための条件なのか？
リタイヤ後に満している条件なのか？
団子の言い方ではそれすらわからん
47:,,・´∀`・,,）っ-○●◎
08/08/29 03:01:25 XA+DpWi/
> リストベクトルなんて有名な性能ボトルネックじゃん
> リソースの投入し甲斐のある箇所だよ、ベクトル機みたいにね
こんなことを言う馬鹿がなぜか回路の制約でSSEはサポートできないと言う
48:,,・´∀`・,,）っ-○●◎
08/08/29 03:38:21 XA+DpWi/
どこでリタイヤとみなすかなんて実装定義だが、
ライトコンバインはメモリまでストアするわけだから、もし、確実にストアできるまで
待つという仕様だと、それがすむまで待たなきゃならんよな。
すなわちストアなら100クロック以上待たないといけない。
でもそんなことやってない。
こんな風にしてフェンス命令を挟んでかかったクロック数計測してみればいい
movntps [ecx], xmm0
sfence
movntps [ecx+16], xmm1
sfence
movntps [ecx+32], xmm2
sfence
movntps [ecx+48], xmm3
sfence
フェンスは前の命令が全部リタイヤするまで次の命令をフェッチさせない仕様なんだから
逆にパイプライン段数の差をとれば、リタイヤと見なすのにかかってるクロックがわかる。
何クロックかかるかなんてのはそれこそ実装依存だが。
それでも、リタイヤと見なすのに逆算して数クロック分しかかかってないことがわかる。
つまり、確実にストアされたかなんてフェンスを使った時すら見てない。
実験してみればわかることだよ。
ちなみにスキャタ命令はMASKMOV*やMOVNT*と同じくライトスルーな。
AoSの読み書きはキャッシュのスラッシングが起きやすいから、キャッシュを
介さないことが好ましい。逆にむしろライトスルーでないと帯域が生かせない。
通常のストアはライトバック制御のせいで待たされるからね。性能を殺す要因。
また、ライトスルー命令だからこそ通常のアクセスとの境界にフェンス命令が【要る】わけよ。
これは常識な。
49:,,・´∀`・,,）っ-○●◎
08/08/29 04:05:25 XA+DpWi/
前スレの発言は撤回する気がないようなのでしつこく粘着してやる
> ページフォールトハンドラ内では当然共有データのページテーブルを更新するだろう
> なのでフェンス命令は必ず実行される
ハンドラに捕捉されるとパイプラインは全部流れます。
そもそもフェンス命令の「実行」状態って何を言うんだろうか？
まだ未完了の実行ユニットのポートをが数サイクルにわたって占拠され
その後ろで実行ステージを待ってる状態を実行中とは言わない。
フェンス命令によって中途半端にストアさせられるｗｗｗｗとかさ
ちなみにページスラッシングはOSじゃなくてマイクロコードでやる仕事ですので
例外ハンドラは全然関係ない。
> scatterの全てのメモリアクセスをバッファリングしておいて、すべてのアドレスがページインした状態を保証してからバッファを書きだすと
> 意味論的には正しいが、バッファリングのコストと、実際のストアまでの余計な遅延がある
ページインかどうかはアドレス指定に用いるレジスタに含まれるオフセット値の最大と最小だけとって
その範囲を見れば判別できるので全てを物理アドレスに変換しストアパケット作ってから
バッファリングするような手間をかけるまでもなく簡単に保証できる。
50:Socket774
08/08/29 04:13:44 d7DEsUlu
まだやってるのか…
どうでもいいけどARMのコード資産は見えないところに行き渡ってる。見えるエコシステムのx86界隈とは文化そのものが違うね。
51:,,・´∀`・,,）っ-○●◎
08/08/29 04:30:05 XA+DpWi/
見えるって言うか実際CPUターゲット別のプログラマ人口で一番多いのがx86だろ。
ソフト市場規模で見てもね。
ARMもいいんだけどでもIntelはXScaleやめちゃったしなぁ
WirelessMMXは本家ARMのSIMDより好きだったんだが。
俺もARMのアセンブリコードくらいは読めます。
てか、まさに、取ってきた仕事のために読んでる。
プレディケートの概念は直感的でいいね
3レジスタオペランドマンセー
52:Socket774
08/08/29 06:07:00 Yk6PbdtE
>>48
なーんだ
やっぱりわかってないじゃん(プ
53:,,・´∀`・,,）っ-○●◎
08/08/29 06:10:29 XA+DpWi/
>>49に補足
そもそもヴァカの間違いは
「フェンス命令は一度パイプラインにフェッチ前の命令で例外が起きても破棄できない」
という思い込み
実際には、例外が起きればパイプラインは全部フラッシュされ、
もちろんフェンス命令も「パイプラインに取り込まれてない」状態に巻き戻されます。
分岐予測ミス時にパイプラインを破棄するのと同じ理屈です。
正常処理できなかったフローは破棄します。
どーせパイプラインに取り込んじゃったら、例外が起きようとフェンス命令をリタイヤ
するまでは継続しないといけないと思ってるんだろ。前の命令を押し出してでも。
だってそうじゃないと「中途半端な状態でフェンスに中断させられる」とか言わないもんな。
基本、こいつはただの 馬 鹿 だ か ら
前の命令に影響を与える命令は存在しません。
そんなんあったらノイマン型コンピュータの原則に反します。
だから、教科書にも書いてある常識です。
後続の命令は実行前ならいつでも破棄出来ます。
パイプラインが実装されてからずっと、そういう構造になってます。
でも頭弱いから、フェンス命令が残ったまんまだと思ってるんだぜ。
その思い込みを根拠に、一貫性云々のこじつけでSSEがサポートできないとか言ってるんだぜ。
いまだに。
ちなみに、例外時に破棄することを前提としたストアバッファは存在しません。
例外チェックをクリアしてからストアバッファに溜まります。
で、フェンス命令のどこが厳しいだって？ｗｗｗｗ
そもそもの前提として、例外が起きたらフェンス命令は溜まったままになりませんｗｗｗｗ
スキャタのアドレス解決機構は、フェンス命令の実装の有無と関係なく
備えていないといけない話だし
54:,,・´∀`・,,）っ-○●◎
08/08/29 06:11:02 XA+DpWi/
>>52
なんだ、いまだにわからないのか。決定的な勘違いが。
55:,,・´∀`・,,）っ-○●◎
08/08/29 06:14:21 XA+DpWi/
×「フェンス命令は一度パイプラインにフェッチ前の命令で例外が起きても破棄できない」
○「フェンス命令は一度パイプラインにフェッチされたら、前の命令で例外が起きても破棄できない」
56:Socket774
08/08/29 06:19:00 Yk6PbdtE
>>48
ヒント
シングルCPUのユーザープロセスにはフェンス命令はいらない
57:,,・´∀`・,,）っ-○●◎
08/08/29 06:23:16 XA+DpWi/
馬鹿だなCore 2で計測してんのに。
計測して反証しろよ。
お前アセンブラ知らないから無理か。まあ馬鹿には無理なのはわかってるし。
x86の話してるのに、x86の命令に存在しない
「s t o r e 」
とか書いちゃうくらいだもんな。ぷぷぷ
58:,,・´∀`・,,）っ-○●◎
08/08/29 06:28:54 XA+DpWi/
それより>>53で図星なんだろ？
でないとフェンス命令が干渉するなんて世界で1人だけの妄想は
起こりえない
59:,,・´∀`・,,）っ-○●◎
08/08/29 06:38:06 XA+DpWi/
URLﾘﾝｸ(aceshardware.freeforums.org)
ここにx86プログラマ界の重鎮Agner氏がいるから
自分が思ってるフェンス命令の動作を説明してきてごらんよ
一発で論破されるから
60:前スレ641
08/08/29 07:32:57 uVP3Rngo
MOVNT系はノンテンポラルとかいう Intel 用語で呼ばないといかんでしょう
ライトスルーはライトスルーで別物だし
ライトコンバインは他にも色々あるからさ
というか、ノンテンポラル命令のWrite Combineプロトコルって、
M,E → Cache Line と Write Data を Combine して burst write
S → RFO後、辻褄が合うようにwrite (実装依存?)
I → マスク付で Write Data を burst write
で、必ず I に落ちるプロトコルっしょ
(勘違いがあったらごめん)
ライトスルーってのは Valid か Invalid しかないのよ
61:Socket774
08/08/29 10:55:15 Yk6PbdtE
>>48
> また、ライトスルー命令だからこそ通常のアクセスとの境界にフェンス命令が【要る】わけよ。
> これは常識な。
プププププ
62:Socket774
08/08/29 11:05:35 L2m2fICO
LarrabeeでSSEが動くのはTera×3以前からIntel自身に言われてたこと。
むしろAVXやLNIは今年になってからの新事実。
Larrabeeには、既存命令と干渉するような新命令なら、最初から載せないだろう
たしかに、キャッシュに収まりきらない大きい多次元配列のアクセスは
ノンテンポラルを使うべきというのはPen3の頃からインテルが言ってた事項だよ。
シーケンシャルならまだいいが、ストライド次第では壮絶なキャッシュミス地獄になるからね。
63:Socket774
08/08/29 11:52:43 Yk6PbdtE
団子> 【現実のIntel/AMD/VIAの実装】
団子> ストアバッファはあくまでキャッシュ帯域の節約のため一括転送するために貯めておくもの。
プププププ
64:Socket774
08/08/29 11:56:39 Yk6PbdtE
> >>22
> 本当に撤回してたんならアンカー出してコピペしてくれよw
コピペマダー？
65:Socket774
08/08/29 12:07:41 Yk6PbdtE
>>20
> 団子> フェンス命令をしないといけないのはアクセスするアドレスが重なるときだよ。やっぱり君は解ってないな。
> こんなアホみたいな主張を続けるのか
>>22
団子> >>20
団子> 撤回済みだけど前スレで
フェンスをちゃんと理解したと思ったら
>>48
団子> また、ライトスルー命令だからこそ通常のアクセスとの境界にフェンス命令が【要る】わけよ。
団子> これは常識な。
やっぱりわかっちゃいねー！！
団子の浅薄な理解はラッキョのごとし
66:Socket774
08/08/29 12:12:48 Yk6PbdtE
正解も書いておいてやるぞ
Weak Consistencyに於いては
2つのメモリアクセスの順序を**CPU外部**に対して保証する場合には、必ずフェンスを間に挟む必要あり
それ以外の場合にはフェンスは全く不要
ライトスルーとかもう全然関係ナシ
67:,,・´∀｀・,,
08/08/29 12:53:52 XA+DpWi/
で、その必要な命令を、マルチコアアーキテクチャのLarrabeeでは
SSEごと「サポートできない」と言ってる馬鹿がいる。
その理由も、既に完全否定されているにもかかわらず、である。
フェンス専用命令のサポートを消して全部CPUIDで済ませろって？
20倍のクロックも待たされる上にEAX:EDX:ECX:EBXレジスタを汚すCPUIDを？
まあ、嘘を言ったのは認めるさ。
まあ、「storeなんて命令なんて無い」って言われて必死に調べたんだろうと
思って、軽くあしらっただけなんだけどさ。
でもアレのコードはプログラミング作法としちゃ駄目だよ
スタックとかヒープとかデータセグメントに対する相対アドレッシング
とかじゃなしに10000000とかの即値でアドレッシングする時点で
安全にストアできる保証がない。
即値はアプリケーションの作法としてはありえない。
そういう意味ではどのみちフェンスがあろうがなかろうが、
一般保護違反になる可能性高いから、あろうがなかろうが同じってことで。
まあいいけど、問題でも出しておくか
add eax, [edx+ecx*2+12345678h]
のModR/Mバイトのエンコードを16進数で答えよ。
これはx86アーキを知る上では常識だけどさ。
68:,,・´∀｀・,,
08/08/29 12:58:42 XA+DpWi/
というかスレッド間で共有するアドレスならなおさら、
データセグメントなりヒープのポインタを使ったアドレッシングになるわけで
「即値」になるわけがない
69:Socket774
08/08/29 13:03:34 YVziV6Bc
何故そこで86になるような問題にしないのか
70:Socket774
08/08/29 13:35:22 Yk6PbdtE
>>67
調べりゃすぐわかることを好きこのんで覚える趣味はないが、まだちょっとだけ覚えている
op modrm sib offset
add eaxはopバイトで指定
modrmがsibの存在とオフセットを指定
siバイトは、スケール2 インデックスecx ベースedx
だっけ
オペコードの割り当てはわすれたが、26hくらい
7ビット目は0、6-4ビットでALUの機能を指定、3-1ビットでアドレッシング、0ビット目でbyte/word
レジスタはeax,ebx,ecx,edx,esp,ebp,esi,ediの順で0から7にエンコード
modrmは、md rrr mmm
modはアドレッシング形式を指定する
mod!=0とmmm=5でsibバイトの存在を指定する
mod=0がレジスタ-レジスタ
mod=1,2,3がレジスタ-メモリでオフセットサイズがそれぞれ0,1,4バイト、かな
sibはss iii bbb
スケールは1,2,4,8なので、*2はss=01
オフセットはリトルエンディアン
結局
26 C5 53 78 56 34 12
20年ぶりにしてはよく覚えてるだろww
71:Socket774
08/08/29 13:40:45 Yk6PbdtE
>>70
×add eaxはopバイトで指定
○addはopバイトで指定
おまけ
20 add eax,eax
21 add eax,ebx
22 add eax,ecx
23 add eax,edx
24 add eax,imm
25 add eax,[offset]
26 add r, r/m
27 add r/m, r
modrmのmmmは
000 [eax]
001 [ebx]
002 [ecx]
003 [edx]
004 [esp]
005 sib
006 [esi]
007 [edi]
で、modの値に応じてそれぞれにオフセットがつく
mod=0のときは、そのままレジスタ番号
じゃなかったけか
72:Socket774
08/08/29 13:49:54 Yk6PbdtE
>>71
> 7ビット目は0、6-4ビットでALUの機能を指定、3-1ビットでアドレッシング、0ビット目でbyte/word
あ、これと矛盾するなあ
b/wの指定はどうすんだっけな。。
73:,,・´∀｀・,,
08/08/29 13:52:22 XA+DpWi/
20年ぶりってｗｗｗおっさんだね。
それならもうアルツハイマー始まっててもおかしくねーわな。
最近のOSセグメント管理知らなくて当然だな
共有変数を即値でとるとか、マルチプロセッサ環境としてにありえないことを
平気で言ってのけられるわけだ。
なっとく（笑）
OSレスならある意味フリーダムだけどね。そんかわりマルチプロセッサの管理が面倒だ。
つーか
Agner氏も当然のごとくLarrabeeではSSEは載るって見てるようだけどその点はどうよ？
74:Socket774
08/08/29 13:57:49 Yk6PbdtE
>>73
OSレスな環境の経験はないのか
そはともかくエンコーディングのクイズはどうよ？
75:Socket774
08/08/29 14:03:15 Yk6PbdtE
>>67
> まあ、嘘を言ったのは認めるさ。
> まあ、「storeなんて命令なんて無い」って言われて必死に調べたんだろうと
以下略
負 け 犬 の 遠 吠 え
76:,,・´∀｀・,,
08/08/29 14:03:36 XA+DpWi/
OSレスでマルチコアでは結局OSの機能を自分で作る羽目になるだけだからな
組み込みでもマルチコア使う用途じゃ審美餡やらWinCEやらLinuxを使うのが一般的だぞ
ほい
URLﾘﾝｸ(maelific.dyndns.org)(32bit).xls?rev=87&format=raw
77:,,・´∀｀・,,
08/08/29 14:05:30 XA+DpWi/
でも即値指定だけはないわー
78:,,・´∀｀・,,
08/08/29 14:08:26 XA+DpWi/
＞負け犬の遠吠え
っていうか即値アドレス指定の時点でマルチタスクOS上のアプリケーション
の共有変数として有り得ないしー（笑）
コードシーケンスとして論外（笑）
79:Socket774
08/08/29 14:11:11 Yk6PbdtE
>>78
負 け 犬 の 遠 吠 え
80:,,・´∀｀・,,
08/08/29 14:22:32 XA+DpWi/
79 ：Socket774：2008/08/29(金) 14:11:11 ID:Yk6PbdtE
>>78
負 け 犬 の 遠 吠 え
と負け犬が遠吠えしてます
出題者が間違えるなんてありえませんから。残念。
81:,,・´∀｀・,,
08/08/29 14:25:01 XA+DpWi/
「フェンスに完了させられる」の誤解はいつ辞めるの？
その誤解の上にSSEをサポートできないのトンでも論理が構築されてるわけで
Agner氏にメールで聞いても「有り得ない」って回答だよ。
82:Socket774
08/08/29 14:35:50 Yk6PbdtE
>>81
> 「フェンスに完了させられる」の誤解はいつ辞めるの？
全く正しい表現だよ
比喩的ではあるから、表面的な理解もあやしい団子には難しかったかもしれないね
> Agner氏にメールで聞いても「有り得ない」って回答だよ。
引用してくれ
83:,,・´∀｀・,,
08/08/29 14:51:34 XA+DpWi/
つーかIntel自身が「Intel 64準拠」だって言ってるんだがなぁ
Intelのx86 64bit拡張はIntel 64（旧称EM64T; Clackamas）以外に無いんだよ。
YamhillはMSその他に揉みつぶされました。
まあ、がんばってSSE非対応の根拠探してくれよ。
ネット上で同意者探すだけでもいいかもよ。
ま、徳川の埋蔵金なみに見つからないと思うけど。
まだ投げられてないサイコロの目をどうこうじゃなくて
既に決定した論理であり、しかも一部にはIntel(R) 64 Technology準拠
であると情報が漏れてる上で
ネットの片隅でSSEサポートでないと言ってる馬鹿一名
せいぜい全てが公開されるまで思い込みで踊れよ愚者め
Intelの公式フォーラムに参加してるx86システム技術者の重鎮ですら
XSAVEを用いたLarrabeeのワイドベクトルレジスタの退避モデルについて
フォーラムで意見を交わしているような既にそんな状況。
SSEがサポートされないなんていってる奴は後藤とこいつ以外みたことが無い
84:Socket774
08/08/29 14:51:50 Yk6PbdtE
1)先行するストア命令が完了したのを、フェンス命令によって保証されてから、後続のストア命令が完了する
が、より比喩的でない表現かな
2)先行するストア命令が、フェンス命令によって完了させられてから、後続のストア命令が完了する
ちょっと比喩的ではあるけど、わかっている人には1)はくどいし、まさか団子がフェンスを理解していなかったとは思わなかったからさ、ごめんな
1)も本質的でないが不正確なところもあるけどね
フェンスは先行するストアが後続するストアより「先に」完了することだけ保証すれば、実装はどうでもいい
SSEのフェンスみたいに後続命令をブロックするのだけが可能な実装ではない
85:,,・´∀｀・,,
08/08/29 14:52:47 XA+DpWi/
自分でメールしろよ。とんでもないこと言ってるのお前だけなんだから
英語でおｋ。氏はデンマーク人だけど。
86:,,・´∀｀・,,
08/08/29 14:54:31 XA+DpWi/
後続命令はパイプラインに載ってない状態になるんだぞ
バッファなんて要らないジャン
87:Socket774
08/08/29 14:54:56 Yk6PbdtE
お前聞いてないんじゃないかよww
88:,,・´∀｀・,,
08/08/29 15:14:21 XA+DpWi/
別にそれが誤ってるなんて言ってねーよ
例外が起きてもフェンス効果が有効だと思ってるがゆえに馬鹿なんだよ
しかもExecuteより手前のステージは分岐予測ミスや例外発生時に
しょっちゅう破棄されてる。もちろんフェンス命令も含めてだ。
フェンス命令の作用自体、仕様書どおり「常にフェッチを止める」というよりは
フェンス命令が実行ステージに入ったときに前の命令がリタイヤするまで後続命令列の
フラッシュを繰り返すことで実現されてるんじゃないかと思ってたりするが。
ま、それこそ実装に依存した話になるが。
実行ステージに入っても無いのにフェンス効果が利く必要は一切ない。
いつでも破棄できることが重要。
で、PF等が起きたらパイプラインを破棄して立て直せばよく
ストアバッファを破棄できる仕様にする必要が無い。
ま、16Wayでもそんなに大きいとは思わないがな
VIAのインオーダの省電力CPUですらWCバッファが数Wayとかだろ。
89:,,・´∀｀・,,
08/08/29 15:17:44 XA+DpWi/
>>87
だから「SSEサポートできない」なんてこの世界で後藤とお前くらいしか
思ってないないんだから、お前が直接識者に聞いてみろよ。
どうせ自分の間違い認められないんだろ？
90:,,・´∀｀・,,
08/08/29 15:20:16 XA+DpWi/
っていうか
前の命令が完了してない時点で、フェンス命令はExecuteの手前のステージってのは
わかる？
わかってない？
だから馬鹿は氏ねよ
91:Socket774
08/08/29 15:21:14 Yk6PbdtE
>>88
> 例外が起きてもフェンス効果が有効だと思ってるがゆえに馬鹿なんだよ
また人が言ってもいないことを～
例外ハンドラ内の話してただろ
>>89
相手のいることなので、団子のためだけにそんな手間かけんのはやなこった
92:,,・´∀｀・,,
08/08/29 15:24:25 XA+DpWi/
↑
SSEサポートできないなんていってる奴が
お前と後藤以外に誰がいるんだよ
つまりお前が人の意見に合わせられないゴミなの
93:,,・´∀｀・,,
08/08/29 15:29:08 XA+DpWi/
＞例外ハンドラ内の話してただろ
例外ハンドラってのはOSがトラップしてアプリのcatchブロックなんかに
投げるアレだけど、それでいいのか？
例外処理ブロックに飛ぶってことは、その時点でオペレーション失敗時に
読み書きしたメモリがクリーンである保証はそもそも無いんだよ。
保証をすることは規格にも無い。
だからバッファリングなんてする必要はないんだ。
94:,,・´∀｀・,,
08/08/29 15:50:05 XA+DpWi/
それよりさっさと、どこのきょうかしょなのかおしえてよ。
そのきょうかしょ（笑）に基づけば「SSEがサポートできない理論」を説明できるのか？
なら1000円までなら尼損で買ってやんよ。
っていうか50過ぎのおっさんなんだろ？無理するな
95:,,・´∀｀・,,
08/08/29 16:07:03 XA+DpWi/
>>93に補足すれば
そもそも例外を検出してないときですら、コンピュータは正しく
データを読み書きしてる保証なんてどこにもない。
ECCメモリのビット誤り検出にしてもそう。100パーセントの
信頼保証は有り得ない。
逆にもし完全に保証できたら、TMRによる多数決冗長系が組める
x86に対するItanium2の優位性は何なのよって話になるだろ。
96:MACオタ＞団子 さん
08/08/29 17:28:00 r1khUYoD
>>89
------------------
だから「SSEサポートできない」なんてこの世界で後藤とお前くらいしか思ってない
------------------
できるできないわ別にして、私もx87やSSEをサポートしない可能性わ有ると思っているす。
97:,,・´∀｀・,,
08/08/29 18:03:29 XA+DpWi/
仕様書見たけど不正な操作に対するコンシステンシ保証なんて
元々規定されてないじゃん。
命令レベルでall or nothingなんて保証したところでそもそも
保 証 す る 意 味 が ね ー し。
アプリケーションとしてall or nothingであったほうがいいのは、
あくまで関数レベル・機能レベルの話になるわな。
命令レベルで保証されても、命令レベルで㌧でリカバリーとか
無駄だからね。
例外トラップ機構なんて高級言語向けのものだから命令レベルで
順序保証されてても意味ねー。
するだけトランジスタの無駄。
フェンス命令は正常なフロー(all)にだけ順序保証をすればいい。
というかそういうもともと仕様のはずだが。
それがなんでscatterと干渉するんだよｗｗｗ
マジ頭悪くね？
98:MACオタ＠補足
08/08/29 18:13:04 r1khUYoD
SSEサポートの程度わ不明という点でわ、Anandも同意見の様す。
URLﾘﾝｸ(www.anandtech.com)
------------------
64-bit x86
SSEn support?
Parallel/Graphics?
------------------
99:,,・´∀｀・,,
08/08/29 18:15:37 XA+DpWi/
>>96
AVXのマニュアルではちょっとだけ
SSEのソフトエミュレーションについて言及してたね
利用頻度の少なくなった命令は#UDをOSに投げて、
トラップしてエミュレーション実行するとか
AMD64だったか忘れたがx87についても
エミュレーションについて言及されてたな。
でもそれは「サポートしない」って言わないんじゃね？
SPARC/Solarisがそんな感じのマイナー命令サポートだし
しかしだな
SSEでも現状利用頻度が多い以上は、ハードワイヤードロジックで
実装する理由がある。
ついでに言うとOSによるSSE*エミュレーションの実装は、
現状影も形も無いわけで、じゃあ誰が提供するのって話になる。
Linuxならpinでも使って実装する手もあるけどさ。
エミュレーション自体、SSEがほとんど誰にも使われなくなった場合の
オプションとして、ゆくゆくは、の話であって、
移行もしてないうちから切り捨てるのはセオリーに反してるべ。
おまいさんの信奉するAppleじゃ日常茶飯事かもしれんが
Intelに取っちゃ死活問題だべ。
100:,,・´∀｀・,,
08/08/29 18:20:11 XA+DpWi/
>>98
Intelの言うところの「64bitサポート」は、
AMD64のLongモードとのISA互換＋SSE3＋CMPXCHG16B
までを要件としてるからそこまでは確定だべ。
逆にSSSE3/SSE4.1/SSE4.2/AES/CLMULのサポートはどこまでかは
俺にもわからんべ。
それこそソフトエミュレーションかもしれんべ。
101:MACオタ＠補足
08/08/29 18:21:08 r1khUYoD
同様な疑問を提示しているサイトす。
URLﾘﾝｸ(techgage.com)
-------------------
- Will apps written for today's Intel CPUs run unmodified on Larrabee?
- Will apps written for Larrabee run unmodified on today's Intel multi-core CPUs?
- The SIMD part of Larrabee is different from Intel's CPUs - so won't that create compatibility
problems?
The first two questions are quite similar, and the straight answer is "No.". But, there's a caveat.
If we were to change 'apps' to 'code', then the story would change, because as it stands, Intel
claims that the same Larrabee code can be compiled to run on either the CPU or GPU (Larrabee).
It's all a matter of what you choose in the compiler to do.
Intel noted that the code wouldn't be compiled for both the CPU and GPU at the same time,
since the compiler will optimize the binary for the respective architecture. They went on to say
that it could technically be compiled for both, but that would not be the ideal scenario, due to
various optimizations.
-------------------
Larrabee論文の「要リコンパイル」の行を重視している模様す。
102:MACオタ＞団子 さん
08/08/29 18:23:43 r1khUYoD
>>99-100
広い世界にわ、LarrabeeのISAサポートに関して疑念を持っているヒト達がいる例ということで。
103:Socket774
08/08/29 18:36:56 Yk6PbdtE
>>93
> 例外ハンドラってのはOSがトラップしてアプリのcatchブロックなんかに
> 投げるアレだけど、それでいいのか？
プ
>>97
> 命令レベルでall or nothingなんて保証したところでそもそも
>
> 保 証 す る 意 味 が ね ー し。
ププ
104:,,・´∀｀・,,
08/08/29 18:37:39 XA+DpWi/
>>101
OSは動く必要はあるでしょ。
x64のOSはAMD64の基本命令まで最低限動くことを前提に作られてるから
動かないと話にならない。
IntelはMSに却下されたYamhillをしぶしぶ廃案にし、Longモードで使える
命令をAMD由来の特権命令も含めてサポートすることで、
それがx86の64ビット版の統一仕様になった。
それを1命令でも欠いてると、対応OSがない可能性がある。
SSE2までは有無を言わさず確定。
でもそれ以降の拡張命令は完全にサポート任意だから
サポート決めうちで最適化コード組んでればリコンパイルが必要ってのは
確かにそうなんじゃね？アセンブラやIntrinsics決めうちだと
リコンパイルどころじゃすみそうにないけどな。
俺はむしろリコンパイルが必要ってのは性能問題だと思ったが。
命令サポートが同じでも、インオーダだと専用のスケジューリングが
必要だし、あと論理CPU数分のスレッドを起こさないといけない。
性能が出せなきゃLarrabeeを使う意味が無いからな。
同じコードで同じスレッド数ならXeonよりはるかに遅い。
105:,,・´∀｀・,,
08/08/29 18:39:08 XA+DpWi/
>>103←馬鹿だねこいつ。もうプしか言えないだろ。
得意の教科書で攻撃してこいや屑め
106:,,・´∀｀・,,
08/08/29 18:40:53 XA+DpWi/
>>101
っていうかそれ
サポート命令が同じなら性能が同じだと思ってる素人アナリスト臭い
はっきり言って考察として読むに値しない。
107:,,・´∀｀・,,
08/08/29 18:48:04 XA+DpWi/
誰かと思えばRob Williamsか。組み込みRTOSの本書いてる人だね。
こらMACヲタ、記者名くらい引用汁
108:MACオタ＞団子 さん
08/08/29 18:54:01 r1khUYoD
>>107
-------------------
記者名くらい引用汁
-------------------
だから何時も安易に他人のことをバカバカ書くなと。。。(笑)
109:,,・´∀｀・,,
08/08/29 18:54:54 XA+DpWi/
それでも記事レベルで数を競うなら、「x64」として書いてる記事のほうがよっぽど多いんだよな
URLﾘﾝｸ(www.google.co.jp)
Larrabee "x64 incompatible"
だと2件しかヒットしない。しかもまったく関係ないページ
URLﾘﾝｸ(www.google.co.jp)
110:,,・´∀｀・,,
08/08/29 19:00:30 XA+DpWi/
LinuxのXSAVE/XRESTRサポートのためのパッチ送った企業ってどこだったっけ？
まあそういうこっちゃ
ヘッダの拡張フィールドによって1024ビットSIMDとかの時代まで対応できる命令とされる。
111:,,・´∀｀・,,
08/08/29 19:06:12 XA+DpWi/
Intel's Larrabee GPU Will Support Linux
URLﾘﾝｸ(www.phoronix.com)
面白いことになったね
112:Socket774
08/08/29 19:24:32 0dK6Hl59
？
Xの話じゃないの
113:MACオタ
08/08/29 19:33:50 r1khUYoD
Siggarph2008のLarrabeeプレゼン見つけたす。
URLﾘﾝｸ(s08.idav.ucdavis.edu)
興味深いところわ、この辺すか。
- in-orderでも遅くない (p.7)
- U/Vパイプのペアリング(制限？)わPentiumと同じ (p.7)
- スカラ命令わシングルサイクルレイテンシ (p.7)
- SMTわクロックごとの粒度のFGMT (p.7)
ただし、スリープしているスレッドわ除く (p.11)
- SIMD ISAで引数の内、ペナルティ無しにメモリを指定できるのわ、一つだけ (p.8)
- SIMDユニットで大半の命令わ実行レイテンシ8サイクル以下 (p.8)
- SIMDの数値精度わビット表現レベルで"fast mode" SSEに同じ (p.8)
- SIMDユニットで4-byeより小さいデータ型わサポートしない (p.9)
16-bit Float, byte, shortわ、自動符号拡張
グラフィック用の構造体も低レイテンシで変換
- Scatter/Gatherわ16-wideベクトルの各要素に32-bitオフセットで指定 (p.9)
スカラコードの自動SIMD化に適用
- SMTの主目的わキャッシュミスの隠蔽 (p.11)
でも命令レイテンシの隠蔽にも有効
- スレッド間でTLBも共有 (p.11)
114:Socket774
08/08/29 19:36:23 6g0fQyCg
今月のパワレポでの後藤
「LarrabeeはMMX/SSE以降の拡張命令のほとんどを採用しないと見られる」
みたいなこと言ってた。
"ほとんど"という言葉が入ったのがネット記事との違いか。
115:MACオタ＞団子 さん
08/08/29 19:44:06 r1khUYoD
>>100
-------------------
Intelの言うところの「64bitサポート」は、
AMD64のLongモードとのISA互換＋SSE3＋CMPXCHG16B
までを要件としてるからそこまでは確定だべ。
-------------------
そのIntel謹製の資料で、x64ともx86-64ともEM64TともIntel64とも書かずに、
===================
Plus standard 64-bit instruction extensions
===================
と書いているのにわ、意味があるのかもしれないす。"standard"すから、X64を指すと受け取るのも
アリと思うすけど。。。
116:,,・´∀｀・,,
08/08/29 19:46:05 XA+DpWi/
> - SMTの主目的わキャッシュミスの隠蔽 (p.11)
> でも命令レイテンシの隠蔽にも有効 。
なー、MACヲタよ。命令レイテンシの隠蔽できるってよ。
加減算は1サイクルだから意味無いす（笑）か？
117:Socket774
08/08/29 19:49:24 0dK6Hl59
Xでlarrabeeが使えることの何が面白いの？
118:,,・´∀｀・,,
08/08/29 20:00:00 XA+DpWi/
＞standard 64-bit instruction extensions
そりゃ「standard」って言ったらAMD64/Intel 64の共通規格のアレ以外ないでしょ。
それ以外にstandardはないでしょ
basicだったら微妙だしsubsetって言ってるなら非互換だろうけどさ。
まあSSE2までは少なくとも確定、SSE3もおそらくいける。
3バイトOpcodeを使うSSSE3以降が微妙。デコードアルゴリズムの拡張が必要だからね。
OSが最低限動くためにはSSSE3/SSE4は必ずしも対応させる必要はない。
この世代のx86は相対的にデコーダのコストが大きいから。
1ダイに16コアとか32コアとか強力なx86デコーダが載るのかと考えればぞっとする。
119:MACオタ＞団子 さん
08/08/29 20:03:12 r1khUYoD
>>116
-----------------
なー、MACヲタよ。命令レイテンシの隠蔽できるってよ。
加減算は1サイクルだから意味無いす（笑）か？
-----------------
日本語が読めないことを思い出させて、わざわざ恥をかくことも無いと思うすけど。。。
私の書いた内容わ、コレす。
=================
191 名前：MACオタ＞団子 さん 投稿日：2008/08/17(日) 13:15:36 ID:Zsenu7UF
>>190
---------------
命令間のレイテンシ隠蔽のための方策も全然違う。
4Wayのマルチスレッドによりプログラム側から見たレイテンシを小さくしたのがLarrabee
---------------
4-wayマルチスレッドわロード・ストアの隠蔽だと思われるす。
ショートパイプラインが売り(多分クロックわ低め)すから、命令レイテンシわ隠蔽するまでもなく
小さいんじゃないすかね。
レジスタわ少なそうすから、後続命令への演算結果のフォワーディングがCell/B.E.より重要になるし。。。
=================
で、積和わ綺麗にパイプライン化されているとのことすから、一生懸命レイテンシ短縮しなくても
動作に問題わ無いす。
==================
- Ternary, multiply-add, one clock throughput (p.8)
==================
120:,,・´∀｀・,,
08/08/29 20:03:42 XA+DpWi/
それとも、MACオタ用語的には「standard」に規格外って意味でもあるのか？
121:Socket774
08/08/29 20:05:38 0dK6Hl59
で、Xでlarrabeeが使えることの何が面白いの？
122:,,・´∀｀・,,
08/08/29 20:06:13 XA+DpWi/
面白いから面白いだけ
123:MACオタ＞団子 さん
08/08/29 20:07:17 r1khUYoD
>>120
-------------------
MACオタ用語的には「standard」に規格外って意味でもあるのか？
-------------------
日本語が読めるなら>>115を読み直せば判ると思うす(笑)
124:,,・´∀｀・,,
08/08/29 20:07:41 XA+DpWi/
＞standard 64-bit instruction extensions
~~~~~~~~
さて、ここはどう弁解しよう？
オッサンのトンデモ論的にはLNIと干渉するんだろ？ｗｗｗｗ
125:Socket774
08/08/29 20:07:49 0dK6Hl59
ふぅん
126:,,・´∀｀・,,
08/08/29 20:13:25 XA+DpWi/
>>123
なにか？AMD64準拠ならOSが動く条件はクリアだよね
暗黙にCMOV/SSE/SSE2も含まれる。
つまり「彼」の死亡条件がクリアされましたｗｗｗ
SSE3もCMPXCHG16Bも今はAMD64の規格に含まれてる。
だがAMDは3DNow!と同じく実装は任意としている。
127:,,・´∀｀・,,
08/08/29 20:16:50 XA+DpWi/
SSE3/CMPXCHG16Bも実装しとかないとAMD64互換であってもIntel 64非互換になっちゃうんだよね。
それIntel的にはまずいでしょ（メンツ的な意味で
128:Socket774
08/08/29 20:17:59 c37I8Bch
> 111 名前：,,・´∀｀・,, 投稿日：2008/08/29(金) 19:06:12 ID:XA+DpWi/
> Intel's Larrabee GPU Will Support Linux
> URLﾘﾝｸ(www.phoronix.com)
>
> 面白いことになったね
>
>
> 112 名前：Socket774 投稿日：2008/08/29(金) 19:24:32 ID:0dK6Hl59
> ？
> Xの話じゃないの
面白いテンプレが出来たね
129:Socket774
08/08/29 20:27:41 L2m2fICO
>>128
いいから死ね
130:Socket774
08/08/29 20:33:46 L2m2fICO
OpenGL(MESA)はXを介さずにフレームバッファにダイレクトに書くんだが。
DirectXがGDIでないのと同じレベルで別物。
無知って恥ずかしいね。
131:Socket774
08/08/29 20:36:58 0dK6Hl59
ふぅん
で、なにが面白いことになるの
X.Org 7.5 should be out before Larrabee ships and hopefully X.Org 7.6, but based upon the recent X history, who knows?
132:MACオタ
08/08/29 20:37:39 r1khUYoD
>>113すけど、上の階層を漁るともう2つSiggraphのプレゼンが見つかるす。
URLﾘﾝｸ(s08.idav.ucdavis.edu)
URLﾘﾝｸ(s08.idav.ucdavis.edu)
前者わ、ちょうどLarrabeeにおける『ソフトウェアコンテキストの細粒度切替による命令レイテンシの
隠蔽』を語っているす。ちなみに後者わグラフィックよりの話題す。
この中に出てくるLarrabeeにおけるコンテキストの最小単位"Fiber"って、リソースがダブらないよう
に複数の処理をするコードを自前で書けという意味にも取れるす。
特にハードウェア的な支援が無いように見えるすけど、「リソースがダブらないように」を満たすために
予想以上にレジスタファイルが大きいとか？
133:Socket774
08/08/29 20:41:28 8RINfp7M
>>131
イジメよくない
134:Socket774
08/08/29 20:44:25 L2m2fICO
私の肛門もフェンス命令に強制リタイアさせられそうです(笑)
135:Socket774
08/08/29 21:01:26 L2m2fICO
LNIとSSEは共存できるが、Larrabeeの実装では、VPUにSSE命令を100%コンパチで実装するのは難しい
(笑)
136:Socket774
08/08/29 21:04:17 L2m2fICO
【テンプレ】
> つか、万が一でもSSE*を100％サポートだったら死ぬの？
いいともさ
そのかわり、ごくささいな互換性でも失なわれていたらお前が死ねよ
137:Socket774
08/08/29 21:07:58 0dK6Hl59
なんか独り言いい始めたぞ
138:Socket774
08/08/29 21:08:56 L2m2fICO
SSEがサポートできない（プ
139:Socket774
08/08/29 21:11:18 L2m2fICO
私のバッファにもスキャット命令が溜め込まれそうです
フェンスに貫かれそうです
アーッ！
140:Socket774
08/08/29 21:29:56 8RINfp7M
>>137
お前があんまりいじめるからだろ
141:Socket774
08/08/29 21:38:58 L2m2fICO
先生、フェンスに完了させられてしまいました。
142:フェンスに完了
08/08/29 21:41:03 L2m2fICO
先生、ららびいがSSEをサポートしない理由教えてください
143:Socket774
08/08/29 21:42:14 0dK6Hl59
なんだ団子か
144:フェンスに完了
08/08/29 21:43:15 L2m2fICO
なんだ自殺宣言した人か
145:Socket774
08/08/29 21:44:19 koiu0PxM
ララビーのアレ(ストリームプロセッサ？)はインオーダー型のデュアルイシューじゃなかったっけ？
CPUコアのほうがインオーダー型のデュアルイシューなのは既出だけど
デュアルのうち片方だけは簡易にしてSIMDを載せない可能性があるとかいう話があった気がする。そのへんどうなってるんだろ。
146:フェンスに完了
08/08/29 21:44:30 L2m2fICO
で、いつ死ぬの？
147:Socket774
08/08/29 21:45:27 0dK6Hl59
は？
148:Socket774
08/08/29 21:46:44 8RINfp7M
>>143
バラスナヨ
149:フェンスに完了
08/08/29 21:47:57 L2m2fICO
フェンスに強制完了させられた短い人生だったな
150:Socket774
08/08/29 21:49:40 0dK6Hl59
何を言ってるんだろうねこの人は
151:Socket774
08/08/29 21:51:31 DRsgErBY
どんなCPUだろうと、GPUだろうと、GPGPUだろうと、DSPだろうと
呼び方違えど同じマイクロチップ(材質はシリコン(半導体))の仲間だ
152:フェンスに完了
08/08/29 22:00:22 L2m2fICO
ナウなヤングにバカウケ
153:MACオタ
08/08/29 22:19:39 r1khUYoD
>>132の続きすけど、よく読むと最初のプレゼンのp.25にFiberの説明があるす。
-------------------
・ Fibers switch on texture request submission
- Saves live registers
- Saves the IP to resume at
- Jumps to the next fiber’s IP
- Next fiber restores live registers
- Gets texture result, continues shading
--------------------
レジスタの退避が必要ということわ、レジスタが増えている訳でも無さそうす。
そもそも同じページに"No hardware or OS support"って書いてあるす。。。
Larrabeeのスケジュール管理の話題で、どの辺が画期的なのか誰か教えて欲しいす。
154:Socket774
08/08/29 23:13:04 xdqYRUcn
ローエンドGPUのことなんてどうでもいいっす
155:フェンスに完了
08/08/29 23:13:06 L2m2fICO
scatter命令のためにSSEをサポートしないのが画期的
156:Socket774
08/08/30 00:37:35 efBh6GPC
>>145
Larrabeeの命令イシューは、VPU命令の大半は片方からのみ、ベクトルストア命令のみもう片方からも発行可能
とインテル資料にあった、はず
>>153
2000年より前に、マイクロソフトのコンパイラのfiberサポートのセールストークを見たことはあるが
一般的な用語かどうかはともかく、どちらもスレッドよりさらに細かいものを指していることには違いがないだろう
- Saves live registers
- Saves the IP to resume at
- Jumps to the next fiber’s IP
- Next fiber restores live registers
- Gets texture result, continues shading
これだけ見るとMSの説明と同じだね
Saves live registerというのは、liveでないレジスタは退避しないということ
MSのfiberは、特にスタックフレームを共用していた
157:Socket774
08/08/30 00:59:32 efBh6GPC
>>156
一言でいえば、fiber≒コルーチン
158:MACオタ＞156 さん
08/08/30 01:04:04 rRKT6K+V
>>156
fiberの解説感謝するす。しかし、
-------------------
liveでないレジスタは退避しないということ
-------------------
これAltiVecならvrsaveレジスタでハードウェアサポートがあるような話すけど。。。
URLﾘﾝｸ(www.ibm.com)
====================
You might think that the overhead of saving thirty-two 128-bit registers would be a little
steep, and the designers of AltiVec would agree. To this end, a 32-bit register called VRSAVE
has been provided. When the operating system switches context, it saves only the registers
whose corresponding bit in the VRSAVE register has been set to one.
====================
159:Socket774
08/08/30 01:18:03 efBh6GPC
>>158
fiberは完全にソフトウェアで切り替えるので、切り替え時にliveなレジスタセットはコンパイラが完全に把握しているから
そういう機能は不要
AltiVecのはプリエンプティブなコンテクストスイッチをする場合に有用
160:Socket774
08/08/30 01:25:45 efBh6GPC
>>145
All instructions can issue on the primary pipeline, which minimizes the combinatorial problems for a compiler.
The secondary pipeline can execute a large subset of the scalar x86 instruction set,
including loads, stores, simple ALU operations, branches, cache manipulation instructions, and vector stores.
だってさ
161:Socket774
08/08/30 01:27:26 efBh6GPC
>>159
全然知らんのだが、AltiVecのレジスタに書き込むと、VRSAVEレジスタの対応するビットが自動的に1になるんだろ？
162:Socket774
08/08/30 01:51:29 efBh6GPC
>>105
> >>103←馬鹿だねこいつ。もうプしか言えないだろ。
団子の変な理解が端的に現れているところを挙げてみたんだが、確かにもうプププとしか言えないねww
163:Socket774
08/08/30 03:44:19 fZBNI9Ql
団子さんここにいたのか
プログラム板の連中が寂しがってたぞ
164:,,・´∀｀・,,
08/08/30 08:34:02 DThLhIVJ
FiberはマイクロOS上の実行単位じゃね？GPGPUとして使った場合の。
Xeonソケットに刺さるGPUじゃない方の、あるいは純粋なCPUとして使った場合の
プログラミングモデルはまだ示されてない気がする。
どっかの海外記事に普通(regular)のOSは容易に移植もしくはそのままで動くらしく、
マイクロOSとは別個のメモリ空間が割り当てられるとか書いてあった。
これはハイパーバイザで仮想マシンを複数サポートする方法があることを意味するかもしれない。
それってつまりVTもしくはそれ以上の仮想化機構をサポートするってことになるんだが。
165:,,・´∀｀・,,
08/08/30 08:44:05 DThLhIVJ
変な理解とは
・フェンス命令は一度パイプラインに入ったらリタイアするまでパイプラインをブロックし
たとえ前の命令が例外を起こした時でもパイプラインからフラッシュされないという思いこみ。
・前の制約により破棄可能なストアバッファリング機構が必要であるという思いこみ。
・SSEはLarrabeeではサポートせずx64非準拠になるという思いこみ。
アハハハハ
166:,,・´∀｀・,,
08/08/30 09:53:24 DThLhIVJ
城島「Intelに『standardな64ビット拡張』って言われてみて、どう思った？」
167:,,・´∀｀・,,
08/08/30 10:09:31 DThLhIVJ
ま、解ったなら、落とし前はつけような。
168:,,・´∀｀・,,
08/08/30 11:58:30 DThLhIVJ
つか、かの人はもう一つとんでもない思い違いをしてたかもわからんね。
ここで問題です。
パラメータに依存して複数サイクルかかるような複合タイプの命令を、
マイクロコードに置き換える機能があるのは次のうちどれでしょう？
1.デコーダ
2.実行ユニット
それ考えたら、シンプルデコーダ側でVPUのストア（思うにそれすら一部のみ）
だけしかデコードできない技術的理由は俺はなんとなく解ったよ。
169:,,・´∀｀・,,
08/08/30 12:02:11 DThLhIVJ
訂正
ここで問題です。
パイプラインにおいて、パラメータに依存して複数サイクルかかるような複合タイプの命令を、
マイクロコードに置き換える機能があるのは次のうちどれでしょう？
1.デコーダ
2.実行ユニット
170:Socket774
08/08/30 12:08:29 efBh6GPC
>>165
> ・フェンス命令は一度パイプラインに入ったらリタイアするまでパイプラインをブロックし
たとえ前の命令が例外を起こした時でもパイプラインからフラッシュされないという思いこみ。
フェンスを理解していないお前がおれの指摘を正しく理解できてないだけだろ…
以下同様
171:Socket774
08/08/30 12:11:59 efBh6GPC
>>168
> ここで問題です。
> パラメータに依存して複数サイクルかかるような複合タイプの命令を、
> マイクロコードに置き換える機能があるのは次のうちどれでしょう？
>
> 1.デコーダ
> 2.実行ユニット
>
何を言いたいんだろう
マイクロコードでもステートマシンでもいいわけだが、
団子頭では
複数サイクル命令==マイクロコードで実装
なんだろうか
172:Socket774
08/08/30 12:15:28 efBh6GPC
>>165
そうそう
> ・フェンス命令は一度パイプラインに入ったらリタイアするまでパイプラインをブロックし
> たとえ前の命令が例外を起こした時でもパイプラインからフラッシュされないという思いこみ。
おれがこういう主張をしているというのなら、該当箇所にアンカーふってくれ
今すぐ首吊ってやんよ
173:Socket774
08/08/30 12:17:41 efBh6GPC
>>172
おれが挙げた例は
「scatter命令が例外を起して、例外ハンドラに処理が移ってからフェンス命令を実行した場合」
だからね
この違いが理解できなかったんだね
174:Socket774
08/08/30 12:22:17 efBh6GPC
>>171
うん、やっぱり団子頭では
「複数サイクル命令は、マイクロコードで実装されなければならない」
ということになってるようだね
175:,,・´∀｀・,,
08/08/30 12:51:20 DThLhIVJ
やっぱりばかだね
ていうか
たとえばCPUIDの主作用である実行の本質知ってる？
EAXで指定した値を元に、デコーダにぶら下がってるマイクロコードROMを参照し、各汎用レジスタに即値ロードする内部命令に置き換えるんだが。
例のリコール騒ぎになったDIVのバグもマイクロコードのテーブルの誤りだったのは有名な話
LarrabeeがP5が土台ということはマイクロコードベースなんだよ。
というかP6以降はもっと極端で、Complex Decoder Pathを強制される命令は例外なくマイクロコードを参照する。
scatter/gatherに限ってマイクロコード実装にしないという理由がない。
むしろscatter/gatherにエラッタがあった場合
マイクロコードでなければROM更新ではなくリコールするしかない。
176:Socket774
08/08/30 12:57:12 efBh6GPC
>>175
はいはい
gather/scatterがマイクロコード命令でなかったら首吊ってれるかい？
177:,,・´∀｀・,,
08/08/30 13:03:11 DThLhIVJ
「SSEサポートだったら死ぬ」と明言し
x64準拠と判明しても見苦しく詭弁を
まき散らす行為を、君の定義で「死ぬ」というのなら
俺はそんなみっともない真似はお断りだ
178:Socket774
08/08/30 13:06:50 fCHg5zW2
>俺はそんなみっともない真似はお断りだ
団子さんからこんな言葉が聞けるなんて
ちょっと感動
179:Socket774
08/08/30 13:11:07 efBh6GPC
>>177
> x64準拠と判明しても
インテルのどの資料？
180:Socket774
08/08/30 13:12:49 efBh6GPC
>>177
> 俺はそんなみっともない真似はお断りだ
人気のないところで潔く首吊るか腹を切るかしてくれれば結構
電車などは迷惑がかかるからやめてね
181:,,・´∀｀・,,
08/08/30 13:16:17 DThLhIVJ
さーな、俺の情報筋はWebじゃねーし。
ソースの在処はMACオタにでも聞けよ
>>115って言ってることだし。
182:,,・´∀｀・,,
08/08/30 13:18:43 DThLhIVJ
これから死ぬ人間にやるような約束などないよ
最後までバカだったね
183:,,・´∀｀・,,
08/08/30 13:25:10 DThLhIVJ
とりあえずSSEをサポートしない64ビット拡張が未だかつて「standard」であったためしは無いからね。
AMD64/Intel64(EM64T)以外にないんだよ。
184:Socket774
08/08/30 13:29:39 efBh6GPC
>>181
> さーな、俺の情報筋はWebじゃねーし。
さすがに団子の妄想を根拠に首を吊るわけにはいかんからなあ
185:Socket774
08/08/30 13:31:15 efBh6GPC
>>182
> これから死ぬ人間にやるような約束などないよ
お、団子の敗北宣言か？
> scatter/gatherに限ってマイクロコード実装にしないという理由がない。
これが怪しいことに気づいたかな？
ほかの軒かな？
186:,,・´∀｀・,,
08/08/30 13:31:50 DThLhIVJ
じゃ、MACヲタの出したソースを根拠に死ね
187:Socket774
08/08/30 13:35:44 efBh6GPC
>>175
> scatter/gatherに限ってマイクロコード実装にしないという理由がない。
ごく一般的な物の考え方として、マイクロコードとステートマシンの二通り(と、その組み合わせ)がある場合には
それぞれの長所短所を考えるものだが、団子にはそんなことが念頭によぎった気配すらない
188:MACオタ＞団子 さん
08/08/30 13:36:07 rRKT6K+V
>>183
いまのところ>>96の意見なので、私を引き合いに出すのわ勘弁して欲しいす。
---------------------
とりあえずSSEをサポートしない64ビット拡張が未だかつて「standard」であったためしは無い
---------------------
この業界、自分に都合の良い部分だけ切り取って『業界標準』(industry standard)を名乗るのわ、
ありふれた話なんすけど。。。
189:MACオタ＞団子 さん
08/08/30 13:44:32 rRKT6K+V
>>175
補足すけど、これスカラ整数ユニット限定す。
-----------------
LarrabeeがP5が土台ということはマイクロコードベースなんだよ。
-----------------
躁状態になると騙りやらコピぺやら、何でもアリの相手すから、死ね死ね言わない方が良いと
思うすけどね。。。
190:,,・´∀｀・,,
08/08/30 13:46:33 DThLhIVJ
既存のIAでSSEのミスアラインドロード・ストア命令は例外なくマイクロコードだったな。
agner.orgにオペレーション数の解析結果まで載ってる。
複数回かかる仕様のロード・ストア命令がマイクロコード実装なのは
P5以降Intelアーキテクチャでは100％そうだし
逆に、実行ユニットで初めて分解するようなのはP5ベースではなく
新規のマイクロアーキテクチャということになってしまう。
実行ステージに突っ込むまでサイクル数が解らないオペレーションなんて、
スケジューラで管理しきれないしさ(笑
191:MACオタ＞団子 さん
08/08/30 13:49:23 rRKT6K+V
>>190
------------------
既存のIAでSSEのミスアラインドロード・ストア命令は例外なくマイクロコードだったな。
agner.orgにオペレーション数の解析結果まで載ってる。
------------------
複数のuopsに分解するという話と、マイクロコード実行わ『別物』でわ？
192:,,・´∀｀・,,
08/08/30 13:54:28 DThLhIVJ
＞MACオタ
君の解釈は聞いてないからただソースだけを貼ってくれ。
193:MACオタ＞団子 さん
08/08/30 13:58:46 rRKT6K+V
>>192
x86わ良く知らないんで質問しているすけど、何か痛い所を突かれて逆切れしたすか？
194:Socket774
08/08/30 13:59:14 efBh6GPC
>>192
> 君の解釈は聞いてないからただソースだけを貼ってくれ。
団子さんからこんな言葉が聞けるなんて
ちょっと感動
195:,,・´∀｀・,,
08/08/30 14:05:24 DThLhIVJ
>191
本質的同じものだよ。粒度が違うだけ。
IntelのいうマイクロオペレーションはP6で初めて使いだした言葉で、
マイクロコードに対してもっと粒度の小さいRISCライクオペレーションという意味。
複数マイクロオペレーション使う命令は必ずマイクロコードROMを参照する。
あ、PenM以降のμOPs Fusion可能なものだけは、一般デコーダでダイレクトにデコードできるけどね。
いずれにしても各実行ステージの手前で切り離す。
196:MACオタ
08/08/30 14:05:45 rRKT6K+V
妙に報道が少なかったHot Chips 20すけど、富士通の発表もあってか安藤氏わ参加していた
様す。とりあえず今日の更新わ、Larrabeeとr龍芯、3Leaf Systems社のネットワーク経由でのccNuma
の話題す。
URLﾘﾝｸ(www.geocities.jp)
ちなみに最後のわ、EDNのブログでも取り上げていたす。
URLﾘﾝｸ(www.edn.com)
197:MACオタ＞団子 さん
08/08/30 14:08:13 rRKT6K+V
>>195
----------------
本質的同じものだよ。粒度が違うだけ。
----------------
それでわ、何故マイクロコード実行わCRISCの概念より古いすか？
agner氏の資料を見れば明らかなように、単一のuopsで複数サイクル実行のモノもあるし。。。
198:,,・´∀｀・,,
08/08/30 14:16:45 DThLhIVJ
浮動小数のこと？
P5にはP6にあるようなfxchによる依存関係の解消の機構がないから
レイテンシがそのままサイクル数になってしまうだけだよ。
199:,,・´∀｀・,,
08/08/30 14:19:02 DThLhIVJ
ロードやストア回数が複数にわたる場合は必ずその回数分以上の
マイクロコードあるいはマイクロオペレーション数に分解されているはずだ。
200:,,・´∀｀・,,
08/08/30 14:21:29 DThLhIVJ
おっとrepは小さいループに変換されるだけだがな
201:MACオタ＞団子 さん
08/08/30 14:25:33 rRKT6K+V
>>198
----------------
P5にはP6にあるようなfxchによる依存関係の解消の機構がないから
----------------
P5にuops分解機能わ無いす。P6で複数サイクル実行のuopsを含む命令わ、
IMUL, AAM, DIV, IDIV, 複雑なFP命令(SSE含)す。
202:Socket774
08/08/30 14:29:48 efBh6GPC
>>199
ARMでもか？
203:MACオタ＠補足
08/08/30 14:33:09 rRKT6K+V
別にもったいをつけるつもりわ無いすけど、ハードウェアロジックでも複数のユニットを占有したり、
回帰計算を行うために複数サイクル必要な命令わ在るす。
おそらく現代的な設計のプロセッサで、実行ステージでマイクロコードROMを一々読んでプログラムを
実行するモノわ無いと思われるす。
命令に関するエラッタが存在したとしても、パッチわデコードユニットでトラップして代替命令に置き換
える程度じゃ無いすかね。
204:,,・´∀｀・,,
08/08/30 14:36:54 DThLhIVJ
たとえば
add eax,[edx]
を
分解せずに実行してたのがP5まででありいわゆる従来のCISC
ロードと加算に分解して実行するのがP6でありいわゆる内部RISCと言われるやつ。
その意味ではK7やPenM以降はCRISCって言っていいのかは疑問だな。まあ最終的には分解してるんだが。
205:,,・´∀｀・,,
08/08/30 14:51:06 DThLhIVJ
分解しないと実行できないような複雑命令はそもそも載せないのが
P&Hの理論にもあるような純RISCだったじゃね？
複雑な命令の実行をマイクロコードに頼ってたのはCISC
でも昔ながらのRISCをうたうCellですら倍精度はマイクロコードだったような。POWERには8バイト命令もあって、固定長ですらないしな。
CISC/RISC論は既に現代では通用しない。
206:Socket774
08/08/30 14:56:26 efBh6GPC
>>205
やっぱりマイクロコードとステートマシンの違いがわかってないようだ
207:Socket774
08/08/30 15:01:28 efBh6GPC
>>206
おっと、実行ユニットがマイクロコードを持っていることもあるから、正しく団子用語の
>>168
> パイプラインにおいて、パラメータに依存して複数サイクルかかるような複合タイプの命令を、
> マイクロコードに置き換える機能があるのは次のうちどれでしょう？
>
> 1.デコーダ
> 2.実行ユニット
208:,,・´∀｀・,,
08/08/30 15:27:17 DThLhIVJ
＞実行ユニットがマイクロコード
はい？
それいつの時代のどこのアーキテクチャですか？
もちろんIntelのP5以降のCPUの話ですよね？
パイプライン化すらされてない時代の話なら笑うしかないよ？
ま、どっちにしろ、まだExecuteにも達してないフェンス命令が前の命令の例外が起きてもパイプラインから棄てられないなんて
脳内動作の根拠にはならないんだが。
209:,,・´∀｀・,,
08/08/30 15:32:52 DThLhIVJ
まあ、こいつはおそらくP5以降のIntelアーキテクチャのブロックダイアグラムで
マイクロコードROMがどこにぶら下がってるか見たこともないんだろうな。
デコーダで解決した方がデコード後のスケジューリングコストがかからないんだけどな。
210:Socket774
08/08/30 15:46:12 efBh6GPC
>>208
> ま、どっちにしろ、まだExecuteにも達してないフェンス命令が前の命令の例外が起きてもパイプラインから棄てられないなんて
> 脳内動作の根拠にはならないんだが。
そりゃこんなこと言ってるの団子だけだし
おれが言ってるのは「例外ハンドラ内で」フェンス命令を実行した場合
211:,,・´∀｀・,,
08/08/30 15:51:03 DThLhIVJ
＞例外ハンドラ内で
バカすぎる
なんの目的で使うんだよ
お前プログラム組んだことないだろ
212:,,・´∀｀・,,
08/08/30 15:58:26 DThLhIVJ
あ、例外発生前にパイプラインに投入されたフェンス命令が例外後も残ってるなんてのは論外な
213:272
08/08/30 16:06:43 efBh6GPC
>>211
> ＞例外ハンドラ内で
> バカすぎる
> なんの目的で使うんだよ
あっ、団子は例外ハンドラがどういうものか理解してなかったんだよな、ゴメンゴメン
例外が発生した後は、どうしても
・共有データであるところのページテーブルを更新したり
・ページインのためにI/Oを開始
したりするんだぜ？
バカでもわかりやすいかと思って「例外ハンドラ内で」というシチュエーションを考えたけど、逆効果だったかな
例外ハンドラから抜けてからフェンス命令を発行しても同じこと
中断したscatterの扱いはどうなるの？
214:,,・´∀｀・,,
08/08/30 16:13:35 DThLhIVJ
余談だけど、ノンテンポラルストアはLarrabeeにおいてはキャッシュプライオリティモデル
おける優先度最低のそのまた下と位置付ければ、
プライオリティモデルに基づく既存プロトコルの延長でL1をスルーする動作を実現できるかもしれないね。
実装次第ではフェンス命令はNOP扱いしてよくなる。
215:Socket774
08/08/30 16:20:58 efBh6GPC
>>214
上半分もトンチキだが
> 実装次第ではフェンス命令はNOP扱いしてよくなる。
まーだこんなこと言ってやがんの
プププのプ
216:,,・´∀｀・,,
08/08/30 16:24:30 DThLhIVJ
＞例外ハンドラ
昔は知らんが最近はC++/javaでいうcatchブロックなんかののことを言う。
現行32ビットアーキでは復帰可能なページフォルトはCPU内で解決される。
OS→アプリに通知されるのは無効命令やアクセス違反など続行不可能なもの。
何年もののバカだよ
217:,,・´∀｀・,,
08/08/30 16:27:39 DThLhIVJ
まあ#PFが飛んでくる条件なんて32ビットOSのソースもさわったことないおっさんには解らんだろうがな
レベル低すぎる
218:,,・´∀｀・,,
08/08/30 16:33:15 DThLhIVJ
まさかリアルモードでSSE使おうとか思ってねーよな？
219:Socket774
08/08/30 16:38:31 efBh6GPC
>>216
団子はちゃんと答えてくれるんで好感度は高いが
> ＞例外ハンドラ
> 昔は知らんが最近はC++/javaでいうcatchブロックなんかののことを言う。
一般的に例外ハンドラというのは、CPUが例外を起したときに、例外ベクトルテーブルを参照して飛んでいく先のこと
団子も説明も嘘ではないけど、文脈的におかしいんだわ
x86だと、IDTで例外ベクトルテーブルを指定してたっけ
インテルのマニュアルにも例外ハンドラの説明あると思うよ
> 現行32ビットアーキでは復帰可能なページフォルトはCPU内で解決される。
それはページミスの説明
> OS→アプリに通知されるのは無効命令やアクセス違反など続行不可能なもの。
ページフォールトは、こちらの続行不可能なものに入る
これでは話が通じないわけだ
220:,,・´∀｀・,,
08/08/30 16:43:26 DThLhIVJ
だからOSのソースも読まずに妄想ほざいてろ。
どこに例外拾って*fenceを呼ぶ実装があるんだよ。
Linuxカーネルのソースでもgrepして引っかからないのを確認して
そして即刻氏ね
221:Socket774
08/08/30 16:50:11 efBh6GPC
一番シンプルな説明だと
TLBにヒットしない→ページミス
ページミスすると、CPUが自動的にページテーブルを参照して、必要なページテーブルエントリを探す
必要なページテーブルエントリがない場合→ページフォールト
ページフォールトが発生すると、CPUは例外テーブルを参照して、(通常はOS内の)例外ハンドラに制御がうつる
222:,,・´∀｀・,,
08/08/30 16:51:32 DThLhIVJ
はい、その時点で復帰不可能だよ。
223:Socket774
08/08/30 16:53:11 efBh6GPC
>>222
復帰不可能というのをどういう意味で使っているのかがわからんのだが
少なくとも半分は正しい
とりあえず>>221を理解して、
> 現行32ビットアーキでは復帰可能なページフォルトはCPU内で解決される。
これを撤回してくれるかな？
224:,,・´∀｀・,,
08/08/30 16:54:22 DThLhIVJ
めんどいからLinuxカーネルソースでいうどこのコードの何行目でやってるか引用してみろ。
225:Socket774
08/08/30 16:58:04 efBh6GPC
>>224
お前さんが一般論が苦手なのは知っているが、説明のためのただの一例に、そのまでするのはやなこった
226:,,・´∀｀・,,
08/08/30 16:58:05 DThLhIVJ
OSに飛ぶ段階で既にOSがフェンスを呼ぶ必要はない。
それとも、キャッシュをバイパスして例外ハンドラのコードをフェッチできるんか？
227:Socket774
08/08/30 17:00:37 efBh6GPC
>>226
> OSに飛ぶ段階で既にOSがフェンスを呼ぶ必要はない。
なんか妙なこだわりがあるな
ページフォールトを起こした命令と、OS内(でもどこでも)のフェンス命令は、無関係だよ
ページフォールトが「起きたから」、フェンスを呼ぶ必要があると捉えているなら、間違いだ
228:Socket774
08/08/30 17:03:06 efBh6GPC
アプリプログラマの団子とは縁のない命令だが、iretにはそもそも逐次化作用があるんだけど、忘れてたのかな？
229:Socket774
08/08/30 17:05:19 DThLhIVJ
OSがトラップする前にCPUは自分自身である程度の後始末はすんでる。
とりあえず例外ハンドラの実装読んでみろと。
読まないことには始まらない。
230:,,・´∀｀・,,
08/08/30 17:07:25 DThLhIVJ
俺が指摘するまでCPUIDのフェンス効果も知らなかったバカがなんか言ってるよ
231:Socket774
08/08/30 17:08:43 efBh6GPC
>>229
> OSがトラップする前にCPUは自分自身である程度の後始末はすんでる。
どういう例外の場合にはどういう処理をするのかな？
ニヤニヤ
232:,,・´∀｀・,,
08/08/30 17:13:59 DThLhIVJ
Intelが64ビット拡張が「standard」であることを示すソースを未だに探せない頭の悪い子にはうまく説明する自信がないな。
ヒント：今年で20回目
233:Socket774
08/08/30 17:15:50 efBh6GPC
>>232
話を逸らさなくても優しくしてやるから、ページミスとページフォールトの違いについては理解できたかな？
234:,,・´∀｀・,,
08/08/30 17:16:23 DThLhIVJ
ていうか>>113
235:,,・´∀｀・,,
08/08/30 17:20:47 DThLhIVJ
まあトラップの仕組みはまあいいよ。ミスした命令を再実行すればいいじゃん。
どう考えても破棄可能なバッファは必要ないね。
236:Socket774
08/08/30 17:21:53 efBh6GPC
>>234
Plus standard 64-bit instruction extensions
は
Plus Intel64(R) instruction extensions
じゃないよね？
237:Socket774
08/08/30 17:24:19 efBh6GPC
>>235
> まあトラップの仕組みはまあいいよ。ミスした命令を再実行すればいいじゃん。
誤ちを認めてくれるのは結構なこった
が、気軽に
> ミスした命令を再実行すればいいじゃん。 どう考えても破棄可能なバッファは必要ないね。
こんなことを言ってくれるようでは困る
238:,,・´∀｀・,,
08/08/30 17:26:27 DThLhIVJ
で、なんで二度書きしたら困るんだ？ﾆﾔﾆﾔ
239:Socket774
08/08/30 17:27:39 efBh6GPC
>>238
アプリプログラマの知らなくていいことだけど、I/Oなんかの都合上とてもまずい
240:,,・´∀｀・,,
08/08/30 17:28:09 DThLhIVJ
>>236
どこにx64以外のstandardがあるんですか？バカですか？
だからとっとと死ね
241:,,・´∀｀・,,
08/08/30 17:30:30 DThLhIVJ
I/Oの都合がある処理でSSEなんて使わないから。ハイハイ
242:,,・´∀｀・,,
08/08/30 17:33:43 DThLhIVJ
むしろ規格準拠くらいの意味だな
243:Socket774
08/08/30 17:39:08 efBh6GPC
>>241
> I/Oの都合がある処理でSSEなんて使わないから。ハイハイ
団子の大好きなインテルのマニュアルに、I/O領域に対するメモリアクセス禁止って書いてあるの？
244:,,・´∀｀・,,
08/08/30 17:42:58 DThLhIVJ
＞I/O領域
ハードウェア予約領域のことか？
そもそもアプリじゃさわりませんｗｗｗ
245:Socket774
08/08/30 17:47:00 efBh6GPC
>>244
アプリプログラマに聞く質問じゃなかったサーセン
246:,,・´∀｀・,,
08/08/30 18:01:52 DThLhIVJ
ライトコンバインなんてカーネルモードですらやんねーよ普通
マルチスレッドなんぞ論外だし
247:,,・´∀｀・,,
08/08/30 18:09:27 DThLhIVJ
カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。
248:MACオタ＠補足
08/08/30 19:32:01 rRKT6K+V
>>247で団子さんの書いているのわ、この話題す。(ということで良いすか？)
URLﾘﾝｸ(www.nabble.com)
249:Socket774
08/08/30 19:54:26 efBh6GPC
>>248
どっちにしろ、おれの出した話題とは何の関係もないのだが
> >>247で団子さんの書いているのわ、この話題す。(ということで良いすか？)
これが本当なら、
団子> カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。
One problem that has not been resolved yet, AFAIK, is how to handle the
possible use of YMM registers in device drivers. Should these registers
be saved before calling a device driver from an interrupt or should it
be the responsibility of the device driver?
250:,,・´∀｀・,,
08/08/30 20:02:01 DThLhIVJ
聞いてない。
x86の64ビット拡張の「standard」とは何ですか？
さっさとけじめつけろや、ｺﾞﾙｧ
251:Socket774
08/08/30 20:06:02 efBh6GPC
>>250
インテルがIntel64(R)でなくstandardとしか言ってない以上、わかるかボケ
252:Socket774
08/08/30 20:06:59 efBh6GPC
>>250
んで、
団子> カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。
のソースは>>248でいいのか
いいわきゃないよな？こんな恥かしい間違いわ
253:,,・´∀｀・,,
08/08/30 20:14:00 DThLhIVJ
standardがx64以外にあるかボケ
詭弁も甚だしい
結論から言ってカーネルモードで使えるけど保証はないのはガチ。
254:Socket774
08/08/30 20:15:59 efBh6GPC
>>253
団子> カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。
誰がどこから何という回答を貰ったのかな～？
Agnerという人は"One problem that has not been resolved yet"って言ってるよ
255:Socket774
08/08/30 20:18:24 efBh6GPC
>>253
おっと
> 結論から言ってカーネルモードで使えるけど保証はないのはガチ。
「保証はないのはガチ」ってねえ、>>248のリンク先ちゃんと読んだの？
memcpyのあたりだよ
256:Socket774
08/08/30 20:19:42 efBh6GPC
>>255
3. When compiling a device driver, the compiler may insert implicit
calls to library functions such as memcpy and memset. These functions
typically have a CPU dispatcher that chooses the largest register size
available. The device driver may therefore use YMM registers without the
knowledge of the programmer and without compiling with the AVX switch on.
257:,,・´∀｀・,,
08/08/30 20:19:53 DThLhIVJ
「死人」には黙ってて貰いたい。ゾンビくん。
俺は一切回答もしないよ。
それとも未だにx64非準拠の確信(笑)あるのかな
単に生きたいだけかな？ｗｗｗ
258:Socket774
08/08/30 20:23:08 efBh6GPC
>>257
> 俺は一切回答もしないよ。
まあ、これ以上何か言ったところで恥の上塗りだから、それがいいと思うよ
> カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。
団子の英語力からすれば>>248を理解できなかったは不思議ではないが、これは許してやんよ
まさかお前の妄想に箔をつけるためにAgner氏の名前をデッチ上げたんじゃないだろうな
259:Socket774
08/08/30 20:24:02 0ZjjQu1D
で、ローエンドGPUのlarrabeeでXが使えるようになると
何が面白いのかね
260:,,・´∀｀・,,
08/08/30 20:25:40 DThLhIVJ
生き恥がなんか言ってるよｗｗｗ
ま、ライトコンバインなんかまともに動く保証はないんじゃね？
261:Socket774
08/08/30 20:28:09 efBh6GPC
>>260
今なら白状しても許すよ
「わたくしこと団子は、Agner氏の名前で大嘘をデッチあげました」
> ま、ライトコンバインなんかまともに動く保証はないんじゃね？
SSE完全互換じゃなかったの？？
262:Socket774
08/08/30 20:29:51 efBh6GPC
団子> カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。
Agner> One problem that has not been resolved yet, AFAIK,
Agner> is how to handle the possible use of YMM registers in device drivers.
263:,,・´∀｀・,,
08/08/30 20:39:01 DThLhIVJ
＞Xが使える
生き恥のさらに上塗りだな。
「X」なんてVESA準拠のカードなら専用ドライバなんてなくても使えるよ。
GPUの機能使わずフレームバッファに直に書くだけならな。
PS3のLinuxもRSXのドライバは用意されてない（アクセスすら禁止されてる）がGNOMEが普通に立ち上がる。
ま、OpenGLのドライバが使えるのは有意義だよ。かなり。
ぶっちゃけMS環境自体にはあまり期待できないんだよ。
メニーコア周りのサポートとか。
未だに上限32or64スレッドまでしか使えないし。
その点、IntelコンパイラもLinux版は無償で使えるからな。
264:Socket774
08/08/30 20:42:21 0ZjjQu1D
だからそれの何が面白いことになったの？
発言者さん
265:Socket774
08/08/30 20:44:14 efBh6GPC
Larrabeeでlinuxを動かして、本体CPUをXアクセラレータにして遊ぶ
266:Socket774
08/08/30 20:48:09 4mz2eK7O
x用のドライバが出来ても
OpenGLが使えるかどうかってのは
また別なはなしだが
267:,,・´∀｀・,,
08/08/30 20:49:17 DThLhIVJ
専用ドライバなしでもWindowsすら動くしな
死ぬほど遅いけどww
よりにもよって「Xが動く」ｗｗｗｗｗｗ
ドライバすらいらねーっつーのｗｗｗｗｗｗ
268:,,・´∀｀・,,
08/08/30 20:50:22 DThLhIVJ
>>266←ｗｗｗｗｗｗ
269:Socket774
08/08/30 20:51:21 efBh6GPC
おい団子、他の人に迷惑かけるな
団子> カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。
これのソースはどこなんだよ
270:,,・´∀｀・,,
08/08/30 20:53:44 DThLhIVJ
MACヲタに代理回答なんて頼んだ覚えはないが。
ま、推奨か非推奨かはIntelのマニュアルにもあることだな
271:,,・´∀｀・,,
08/08/30 20:56:20 DThLhIVJ
死人は棺桶のなかでおとなしくしてて下さい。
書き込むだけで迷惑ｗｗｗｗｗｗ
Intelがｗｗｗｗｗｗ
Larrabeeでｗｗｗｗｗｗ
SSEをｗｗｗｗｗｗ
サポートしたくないｗｗｗｗｗｗ
272:,,・´∀｀・,,
08/08/30 20:58:45 DThLhIVJ
「IntelはSSEをサポートしたくない」のソースをお願いします。
他人にソースを求める立場ではないの自覚しような
273:Socket774
08/08/30 21:01:25 NI1xX8WB
x.orgのドライバーだけでGLXが動くと思ってる馬鹿がいるな
仕様を公開してるATIやVIAならともかく・・
274:,,・´∀｀・,,
08/08/30 21:02:28 DThLhIVJ
フェンス命令に中途半端に完了
のソースまだー？
死人に無知鬱
275:MACオタ＞269 さん
08/08/30 21:04:51 rRKT6K+V
>>269
---------------------
団子> カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。
これのソースはどこなんだよ
---------------------
英語が読めないのか、groups.google.com型のサイトの読み方が判らないのかどちらかだと思うすけど、
>>248のリンク先にわ、intelのArjan van de Ven氏から次のような回答が寄せられているす。
======================
Let me repeat this loud and clear:
It is not allowed to use floating point, SSE of AVX in device drivers.
======================
ちなみに団子さんと同じ資料を読んでも、私が>>96のような意見なのわレガシーなx86コードの大半が
Linuxカーネルと同じ状況だからす。
276:Socket774
08/08/30 21:06:40 CvxpbjGE
団子は何か勘違いしている
おれのは予想で、出しているのは傍証
証拠もないのに事実だと決めつけているのはお前だけだ
予想と事実、傍証と証拠の違いくらいわかるよな？
277:MACオタ＠補足
08/08/30 21:06:45 rRKT6K+V
Arjan van de Ven氏の身分の参考に。
URLﾘﾝｸ(www.linuxjournal.com)
-------------------
Linux Journal recently caught up with Intel's Arjan van de Ven. Van de Ven leads Intel's green
Lesswatts.org initiative and is the developer of PowerTOP, one of the most acclaimed power
management tools on the Linux platform.
-------------------
278:,,・´∀｀・,,
08/08/30 21:09:05 DThLhIVJ
GLXｗｗｗｗｗｗ
つかOpenGL自体プログラミングスタックにあるし。
IntelがLinux環境に好意的なのは有名な話だしな。
AtomベースMIDのSDKはLinux版以外あったっけな
279:,,・´∀｀・,,
08/08/30 21:12:03 DThLhIVJ
「Standard」の意味が解らないと見苦しい事を言ってる馬鹿ならいるな
280:,,・´∀｀・,,
08/08/30 21:17:29 DThLhIVJ
standard 64-bit extensionの意味も解らないって素敵だね。
英語がわからないから約束守る必要ないなんて理屈がまかり通るなら
英語知らない方がいいようだな
281:,,・´∀｀・,,
08/08/30 21:19:18 DThLhIVJ
standard 64-bit extensionにフェンス命令は含まないんですか？
Intelは含めたくないんですか？
282:,,・´∀｀・,,
08/08/30 21:21:40 DThLhIVJ
P5アーキがデコーダでマイクロコードに展開するという常識もない人間に傍証も糞もない
詭弁とこじつけだけ
283:Socket774
08/08/30 21:22:24 0ZjjQu1D
はいはーい、またまた精神破綻者の独り言の始まり始まり
284:,,・´∀｀・,,
08/08/30 21:26:53 DThLhIVJ
あ？精神病がなんか言ってるよ
死ぬって言って死なないのはメンヘル女の特権だぞボケ
男ならけじめつけろや
285:Socket774
08/08/30 21:32:29 CvxpbjGE
>>275
続きがあったのは気づかなかったが
Arjanとケンカしてんじゃん
Andiの指摘までAgnerは納得してない
だいたいこれ、Linux固有の話しじゃん
一般論のできない君らとはいえ、こいつぁひどい
286:,,・´∀｀・,,
08/08/30 21:36:02 DThLhIVJ
P5のマイクロコードがデコーダから供給されることも知らない人の一般論には
説得力があるな
287:Socket774
08/08/30 21:42:24 CvxpbjGE
>>286
捏造するのはヤメテ
罵倒するときはアンカーつけて
288:,,・´∀｀・,,
08/08/30 21:47:28 DThLhIVJ
AMD64/Intel64はx86の64ビット拡張のstandardでない
ですね、わかります
289:,,・´∀｀・,,
08/08/30 21:51:28 DThLhIVJ
SSEやCPUIDを排除してLNIをサポートしたのを64ビット新標準にすればいいですね、わかります
290:Socket774
08/08/30 21:52:44 CvxpbjGE
>>288
十分条件と必要条件の区別のつかない団子らしい発言です
291:Socket774
08/08/30 21:56:36 CvxpbjGE
>>289
CPUIDを実装しないなんて一言も言ってないが
他人を罵倒するために捏造するのはやめて
292:Socket774
08/08/30 21:57:06 lAKSJLJJ
確かに288は頭の悪すぎる発言だなw
293:Socket774
08/08/30 21:59:23 CvxpbjGE
捏造しているのか、理解できていないのかはともかく、
罵倒するときはアンカーかコピペたのんます
294:,,・´∀｀・,,
08/08/30 22:01:24 DThLhIVJ
x86アーキにおいてスタンダードな64ビット拡張であるにはx64準拠は必要条件。
x64準拠であることはSSEサポートの十分条件。
ですね、わかります。
わかったら氏ね
295:,,・´∀｀・,,
08/08/30 22:03:59 DThLhIVJ
standardであることとSSEをサポートしないことは「矛盾」
296:,,・´∀｀・,,
08/08/31 01:25:06 AQd+hwdB
完璧であったはずの論理が覆されたのはどう思った？
297:,,・´∀｀・,,
08/08/31 02:01:44 AQd+hwdB
前提に誤りがあると微塵も思わないんだもんなー
固定観念に縛られすぎて常識とずれてしまってることは自覚しような。
298:,,・´∀｀・,,
08/08/31 09:11:17 AQd+hwdB
「ページフォールト時のスワップ処理」
→ビデオカードにはそもそもスワップできるデバイスなんて載らないよ。フローなんて復帰できるわけがないよ。
あとHPC版はメモリ馬鹿みたいに積むからなあ。スワップ？なにそれおいしいの？
ま、スワップアウトありでいいや。でも
「ページ解決後に2度書きするのイクナイ！」
→なんならプログレスカウントに汎用レジスタでも使う仕様にすれば？
たとえば1ビット×16でストア対象要素を指定し、正常完了したものから対応するビットにマスクをかける。
最終的に0またはFFFFになる。そうすれば途中中断しても復帰できるよ。
スカラとベクタは並列実行できるし。
「メモリコンシステンシモデルを緩める必要がある」
→だからそうすればいいじゃん。フェンス命令の実装関係ない。
「SSEは非対応。x64とは非互換になる」→Intelは標準の64ビット拡張と言ってはりますよ。どこにそんな標準があるんですか？
299:,,・´∀｀・,,
08/08/31 10:13:18 AQd+hwdB
ま、せっかくだから「ぼくのかんがえたさいきょうのめいれい」書いておくか。ま、我ながらいかにも「Intelアーキらしい」仕様だな
vscatvps [mem32],zmm1,zmm2
[mem]：起点アドレス
zmm1：ストアデータ
zmm2：アドレスのオフセット×16
ecx：下位16ビットで処理するビットのマスクを指定。ストア毎に順次要素に対応するビットをマスクしていく。
これもあくまで一案だが、デコーダのマイクロコードで実装するから可能な仕様だな。
VPU実行ステージでマイクロコード分解するなんてIntelが経験したことない珍妙な仕様じゃ不可能だよね。
ストリング命令同様、スワップを挟んでも復帰できる仕様は満たせる。
ま、俺も彼の言い分を理解してなかったのは認める。
カーネルソース読んでみて言いたいことの意味分かったよ。
俺もスワップなんて想定してるとは想定外だったからね。
ビデオカードにHDDでも接続するなんて発想はなかったからさｗｗｗ
HPC版じゃスワップなんて普通させないくらいメモリ積むだろうし。
300:Socket774
08/08/31 14:35:28 K6NM5XfT
WDDM2.0からVRAMをスワップアウトするようになったはずだけど
301:MACオタ
08/08/31 16:12:55 Ng1mcTQb
今回のネタでbinutilsのソースが引用されたついでにPOWER7のVSX ISAの公開部分について
調べてみたす。
- 命令フォーマット
XX1(引数1)とXX3(引数3)のフォーマットの存在が確認。4引数の命令が無いため、積和や
vector permute命令わ、ソースを上書きする？
- データ形式
今のところ8-byte x 2データ以外の言及わ無し
- 命令 (XT/XS/XA6/XB6: VSXレジスタ, RA/RB, 汎用レジスタ)
lxvd2x XT, RA, RB (Load Floating-Point Double X-Vecor Indexed X-form?)
RAとRBの和で求められる実効アドレスから2つの倍精度浮動小数点データをXTにロード
lxvd2ux XT, RA, RB (Load Floating-Point Double X-Vecor with Update Indexed X-form?)
RAとRBの和で求められる実効アドレスから2つの倍精度浮動小数点データをXTにロード後、
RAに実効アドレスを格納
stxvd2x XS, RA, RB (Store Floating-Point Double X-Vector Indexed X-form?)
RAとRBの和で求められる実効アドレスへXSの内容(double x 2)をストア
stxvd2ux XS, RA, RB (Store Floating-Point Double X-Vector with Update Indexed X-form?)
RAとRBの和で求められる実効アドレスへXSの内容(double x 2)をストア後、RAに実効アドレス
を格納
xxmrghd XT6, XA6, XB6 (X-Vector Marge High Floating-Point Double?)
XA6の上位倍精度浮動小数点データとXB6の上位倍精度浮動小数点データを並べてXT6に格納
xxmrgld XT6, XA6, XB6 (X-Vector Marge Low Floating-Point Double?)
XA6の下位倍精度浮動小数点データとXB6の下位倍精度浮動小数点データを並べてXT6に格納
xxpermdi XT6, XA6, XB6, DM (Permute Floating-Point Double Immediate?)
XA6とXB6の倍精度浮動小数点ベクトルを2bitのDMフィールド表現に従って並び替えてXT6へ
格納
xvcpsgndp XT6, XA6, XB6 (X-Vector Copy Sign of Floating-Point Double?)
XB6の倍精度浮動小数点ベクトルを符号ビットのみXA6からコピーして、XT6へ格納
302:MACオタ＠補足
08/08/31 16:36:43 Ng1mcTQb
"xxpermdi"命令すけど、DMフィールドが4-bitなら曲がりなりにもvector permuteっぽい動作に
なるすけど、何故か2-bitの模様す。単なるコピーとやsplat命令、"xxmrghd", "xxmrgld"命令と組み
合わせて全16通りをカバーするのかもしれないす。
でも、これ並べ替えをレジスタの内容でダイナミックに変更できるAltivecのvperm命令と比較すると
命令や直値で指定するのって、何か意味があるすかね？