CPUアーキテクチャについて語れ Part.12
- 1 名前：Socket774 ：2008/08/28(木) 09:48:14 ID:vX5clrui
- おいお前らいい加減、無能なAMD房・Intel房・GKに振りまわされず、
エンコ時間がどうとかPIがどうとかPS3がどうとかじゃなく、
CPUコアのアーキテクチャについて語りましょう。
x86/RISC/CISC/スーパースカラ/VLIW/MIMD/SIMD
等について語ってもよし、
各SPUの汎用レジスタ128本のCell B.E.マンセー、
x86なワンチップスパコンのLarrabeeマンセー、
時代はGPGPUだ！、Sunは漢の浪漫！、龍芯(笑)、
昔々8086の時代は(以下略・・・等もよし。
さあ、不毛な争いを止めてCPUアーキテクチャについて語ろう！
前スレ
CPUアーキテクチャについて語れ 11
http://pc11.2ch.net/test/read.cgi/jisaku/1214999146/l5
【過去スレ】
Part 1 http://pc5.2ch.net/test/read.cgi/jisaku/1082357989/
Part 2 http://pc7.2ch.net/test/read.cgi/jisaku/1101041110/
Part 3 http://pc7.2ch.net/test/read.cgi/jisaku/1139046363/
Part 4 http://pc7.2ch.net/test/read.cgi/jisaku/1151732227/
Part 5 http://pc9.2ch.net/test/read.cgi/jisaku/1159238563/
Part 6 http://pc9.2ch.net/test/read.cgi/jisaku/1169393906/
Part 7 http://pc11.2ch.net/test/read.cgi/jisaku/1172923824/
Part 8 http://pc11.2ch.net/test/read.cgi/jisaku/1178140550/
part 9 http://pc11.2ch.net/test/read.cgi/jisaku/1186887760/
part10 http://pc11.2ch.net/test/read.cgi/jisaku/1202913839/
part11 http://pc11.2ch.net/test/read.cgi/jisaku/1214999146/
自作板CPU系スレッド 現行スレ案内＆過去ログ保存サイト
http://cpu.jisakuita.net/
- 2 名前：Socket774 ：2008/08/28(木) 09:50:30 ID: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 名前：,,・´∀｀・,, ：2008/08/28(木) 09:53:25 ID:vX5clrui
- つか「Cell B.E.」って書こうとしたら間違えたし
- 4 名前：Socket774 ：2008/08/28(木) 12:48:00 ID:Xw90vCMb
- 12スレ目にもなると流石に飽ーきてくっちゃ、ダーリン
- 5 名前：Socket774 ：2008/08/29(金) 01:45:30 ID:Yk6PbdtE
- これもテンプレにしたほうがいいな
--
fenceってのは、ストア1が完了したことを別のストア(ストア2)で他のプロ
セッサお知らせしたりするようなときに二つのストアの間に置くものだよ。
このとき、、
つまり、ストア1とストア2のアドレスは別。他のプロセッサがロードによっ
てストア2への書き込みを知った後、ストア1の結果を読み取ろうとしたと
き、それがメモリシステムのごたごたによってまだ読めなかったりすると
困る。
そんなことが無いように保証するのがfenceの役割。
- 6 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 01:46:22 ID:XA+DpWi/
- 中途半端に完了させるのがフェンスの役割だろ。
いまさらまともなこというな
- 7 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 01:47:29 ID:XA+DpWi/
- これもテンプレ追加で
595 名前：Socket774[sage] 投稿日：2008/08/25(月) 01:15:00 ID:O2J1PAxv
>>590
> メモリコンシステンシ遵守で走ってるときは1命令が完了するまで次の命令はフェッチできない。
どうしてそう性能を落したがるのかなあ
- 8 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 01:51:11 ID:XA+DpWi/
- どうしてそう性能を落したがるのかなあ
どうしてそう性能を落したがるのかなあ
どうしてそう性能を落したがるのかなあ
どうしてそう性能を落したがるのかなあ
データに信頼がなくなるからです
- 9 名前：Socket774 ：2008/08/29(金) 02:01:02 ID:Yk6PbdtE
- これもテンプレ
--
> フェンス命令をしないといけないのはアクセスするアドレスが重なるときだよ。やっぱり君は解ってないな。
これは「間違い」
- 10 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:03:52 ID:XA+DpWi/
- 488 名前：Socket774[sage] 投稿日：2008/08/24(日) 16:48:54 ID:dxY2QGlA
>>486
> HPC用に用意されるソケット版はXeonとプラットフォーム互換で、QPIで相互インターコネクトされる。
だからそれはLarrabeeじゃねえって何度も言ってるだろ
- 11 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:04:42 ID:XA+DpWi/
- x64非互換な脳内Larrabeeの話はよそでどうぞ
完全準拠は確定してます。
- 12 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:06:33 ID: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 ：2008/08/29(金) 02:15:22 ID:Yk6PbdtE
- どうした団子、勇ましく>>5を否定したらどうだ
- 14 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:16:20 ID:XA+DpWi/
- ところでさ、面白いもの見つけたんだがｗｗｗｗ
中途半端にフェンスに完了させられる（笑）ってのはこんなニーモニックの命令かね？
↓
vscatvps/vscatvpd/vpscatvb/vpscatvw/vpscatvd
ククククク
お前は死ぬよ。確実に。
- 15 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:16:47 ID:XA+DpWi/
- >>13
否定しないよ。ようやく解ったようだね。
- 16 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:17:56 ID:XA+DpWi/
- ただ、フェンス命令があってはならない理由って結局何なんだね？
何かわからないけど他に互換でない要因があるに違いない
と思い込みたい状態？
- 17 名前：Socket774 ：2008/08/29(金) 02:19:06 ID:Yk6PbdtE
- んじゃ、これも否定してくれ
団子> フェンス命令をしないといけないのはアクセスするアドレスが重なるときだよ。やっぱり君は解ってないな。
- 18 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:20:31 ID:XA+DpWi/
- 488 名前：Socket774[sage] 投稿日：2008/08/24(日) 16:48:54 ID:dxY2QGlA
>>486
> HPC用に用意されるソケット版はXeonとプラットフォーム互換で、QPIで相互インターコネクトされる。
だからそれはLarrabeeじゃねえって何度も言ってるだろ
これ撤回するならな。
いい加減Larrabee＝EM64T準拠を認めてくれよ
- 19 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:23:12 ID:XA+DpWi/
- >>17
で、スキャタ命令は、フェンス命令をせずにどうやってコンシステンシを守るんだい？
後続命令からのメモリ汚染をどうやって防ぐの？
君の仮想世界に存在する脳内Larrabeeの話はいいから
- 20 名前：Socket774 ：2008/08/29(金) 02:23:18 ID:Yk6PbdtE
- >>18
やなこった
んで、まだ
団子> フェンス命令をしないといけないのはアクセスするアドレスが重なるときだよ。やっぱり君は解ってないな。
こんなアホみたいな主張を続けるのか
- 21 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:24:16 ID:XA+DpWi/
- 20 名前：Socket774[sage] 投稿日：2008/08/29(金) 02:23:18 ID:Yk6PbdtE
>>18
やなこった
現実から逃げるなｗｗｗｗ
- 22 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:24:42 ID:XA+DpWi/
- >>20
撤回済みだけど前スレで
- 23 名前：Socket774 ：2008/08/29(金) 02:25:54 ID: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 ：2008/08/29(金) 02:26:46 ID:Yk6PbdtE
- >>22
本当に撤回してたんならアンカー出してコピペしてくれよw
- 25 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:26:53 ID:XA+DpWi/
- キャッシュライン管理の特性上、確実に汚されない組み合わせが存在するのも事実だよ
でも君が指定したあのアドレス指定だと普通セグメンテーションフォルトだからどのみちフェンスの必要がない。
絶対アドレス指定であれはありえない。
- 26 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:27:51 ID:XA+DpWi/
- 先生！ID:Yk6PbdtEはLarrabeeがEM64T準拠でないといってます。
- 27 名前：Socket774 ：2008/08/29(金) 02:27:53 ID:Yk6PbdtE
- ついでにおれが最初から正しくフェンス命令の動作を理解していたのも認めるかね？
- 28 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:28:11 ID:XA+DpWi/
- 最初から誤解してた
- 29 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:29:24 ID: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 ：2008/08/29(金) 02:29:46 ID:Yk6PbdtE
- 団子はフェンスの動作を完全に誤解していたが、いまとけつつある？
おれは最初から完全に正しい動作を説明していた
これでOK?
- 31 名前：Socket774 ：2008/08/29(金) 02:32:57 ID:Yk6PbdtE
- フェンスの動作を全く理解していなかったことを認めざるを得ない団子がファビョッて
なんの関係もないレスを、しかもコメントを何もつけられずにコピペするだけで
難局を乗り切ろうと足掻く様は愉快だな
- 32 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:33:42 ID:XA+DpWi/
- SSEは厳しいモデルだと言ってた奴がフェンス命令の仕様を理解しているわけがない。
CPUIDにフェンスの効果があることすら知らなかったんだからな
- 33 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:35:05 ID:XA+DpWi/
- CPUID命令って、CPUのバージョンやベンダー名、対応命令を取得するだけでなく
副作用としてフェンスする効果もある。
CPUIDからeax:edx:ecx:ebxを汚さず、フェンス機能のみを使うのが、*FENCE
*FENCEが動作に干渉する命令は当然CPUIDを使っても干渉する。
ID:Yk6PbdtEの主張
「CPUIDの場合はフェンスをスルーすればいい」
- 34 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:39:11 ID:XA+DpWi/
- 561 名前：Socket774[sage] 投稿日：2008/08/24(日) 23:19:19 ID:dxY2QGlA
>>552
CPUID等の直列化作用のほうをVPUには緩めると思う
が、直列化以外の意義のないフェンス命令はナンセンス
どうみてもフェンス理解してない人の発言
俺が指摘してから調べたんだろ
- 35 名前：Socket774 ：2008/08/29(金) 02:39:39 ID: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 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:40:21 ID:XA+DpWi/
- 「中途半端にフェンスに完了させられる」
これはフェンスを理解してる人の発言ではない
- 37 名前：Socket774 ：2008/08/29(金) 02:41:42 ID:Yk6PbdtE
- フェンスを理解していなかった団子
フェンスを理解していなかった団子
フェンスを理解していなかった団子
認めざるを得なくなった団子
くやしいのう くやしいのうwwwwwww
- 38 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:42:07 ID:XA+DpWi/
- > LarrabeeにはScatter/Gatherがあるだろ、
> 1命令で16要素のメモリアクセスするから、スレッド数にあわせて4段のパイプラインだと、
> 全部で64アクセスをバッファにためないといけない
ところが全部ページ内に収まるかを解決してしまえばバッファリングそのものが不要です
- 39 名前：Socket774 ：2008/08/29(金) 02:44:30 ID:Yk6PbdtE
- 知識も素養もないのにマニュアルだけ読んで フェンスを理解できなかった団子
しかも1スレにわたって偉そうな態度で大間違いを吹聴していた団子
くやしいっ…でも気持ちいいっ…
- 40 名前：Socket774 ：2008/08/29(金) 02:47:03 ID:Yk6PbdtE
- ま、MACオタよりよっぽどマシな態度なんで、いじめるのはここまでにします
今日は団子が理解を深めたことと、素直ではないが自分の間違いを受け入れられるような人間に成長したことを素直に祝いましょう
- 41 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:47:22 ID: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 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:48:12 ID:XA+DpWi/
- 勝利宣言ｗｗｗｗ
でも君は死ぬんだ。確実に。
Larrabeeは完全なEM64T準拠ですから。
- 43 名前：Socket774 ：2008/08/29(金) 02:48:35 ID:Yk6PbdtE
- これに懲りたらちゃんと最新の分厚い教科書読んでね
どういうプライドから読まないのか知らないが、読んで損はしないよ
- 44 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:50:14 ID:XA+DpWi/
- っていうかライトコンバイン命令のリタイヤ条件を把握してない奴が
フェンス命令の仕様を理解してるわけがないしさ。
766 名前：Socket774[sage] 投稿日：2008/08/26(火) 21:17:10 ID:JnmrWmO4
>>765
すまないが、君と話すことはもうなにもない
「リタイアしたストア命令が、データを正しくストアしている保証はない」
なんて、x86に限らず、ありえない
- 45 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 02:50:59 ID:XA+DpWi/
- >>43
懲りるのはお前だよ。
なぜならLarrabeeにSSE*は実装されることは確定なのだから。
- 46 名前：Socket774 ：2008/08/29(金) 02:57:29 ID:Yk6PbdtE
- >>44
> っていうかライトコンバイン命令のリタイヤ条件を把握してない奴が
そもそもライトコンバイン命令のリタイヤ条件というのがどういう意味かわからんが、よかったら説明してくれ
リタイヤするための条件なのか？
リタイヤ後に満している条件なのか？
団子の言い方ではそれすらわからん
- 47 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 03:01:25 ID:XA+DpWi/
- > リストベクトルなんて有名な性能ボトルネックじゃん
> リソースの投入し甲斐のある箇所だよ、ベクトル機みたいにね
こんなことを言う馬鹿がなぜか回路の制約でSSEはサポートできないと言う
- 48 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 03:38:21 ID: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 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 04:05:25 ID:XA+DpWi/
- 前スレの発言は撤回する気がないようなのでしつこく粘着してやる
> ページフォールトハンドラ内では当然共有データのページテーブルを更新するだろう
> なのでフェンス命令は必ず実行される
ハンドラに捕捉されるとパイプラインは全部流れます。
そもそもフェンス命令の「実行」状態って何を言うんだろうか？
まだ未完了の実行ユニットのポートをが数サイクルにわたって占拠され
その後ろで実行ステージを待ってる状態を実行中とは言わない。
フェンス命令によって中途半端にストアさせられるｗｗｗｗとかさ
ちなみにページスラッシングはOSじゃなくてマイクロコードでやる仕事ですので
例外ハンドラは全然関係ない。
> scatterの全てのメモリアクセスをバッファリングしておいて、すべてのアドレスがページインした状態を保証してからバッファを書きだすと
> 意味論的には正しいが、バッファリングのコストと、実際のストアまでの余計な遅延がある
ページインかどうかはアドレス指定に用いるレジスタに含まれるオフセット値の最大と最小だけとって
その範囲を見れば判別できるので全てを物理アドレスに変換しストアパケット作ってから
バッファリングするような手間をかけるまでもなく簡単に保証できる。
- 50 名前：Socket774 ：2008/08/29(金) 04:13:44 ID:d7DEsUlu
- まだやってるのか…
どうでもいいけどARMのコード資産は見えないところに行き渡ってる。見えるエコシステムのx86界隈とは文化そのものが違うね。
- 51 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 04:30:05 ID:XA+DpWi/
- 見えるって言うか実際CPUターゲット別のプログラマ人口で一番多いのがx86だろ。
ソフト市場規模で見てもね。
ARMもいいんだけどでもIntelはXScaleやめちゃったしなぁ
WirelessMMXは本家ARMのSIMDより好きだったんだが。
俺もARMのアセンブリコードくらいは読めます。
てか、まさに、取ってきた仕事のために読んでる。
プレディケートの概念は直感的でいいね
3レジスタオペランドマンセー
- 52 名前：Socket774 ：2008/08/29(金) 06:07:00 ID:Yk6PbdtE
- >>48
なーんだ
やっぱりわかってないじゃん(プ
- 53 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 06:10:29 ID:XA+DpWi/
- >>49に補足
そもそもヴァカの間違いは
「フェンス命令は一度パイプラインにフェッチ前の命令で例外が起きても破棄できない」
という思い込み
実際には、例外が起きればパイプラインは全部フラッシュされ、
もちろんフェンス命令も「パイプラインに取り込まれてない」状態に巻き戻されます。
分岐予測ミス時にパイプラインを破棄するのと同じ理屈です。
正常処理できなかったフローは破棄します。
どーせパイプラインに取り込んじゃったら、例外が起きようとフェンス命令をリタイヤ
するまでは継続しないといけないと思ってるんだろ。前の命令を押し出してでも。
だってそうじゃないと「中途半端な状態でフェンスに中断させられる」とか言わないもんな。
基本、こいつはただの 馬 鹿 だ か ら
前の命令に影響を与える命令は存在しません。
そんなんあったらノイマン型コンピュータの原則に反します。
だから、教科書にも書いてある常識です。
後続の命令は実行前ならいつでも破棄出来ます。
パイプラインが実装されてからずっと、そういう構造になってます。
でも頭弱いから、フェンス命令が残ったまんまだと思ってるんだぜ。
その思い込みを根拠に、一貫性云々のこじつけでSSEがサポートできないとか言ってるんだぜ。
いまだに。
ちなみに、例外時に破棄することを前提としたストアバッファは存在しません。
例外チェックをクリアしてからストアバッファに溜まります。
で、フェンス命令のどこが厳しいだって？ｗｗｗｗ
そもそもの前提として、例外が起きたらフェンス命令は溜まったままになりませんｗｗｗｗ
スキャタのアドレス解決機構は、フェンス命令の実装の有無と関係なく
備えていないといけない話だし
- 54 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 06:11:02 ID:XA+DpWi/
- >>52
なんだ、いまだにわからないのか。決定的な勘違いが。
- 55 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 06:14:21 ID:XA+DpWi/
- ×「フェンス命令は一度パイプラインにフェッチ前の命令で例外が起きても破棄できない」
○「フェンス命令は一度パイプラインにフェッチされたら、前の命令で例外が起きても破棄できない」
- 56 名前：Socket774 ：2008/08/29(金) 06:19:00 ID:Yk6PbdtE
- >>48
ヒント
シングルCPUのユーザープロセスにはフェンス命令はいらない
- 57 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 06:23:16 ID:XA+DpWi/
- 馬鹿だなCore 2で計測してんのに。
計測して反証しろよ。
お前アセンブラ知らないから無理か。まあ馬鹿には無理なのはわかってるし。
x86の話してるのに、x86の命令に存在しない
「s t o r e 」
とか書いちゃうくらいだもんな。ぷぷぷ
- 58 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 06:28:54 ID:XA+DpWi/
- それより>>53で図星なんだろ？
でないとフェンス命令が干渉するなんて世界で1人だけの妄想は
起こりえない
- 59 名前：,,・´∀`・,,）っ-○●◎ ：2008/08/29(金) 06:38:06 ID:XA+DpWi/
- http://aceshardware.freeforums.org/consequences-of-extending-xmm-registers-to-ymm-t539.html
ここにx86プログラマ界の重鎮Agner氏がいるから
自分が思ってるフェンス命令の動作を説明してきてごらんよ
一発で論破されるから
- 60 名前：前スレ641 ：2008/08/29(金) 07:32:57 ID: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 ：2008/08/29(金) 10:55:15 ID:Yk6PbdtE
- >>48
> また、ライトスルー命令だからこそ通常のアクセスとの境界にフェンス命令が【要る】わけよ。
> これは常識な。
プププププ
- 62 名前：Socket774 ：2008/08/29(金) 11:05:35 ID:L2m2fICO
- LarrabeeでSSEが動くのはTera×3以前からIntel自身に言われてたこと。
むしろAVXやLNIは今年になってからの新事実。
Larrabeeには、既存命令と干渉するような新命令なら、最初から載せないだろう
たしかに、キャッシュに収まりきらない大きい多次元配列のアクセスは
ノンテンポラルを使うべきというのはPen3の頃からインテルが言ってた事項だよ。
シーケンシャルならまだいいが、ストライド次第では壮絶なキャッシュミス地獄になるからね。
- 63 名前：Socket774 ：2008/08/29(金) 11:52:43 ID:Yk6PbdtE
- 団子> 【現実のIntel/AMD/VIAの実装】
団子> ストアバッファはあくまでキャッシュ帯域の節約のため一括転送するために貯めておくもの。
プププププ
- 64 名前：Socket774 ：2008/08/29(金) 11:56:39 ID:Yk6PbdtE
- > >>22
> 本当に撤回してたんならアンカー出してコピペしてくれよw
コピペマダー？
- 65 名前：Socket774 ：2008/08/29(金) 12:07:41 ID:Yk6PbdtE
- >>20
> 団子> フェンス命令をしないといけないのはアクセスするアドレスが重なるときだよ。やっぱり君は解ってないな。
> こんなアホみたいな主張を続けるのか
>>22
団子> >>20
団子> 撤回済みだけど前スレで
フェンスをちゃんと理解したと思ったら
>>48
団子> また、ライトスルー命令だからこそ通常のアクセスとの境界にフェンス命令が【要る】わけよ。
団子> これは常識な。
やっぱりわかっちゃいねー！！
団子の浅薄な理解はラッキョのごとし
- 66 名前：Socket774 ：2008/08/29(金) 12:12:48 ID:Yk6PbdtE
- 正解も書いておいてやるぞ
Weak Consistencyに於いては
2つのメモリアクセスの順序を**CPU外部**に対して保証する場合には、必ずフェンスを間に挟む必要あり
それ以外の場合にはフェンスは全く不要
ライトスルーとかもう全然関係ナシ
- 67 名前：,,・´∀｀・,, ：2008/08/29(金) 12:53:52 ID:XA+DpWi/
- で、その必要な命令を、マルチコアアーキテクチャのLarrabeeでは
SSEごと「サポートできない」と言ってる馬鹿がいる。
その理由も、既に完全否定されているにもかかわらず、である。
フェンス専用命令のサポートを消して全部CPUIDで済ませろって？
20倍のクロックも待たされる上にEAX:EDX:ECX:EBXレジスタを汚すCPUIDを？
まあ、嘘を言ったのは認めるさ。
まあ、「storeなんて命令なんて無い」って言われて必死に調べたんだろうと
思って、軽くあしらっただけなんだけどさ。
でもアレのコードはプログラミング作法としちゃ駄目だよ
スタックとかヒープとかデータセグメントに対する相対アドレッシング
とかじゃなしに10000000とかの即値でアドレッシングする時点で
安全にストアできる保証がない。
即値はアプリケーションの作法としてはありえない。
そういう意味ではどのみちフェンスがあろうがなかろうが、
一般保護違反になる可能性高いから、あろうがなかろうが同じってことで。
まあいいけど、問題でも出しておくか
add eax, [edx+ecx*2+12345678h]
のModR/Mバイトのエンコードを16進数で答えよ。
これはx86アーキを知る上では常識だけどさ。
- 68 名前：,,・´∀｀・,, ：2008/08/29(金) 12:58:42 ID:XA+DpWi/
- というかスレッド間で共有するアドレスならなおさら、
データセグメントなりヒープのポインタを使ったアドレッシングになるわけで
「即値」になるわけがない
- 69 名前：Socket774 ：2008/08/29(金) 13:03:34 ID:YVziV6Bc
- 何故そこで86になるような問題にしないのか
- 70 名前：Socket774 ：2008/08/29(金) 13:35:22 ID: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 ：2008/08/29(金) 13:40:45 ID: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 ：2008/08/29(金) 13:49:54 ID:Yk6PbdtE
- >>71
> 7ビット目は0、6-4ビットでALUの機能を指定、3-1ビットでアドレッシング、0ビット目でbyte/word
あ、これと矛盾するなあ
b/wの指定はどうすんだっけな。。
- 73 名前：,,・´∀｀・,, ：2008/08/29(金) 13:52:22 ID:XA+DpWi/
- 20年ぶりってｗｗｗおっさんだね。
それならもうアルツハイマー始まっててもおかしくねーわな。
最近のOSセグメント管理知らなくて当然だな
共有変数を即値でとるとか、マルチプロセッサ環境としてにありえないことを
平気で言ってのけられるわけだ。
なっとく（笑）
OSレスならある意味フリーダムだけどね。そんかわりマルチプロセッサの管理が面倒だ。
つーか
Agner氏も当然のごとくLarrabeeではSSEは載るって見てるようだけどその点はどうよ？
- 74 名前：Socket774 ：2008/08/29(金) 13:57:49 ID:Yk6PbdtE
- >>73
OSレスな環境の経験はないのか
そはともかくエンコーディングのクイズはどうよ？
- 75 名前：Socket774 ：2008/08/29(金) 14:03:15 ID:Yk6PbdtE
- >>67
> まあ、嘘を言ったのは認めるさ。
> まあ、「storeなんて命令なんて無い」って言われて必死に調べたんだろうと
以下略
負 け 犬 の 遠 吠 え
- 76 名前：,,・´∀｀・,, ：2008/08/29(金) 14:03:36 ID:XA+DpWi/
- OSレスでマルチコアでは結局OSの機能を自分で作る羽目になるだけだからな
組み込みでもマルチコア使う用途じゃ審美餡やらWinCEやらLinuxを使うのが一般的だぞ
ほい
http://maelific.dyndns.org/projects/myos/browser/tags/All/trunk/MyOS/src/dosutil/myasm/etc/%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E6%8C%87%E5%AE%9A%E5%BD%A2%E5%BC%8F%E6%8C%87%E5%AE%9A%E5%AD%90%E3%83%90%E3%82%A4%E3%83%88(32bit).xls?rev=87&format=raw
- 77 名前：,,・´∀｀・,, ：2008/08/29(金) 14:05:30 ID:XA+DpWi/
- でも即値指定だけはないわー
- 78 名前：,,・´∀｀・,, ：2008/08/29(金) 14:08:26 ID:XA+DpWi/
- ＞負け犬の遠吠え
っていうか即値アドレス指定の時点でマルチタスクOS上のアプリケーション
の共有変数として有り得ないしー（笑）
コードシーケンスとして論外（笑）
- 79 名前：Socket774 ：2008/08/29(金) 14:11:11 ID:Yk6PbdtE
- >>78
負 け 犬 の 遠 吠 え
- 80 名前：,,・´∀｀・,, ：2008/08/29(金) 14:22:32 ID:XA+DpWi/
- 79 ：Socket774：2008/08/29(金) 14:11:11 ID:Yk6PbdtE
>>78
負 け 犬 の 遠 吠 え
と負け犬が遠吠えしてます
出題者が間違えるなんてありえませんから。残念。
- 81 名前：,,・´∀｀・,, ：2008/08/29(金) 14:25:01 ID:XA+DpWi/
- 「フェンスに完了させられる」の誤解はいつ辞めるの？
その誤解の上にSSEをサポートできないのトンでも論理が構築されてるわけで
Agner氏にメールで聞いても「有り得ない」って回答だよ。
- 82 名前：Socket774 ：2008/08/29(金) 14:35:50 ID:Yk6PbdtE
- >>81
> 「フェンスに完了させられる」の誤解はいつ辞めるの？
全く正しい表現だよ
比喩的ではあるから、表面的な理解もあやしい団子には難しかったかもしれないね
> Agner氏にメールで聞いても「有り得ない」って回答だよ。
引用してくれ
- 83 名前：,,・´∀｀・,, ：2008/08/29(金) 14:51:34 ID: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 ：2008/08/29(金) 14:51:50 ID:Yk6PbdtE
- 1)先行するストア命令が完了したのを、フェンス命令によって保証されてから、後続のストア命令が完了する
が、より比喩的でない表現かな
2)先行するストア命令が、フェンス命令によって完了させられてから、後続のストア命令が完了する
ちょっと比喩的ではあるけど、わかっている人には1)はくどいし、まさか団子がフェンスを理解していなかったとは思わなかったからさ、ごめんな
1)も本質的でないが不正確なところもあるけどね
フェンスは先行するストアが後続するストアより「先に」完了することだけ保証すれば、実装はどうでもいい
SSEのフェンスみたいに後続命令をブロックするのだけが可能な実装ではない
- 85 名前：,,・´∀｀・,, ：2008/08/29(金) 14:52:47 ID:XA+DpWi/
- 自分でメールしろよ。とんでもないこと言ってるのお前だけなんだから
英語でおｋ。氏はデンマーク人だけど。
- 86 名前：,,・´∀｀・,, ：2008/08/29(金) 14:54:31 ID:XA+DpWi/
- 後続命令はパイプラインに載ってない状態になるんだぞ
バッファなんて要らないジャン
- 87 名前：Socket774 ：2008/08/29(金) 14:54:56 ID:Yk6PbdtE
- お前聞いてないんじゃないかよww
- 88 名前：,,・´∀｀・,, ：2008/08/29(金) 15:14:21 ID:XA+DpWi/
- 別にそれが誤ってるなんて言ってねーよ
例外が起きてもフェンス効果が有効だと思ってるがゆえに馬鹿なんだよ
しかもExecuteより手前のステージは分岐予測ミスや例外発生時に
しょっちゅう破棄されてる。もちろんフェンス命令も含めてだ。
フェンス命令の作用自体、仕様書どおり「常にフェッチを止める」というよりは
フェンス命令が実行ステージに入ったときに前の命令がリタイヤするまで後続命令列の
フラッシュを繰り返すことで実現されてるんじゃないかと思ってたりするが。
ま、それこそ実装に依存した話になるが。
実行ステージに入っても無いのにフェンス効果が利く必要は一切ない。
いつでも破棄できることが重要。
で、PF等が起きたらパイプラインを破棄して立て直せばよく
ストアバッファを破棄できる仕様にする必要が無い。
ま、16Wayでもそんなに大きいとは思わないがな
VIAのインオーダの省電力CPUですらWCバッファが数Wayとかだろ。
- 89 名前：,,・´∀｀・,, ：2008/08/29(金) 15:17:44 ID:XA+DpWi/
- >>87
だから「SSEサポートできない」なんてこの世界で後藤とお前くらいしか
思ってないないんだから、お前が直接識者に聞いてみろよ。
どうせ自分の間違い認められないんだろ？
- 90 名前：,,・´∀｀・,, ：2008/08/29(金) 15:20:16 ID:XA+DpWi/
- っていうか
前の命令が完了してない時点で、フェンス命令はExecuteの手前のステージってのは
わかる？
わかってない？
だから馬鹿は氏ねよ
- 91 名前：Socket774 ：2008/08/29(金) 15:21:14 ID:Yk6PbdtE
- >>88
> 例外が起きてもフェンス効果が有効だと思ってるがゆえに馬鹿なんだよ
また人が言ってもいないことを～
例外ハンドラ内の話してただろ
>>89
相手のいることなので、団子のためだけにそんな手間かけんのはやなこった
- 92 名前：,,・´∀｀・,, ：2008/08/29(金) 15:24:25 ID:XA+DpWi/
- ↑
SSEサポートできないなんていってる奴が
お前と後藤以外に誰がいるんだよ
つまりお前が人の意見に合わせられないゴミなの
- 93 名前：,,・´∀｀・,, ：2008/08/29(金) 15:29:08 ID:XA+DpWi/
- ＞例外ハンドラ内の話してただろ
例外ハンドラってのはOSがトラップしてアプリのcatchブロックなんかに
投げるアレだけど、それでいいのか？
例外処理ブロックに飛ぶってことは、その時点でオペレーション失敗時に
読み書きしたメモリがクリーンである保証はそもそも無いんだよ。
保証をすることは規格にも無い。
だからバッファリングなんてする必要はないんだ。
- 94 名前：,,・´∀｀・,, ：2008/08/29(金) 15:50:05 ID:XA+DpWi/
- それよりさっさと、どこのきょうかしょなのかおしえてよ。
そのきょうかしょ（笑）に基づけば「SSEがサポートできない理論」を説明できるのか？
なら1000円までなら尼損で買ってやんよ。
っていうか50過ぎのおっさんなんだろ？無理するな
- 95 名前：,,・´∀｀・,, ：2008/08/29(金) 16:07:03 ID:XA+DpWi/
- >>93に補足すれば
そもそも例外を検出してないときですら、コンピュータは正しく
データを読み書きしてる保証なんてどこにもない。
ECCメモリのビット誤り検出にしてもそう。100パーセントの
信頼保証は有り得ない。
逆にもし完全に保証できたら、TMRによる多数決冗長系が組める
x86に対するItanium2の優位性は何なのよって話になるだろ。
- 96 名前：MACオタ＞団子 さん ：2008/08/29(金) 17:28:00 ID:r1khUYoD
- >>89
------------------
だから「SSEサポートできない」なんてこの世界で後藤とお前くらいしか思ってない
------------------
できるできないわ別にして、私もx87やSSEをサポートしない可能性わ有ると思っているす。
- 97 名前：,,・´∀｀・,, ：2008/08/29(金) 18:03:29 ID:XA+DpWi/
- 仕様書見たけど不正な操作に対するコンシステンシ保証なんて
元々規定されてないじゃん。
命令レベルでall or nothingなんて保証したところでそもそも
保 証 す る 意 味 が ね ー し。
アプリケーションとしてall or nothingであったほうがいいのは、
あくまで関数レベル・機能レベルの話になるわな。
命令レベルで保証されても、命令レベルで㌧でリカバリーとか
無駄だからね。
例外トラップ機構なんて高級言語向けのものだから命令レベルで
順序保証されてても意味ねー。
するだけトランジスタの無駄。
フェンス命令は正常なフロー(all)にだけ順序保証をすればいい。
というかそういうもともと仕様のはずだが。
それがなんでscatterと干渉するんだよｗｗｗ
マジ頭悪くね？
- 98 名前：MACオタ＠補足 ：2008/08/29(金) 18:13:04 ID:r1khUYoD
- SSEサポートの程度わ不明という点でわ、Anandも同意見の様す。
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3367&p=3
------------------
64-bit x86
SSEn support?
Parallel/Graphics?
------------------
- 99 名前：,,・´∀｀・,, ：2008/08/29(金) 18:15:37 ID:XA+DpWi/
- >>96
AVXのマニュアルではちょっとだけ
SSEのソフトエミュレーションについて言及してたね
利用頻度の少なくなった命令は#UDをOSに投げて、
トラップしてエミュレーション実行するとか
AMD64だったか忘れたがx87についても
エミュレーションについて言及されてたな。
でもそれは「サポートしない」って言わないんじゃね？
SPARC/Solarisがそんな感じのマイナー命令サポートだし
しかしだな
SSEでも現状利用頻度が多い以上は、ハードワイヤードロジックで
実装する理由がある。
ついでに言うとOSによるSSE*エミュレーションの実装は、
現状影も形も無いわけで、じゃあ誰が提供するのって話になる。
Linuxならpinでも使って実装する手もあるけどさ。
エミュレーション自体、SSEがほとんど誰にも使われなくなった場合の
オプションとして、ゆくゆくは、の話であって、
移行もしてないうちから切り捨てるのはセオリーに反してるべ。
おまいさんの信奉するAppleじゃ日常茶飯事かもしれんが
Intelに取っちゃ死活問題だべ。
- 100 名前：,,・´∀｀・,, ：2008/08/29(金) 18:20:11 ID:XA+DpWi/
- >>98
Intelの言うところの「64bitサポート」は、
AMD64のLongモードとのISA互換＋SSE3＋CMPXCHG16B
までを要件としてるからそこまでは確定だべ。
逆にSSSE3/SSE4.1/SSE4.2/AES/CLMULのサポートはどこまでかは
俺にもわからんべ。
それこそソフトエミュレーションかもしれんべ。
- 101 名前：MACオタ＠補足 ：2008/08/29(金) 18:21:08 ID:r1khUYoD
- 同様な疑問を提示しているサイトす。
http://techgage.com/article/clearing_up_misconceptions_about_cuda_and_larrabee/
-------------------
- 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オタ＞団子 さん ：2008/08/29(金) 18:23:43 ID:r1khUYoD
- >>99-100
広い世界にわ、LarrabeeのISAサポートに関して疑念を持っているヒト達がいる例ということで。
- 103 名前：Socket774 ：2008/08/29(金) 18:36:56 ID:Yk6PbdtE
- >>93
> 例外ハンドラってのはOSがトラップしてアプリのcatchブロックなんかに
> 投げるアレだけど、それでいいのか？
プ
>>97
> 命令レベルでall or nothingなんて保証したところでそもそも
>
> 保 証 す る 意 味 が ね ー し。
ププ
- 104 名前：,,・´∀｀・,, ：2008/08/29(金) 18:37:39 ID:XA+DpWi/
- >>101
OSは動く必要はあるでしょ。
x64のOSはAMD64の基本命令まで最低限動くことを前提に作られてるから
動かないと話にならない。
IntelはMSに却下されたYamhillをしぶしぶ廃案にし、Longモードで使える
命令をAMD由来の特権命令も含めてサポートすることで、
それがx86の64ビット版の統一仕様になった。
それを1命令でも欠いてると、対応OSがない可能性がある。
SSE2までは有無を言わさず確定。
でもそれ以降の拡張命令は完全にサポート任意だから
サポート決めうちで最適化コード組んでればリコンパイルが必要ってのは
確かにそうなんじゃね？アセンブラやIntrinsics決めうちだと
リコンパイルどころじゃすみそうにないけどな。
俺はむしろリコンパイルが必要ってのは性能問題だと思ったが。
命令サポートが同じでも、インオーダだと専用のスケジューリングが
必要だし、あと論理CPU数分のスレッドを起こさないといけない。
性能が出せなきゃLarrabeeを使う意味が無いからな。
同じコードで同じスレッド数ならXeonよりはるかに遅い。
- 105 名前：,,・´∀｀・,, ：2008/08/29(金) 18:39:08 ID:XA+DpWi/
- >>103←馬鹿だねこいつ。もうプしか言えないだろ。
得意の教科書で攻撃してこいや屑め
- 106 名前：,,・´∀｀・,, ：2008/08/29(金) 18:40:53 ID:XA+DpWi/
- >>101
っていうかそれ
サポート命令が同じなら性能が同じだと思ってる素人アナリスト臭い
はっきり言って考察として読むに値しない。
- 107 名前：,,・´∀｀・,, ：2008/08/29(金) 18:48:04 ID:XA+DpWi/
- 誰かと思えばRob Williamsか。組み込みRTOSの本書いてる人だね。
こらMACヲタ、記者名くらい引用汁
- 108 名前：MACオタ＞団子 さん ：2008/08/29(金) 18:54:01 ID:r1khUYoD
- >>107
-------------------
記者名くらい引用汁
-------------------
だから何時も安易に他人のことをバカバカ書くなと。。。(笑)
- 109 名前：,,・´∀｀・,, ：2008/08/29(金) 18:54:54 ID:XA+DpWi/
- それでも記事レベルで数を競うなら、「x64」として書いてる記事のほうがよっぽど多いんだよな
http://www.google.co.jp/search?q=Larrabee+x64
Larrabee "x64 incompatible"
だと2件しかヒットしない。しかもまったく関係ないページ
http://www.google.co.jp/search?q=Larrabee+%22x64+incompatible%22
- 110 名前：,,・´∀｀・,, ：2008/08/29(金) 19:00:30 ID:XA+DpWi/
- LinuxのXSAVE/XRESTRサポートのためのパッチ送った企業ってどこだったっけ？
まあそういうこっちゃ
ヘッダの拡張フィールドによって1024ビットSIMDとかの時代まで対応できる命令とされる。
- 111 名前：,,・´∀｀・,, ：2008/08/29(金) 19:06:12 ID:XA+DpWi/
- Intel's Larrabee GPU Will Support Linux
http://www.phoronix.com/scan.php?page=news_item&px=NjYzOA
面白いことになったね
- 112 名前：Socket774 ：2008/08/29(金) 19:24:32 ID:0dK6Hl59
- ？
Xの話じゃないの
- 113 名前：MACオタ ：2008/08/29(金) 19:33:50 ID:r1khUYoD
- Siggarph2008のLarrabeeプレゼン見つけたす。
http://s08.idav.ucdavis.edu/forsyth-larrabee-graphics-architecture.pdf
興味深いところわ、この辺すか。
- 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 ：2008/08/29(金) 19:36:23 ID:6g0fQyCg
- 今月のパワレポでの後藤
「LarrabeeはMMX/SSE以降の拡張命令のほとんどを採用しないと見られる」
みたいなこと言ってた。
"ほとんど"という言葉が入ったのがネット記事との違いか。
- 115 名前：MACオタ＞団子 さん ：2008/08/29(金) 19:44:06 ID:r1khUYoD
- >>100
-------------------
Intelの言うところの「64bitサポート」は、
AMD64のLongモードとのISA互換＋SSE3＋CMPXCHG16B
までを要件としてるからそこまでは確定だべ。
-------------------
そのIntel謹製の資料で、x64ともx86-64ともEM64TともIntel64とも書かずに、
===================
Plus standard 64-bit instruction extensions
===================
と書いているのにわ、意味があるのかもしれないす。"standard"すから、X64を指すと受け取るのも
アリと思うすけど。。。
- 116 名前：,,・´∀｀・,, ：2008/08/29(金) 19:46:05 ID:XA+DpWi/
- > - SMTの主目的わキャッシュミスの隠蔽 (p.11)
> でも命令レイテンシの隠蔽にも有効 。
なー、MACヲタよ。命令レイテンシの隠蔽できるってよ。
加減算は1サイクルだから意味無いす（笑）か？
- 117 名前：Socket774 ：2008/08/29(金) 19:49:24 ID:0dK6Hl59
- Xでlarrabeeが使えることの何が面白いの？
- 118 名前：,,・´∀｀・,, ：2008/08/29(金) 20:00:00 ID: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オタ＞団子 さん ：2008/08/29(金) 20:03:12 ID: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 名前：,,・´∀｀・,, ：2008/08/29(金) 20:03:42 ID:XA+DpWi/
- それとも、MACオタ用語的には「standard」に規格外って意味でもあるのか？
- 121 名前：Socket774 ：2008/08/29(金) 20:05:38 ID:0dK6Hl59
- で、Xでlarrabeeが使えることの何が面白いの？
- 122 名前：,,・´∀｀・,, ：2008/08/29(金) 20:06:13 ID:XA+DpWi/
- 面白いから面白いだけ
- 123 名前：MACオタ＞団子 さん ：2008/08/29(金) 20:07:17 ID:r1khUYoD
- >>120
-------------------
MACオタ用語的には「standard」に規格外って意味でもあるのか？
-------------------
日本語が読めるなら>>115を読み直せば判ると思うす(笑)
- 124 名前：,,・´∀｀・,, ：2008/08/29(金) 20:07:41 ID:XA+DpWi/
- ＞standard 64-bit instruction extensions
~~~~~~~~
さて、ここはどう弁解しよう？
オッサンのトンデモ論的にはLNIと干渉するんだろ？ｗｗｗｗ
- 125 名前：Socket774 ：2008/08/29(金) 20:07:49 ID:0dK6Hl59
- ふぅん
- 126 名前：,,・´∀｀・,, ：2008/08/29(金) 20:13:25 ID:XA+DpWi/
- >>123
なにか？AMD64準拠ならOSが動く条件はクリアだよね
暗黙にCMOV/SSE/SSE2も含まれる。
つまり「彼」の死亡条件がクリアされましたｗｗｗ
SSE3もCMPXCHG16Bも今はAMD64の規格に含まれてる。
だがAMDは3DNow!と同じく実装は任意としている。
- 127 名前：,,・´∀｀・,, ：2008/08/29(金) 20:16:50 ID:XA+DpWi/
- SSE3/CMPXCHG16Bも実装しとかないとAMD64互換であってもIntel 64非互換になっちゃうんだよね。
それIntel的にはまずいでしょ（メンツ的な意味で
- 128 名前：Socket774 ：2008/08/29(金) 20:17:59 ID:c37I8Bch
- > 111 名前：,,・´∀｀・,, 投稿日：2008/08/29(金) 19:06:12 ID:XA+DpWi/
> Intel's Larrabee GPU Will Support Linux
> http://www.phoronix.com/scan.php?page=news_item&px=NjYzOA
>
> 面白いことになったね
>
>
> 112 名前：Socket774 投稿日：2008/08/29(金) 19:24:32 ID:0dK6Hl59
> ？
> Xの話じゃないの
面白いテンプレが出来たね
- 129 名前：Socket774 ：2008/08/29(金) 20:27:41 ID:L2m2fICO
- >>128
いいから死ね
- 130 名前：Socket774 ：2008/08/29(金) 20:33:46 ID:L2m2fICO
- OpenGL(MESA)はXを介さずにフレームバッファにダイレクトに書くんだが。
DirectXがGDIでないのと同じレベルで別物。
無知って恥ずかしいね。
- 131 名前：Socket774 ：2008/08/29(金) 20:36:58 ID: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オタ ：2008/08/29(金) 20:37:39 ID:r1khUYoD
- >>113すけど、上の階層を漁るともう2つSiggraphのプレゼンが見つかるす。
http://s08.idav.ucdavis.edu/lefohn-programming-larrabee.pdf
http://s08.idav.ucdavis.edu/pharr-advanced-rendering-on-larrabee.pdf
前者わ、ちょうどLarrabeeにおける『ソフトウェアコンテキストの細粒度切替による命令レイテンシの
隠蔽』を語っているす。ちなみに後者わグラフィックよりの話題す。
この中に出てくるLarrabeeにおけるコンテキストの最小単位"Fiber"って、リソースがダブらないよう
に複数の処理をするコードを自前で書けという意味にも取れるす。
特にハードウェア的な支援が無いように見えるすけど、「リソースがダブらないように」を満たすために
予想以上にレジスタファイルが大きいとか？
- 133 名前：Socket774 ：2008/08/29(金) 20:41:28 ID:8RINfp7M
- >>131
イジメよくない
- 134 名前：Socket774 ：2008/08/29(金) 20:44:25 ID:L2m2fICO
- 私の肛門もフェンス命令に強制リタイアさせられそうです(笑)
- 135 名前：Socket774 ：2008/08/29(金) 21:01:26 ID:L2m2fICO
- LNIとSSEは共存できるが、Larrabeeの実装では、VPUにSSE命令を100%コンパチで実装するのは難しい
(笑)
- 136 名前：Socket774 ：2008/08/29(金) 21:04:17 ID:L2m2fICO
- 【テンプレ】
> つか、万が一でもSSE*を100％サポートだったら死ぬの？
いいともさ
そのかわり、ごくささいな互換性でも失なわれていたらお前が死ねよ
- 137 名前：Socket774 ：2008/08/29(金) 21:07:58 ID:0dK6Hl59
- なんか独り言いい始めたぞ
- 138 名前：Socket774 ：2008/08/29(金) 21:08:56 ID:L2m2fICO
- SSEがサポートできない（プ
- 139 名前：Socket774 ：2008/08/29(金) 21:11:18 ID:L2m2fICO
- 私のバッファにもスキャット命令が溜め込まれそうです
フェンスに貫かれそうです
アーッ！
- 140 名前：Socket774 ：2008/08/29(金) 21:29:56 ID:8RINfp7M
- >>137
お前があんまりいじめるからだろ
- 141 名前：Socket774 ：2008/08/29(金) 21:38:58 ID:L2m2fICO
- 先生、フェンスに完了させられてしまいました。
- 142 名前：フェンスに完了 ：2008/08/29(金) 21:41:03 ID:L2m2fICO
- 先生、ららびいがSSEをサポートしない理由教えてください
- 143 名前：Socket774 ：2008/08/29(金) 21:42:14 ID:0dK6Hl59
- なんだ団子か
- 144 名前：フェンスに完了 ：2008/08/29(金) 21:43:15 ID:L2m2fICO
- なんだ自殺宣言した人か
- 145 名前：Socket774 ：2008/08/29(金) 21:44:19 ID:koiu0PxM
- ララビーのアレ(ストリームプロセッサ？)はインオーダー型のデュアルイシューじゃなかったっけ？
CPUコアのほうがインオーダー型のデュアルイシューなのは既出だけど
デュアルのうち片方だけは簡易にしてSIMDを載せない可能性があるとかいう話があった気がする。そのへんどうなってるんだろ。
- 146 名前：フェンスに完了 ：2008/08/29(金) 21:44:30 ID:L2m2fICO
- で、いつ死ぬの？
- 147 名前：Socket774 ：2008/08/29(金) 21:45:27 ID:0dK6Hl59
- は？
- 148 名前：Socket774 ：2008/08/29(金) 21:46:44 ID:8RINfp7M
- >>143
バラスナヨ
- 149 名前：フェンスに完了 ：2008/08/29(金) 21:47:57 ID:L2m2fICO
- フェンスに強制完了させられた短い人生だったな
- 150 名前：Socket774 ：2008/08/29(金) 21:49:40 ID:0dK6Hl59
- 何を言ってるんだろうねこの人は
- 151 名前：Socket774 ：2008/08/29(金) 21:51:31 ID:DRsgErBY
- どんなCPUだろうと、GPUだろうと、GPGPUだろうと、DSPだろうと
呼び方違えど同じマイクロチップ(材質はシリコン(半導体))の仲間だ
- 152 名前：フェンスに完了 ：2008/08/29(金) 22:00:22 ID:L2m2fICO
- ナウなヤングにバカウケ
- 153 名前：MACオタ ：2008/08/29(金) 22:19:39 ID: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 ：2008/08/29(金) 23:13:04 ID:xdqYRUcn
- ローエンドGPUのことなんてどうでもいいっす
- 155 名前：フェンスに完了 ：2008/08/29(金) 23:13:06 ID:L2m2fICO
- scatter命令のためにSSEをサポートしないのが画期的
- 156 名前：Socket774 ：2008/08/30(土) 00:37:35 ID: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 ：2008/08/30(土) 00:59:32 ID:efBh6GPC
- >>156
一言でいえば、fiber≒コルーチン
- 158 名前：MACオタ＞156 さん ：2008/08/30(土) 01:04:04 ID:rRKT6K+V
- >>156
fiberの解説感謝するす。しかし、
-------------------
liveでないレジスタは退避しないということ
-------------------
これAltiVecならvrsaveレジスタでハードウェアサポートがあるような話すけど。。。
http://www.ibm.com/developerworks/power/library/pa-unrollav1/
====================
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 ：2008/08/30(土) 01:18:03 ID:efBh6GPC
- >>158
fiberは完全にソフトウェアで切り替えるので、切り替え時にliveなレジスタセットはコンパイラが完全に把握しているから
そういう機能は不要
AltiVecのはプリエンプティブなコンテクストスイッチをする場合に有用
- 160 名前：Socket774 ：2008/08/30(土) 01:25:45 ID: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 ：2008/08/30(土) 01:27:26 ID:efBh6GPC
- >>159
全然知らんのだが、AltiVecのレジスタに書き込むと、VRSAVEレジスタの対応するビットが自動的に1になるんだろ？
- 162 名前：Socket774 ：2008/08/30(土) 01:51:29 ID:efBh6GPC
- >>105
> >>103←馬鹿だねこいつ。もうプしか言えないだろ。
団子の変な理解が端的に現れているところを挙げてみたんだが、確かにもうプププとしか言えないねww
- 163 名前：Socket774 ：2008/08/30(土) 03:44:19 ID:fZBNI9Ql
- 団子さんここにいたのか
プログラム板の連中が寂しがってたぞ
- 164 名前：,,・´∀｀・,, ：2008/08/30(土) 08:34:02 ID:DThLhIVJ
- FiberはマイクロOS上の実行単位じゃね？GPGPUとして使った場合の。
Xeonソケットに刺さるGPUじゃない方の、あるいは純粋なCPUとして使った場合の
プログラミングモデルはまだ示されてない気がする。
どっかの海外記事に普通(regular)のOSは容易に移植もしくはそのままで動くらしく、
マイクロOSとは別個のメモリ空間が割り当てられるとか書いてあった。
これはハイパーバイザで仮想マシンを複数サポートする方法があることを意味するかもしれない。
それってつまりVTもしくはそれ以上の仮想化機構をサポートするってことになるんだが。
- 165 名前：,,・´∀｀・,, ：2008/08/30(土) 08:44:05 ID:DThLhIVJ
- 変な理解とは
・フェンス命令は一度パイプラインに入ったらリタイアするまでパイプラインをブロックし
たとえ前の命令が例外を起こした時でもパイプラインからフラッシュされないという思いこみ。
・前の制約により破棄可能なストアバッファリング機構が必要であるという思いこみ。
・SSEはLarrabeeではサポートせずx64非準拠になるという思いこみ。
アハハハハ
- 166 名前：,,・´∀｀・,, ：2008/08/30(土) 09:53:24 ID:DThLhIVJ
- 城島「Intelに『standardな64ビット拡張』って言われてみて、どう思った？」
- 167 名前：,,・´∀｀・,, ：2008/08/30(土) 10:09:31 ID:DThLhIVJ
- ま、解ったなら、落とし前はつけような。
- 168 名前：,,・´∀｀・,, ：2008/08/30(土) 11:58:30 ID:DThLhIVJ
- つか、かの人はもう一つとんでもない思い違いをしてたかもわからんね。
ここで問題です。
パラメータに依存して複数サイクルかかるような複合タイプの命令を、
マイクロコードに置き換える機能があるのは次のうちどれでしょう？
1.デコーダ
2.実行ユニット
それ考えたら、シンプルデコーダ側でVPUのストア（思うにそれすら一部のみ）
だけしかデコードできない技術的理由は俺はなんとなく解ったよ。
- 169 名前：,,・´∀｀・,, ：2008/08/30(土) 12:02:11 ID:DThLhIVJ
- 訂正
ここで問題です。
パイプラインにおいて、パラメータに依存して複数サイクルかかるような複合タイプの命令を、
マイクロコードに置き換える機能があるのは次のうちどれでしょう？
1.デコーダ
2.実行ユニット
- 170 名前：Socket774 ：2008/08/30(土) 12:08:29 ID:efBh6GPC
- >>165
> ・フェンス命令は一度パイプラインに入ったらリタイアするまでパイプラインをブロックし
たとえ前の命令が例外を起こした時でもパイプラインからフラッシュされないという思いこみ。
フェンスを理解していないお前がおれの指摘を正しく理解できてないだけだろ…
以下同様
- 171 名前：Socket774 ：2008/08/30(土) 12:11:59 ID:efBh6GPC
- >>168
> ここで問題です。
> パラメータに依存して複数サイクルかかるような複合タイプの命令を、
> マイクロコードに置き換える機能があるのは次のうちどれでしょう？
>
> 1.デコーダ
> 2.実行ユニット
>
何を言いたいんだろう
マイクロコードでもステートマシンでもいいわけだが、
団子頭では
複数サイクル命令==マイクロコードで実装
なんだろうか
- 172 名前：Socket774 ：2008/08/30(土) 12:15:28 ID:efBh6GPC
- >>165
そうそう
> ・フェンス命令は一度パイプラインに入ったらリタイアするまでパイプラインをブロックし
> たとえ前の命令が例外を起こした時でもパイプラインからフラッシュされないという思いこみ。
おれがこういう主張をしているというのなら、該当箇所にアンカーふってくれ
今すぐ首吊ってやんよ
- 173 名前：Socket774 ：2008/08/30(土) 12:17:41 ID:efBh6GPC
- >>172
おれが挙げた例は
「scatter命令が例外を起して、例外ハンドラに処理が移ってからフェンス命令を実行した場合」
だからね
この違いが理解できなかったんだね
- 174 名前：Socket774 ：2008/08/30(土) 12:22:17 ID:efBh6GPC
- >>171
うん、やっぱり団子頭では
「複数サイクル命令は、マイクロコードで実装されなければならない」
ということになってるようだね
- 175 名前：,,・´∀｀・,, ：2008/08/30(土) 12:51:20 ID:DThLhIVJ
- やっぱりばかだね
ていうか
たとえばCPUIDの主作用である実行の本質知ってる？
EAXで指定した値を元に、デコーダにぶら下がってるマイクロコードROMを参照し、各汎用レジスタに即値ロードする内部命令に置き換えるんだが。
例のリコール騒ぎになったDIVのバグもマイクロコードのテーブルの誤りだったのは有名な話
LarrabeeがP5が土台ということはマイクロコードベースなんだよ。
というかP6以降はもっと極端で、Complex Decoder Pathを強制される命令は例外なくマイクロコードを参照する。
scatter/gatherに限ってマイクロコード実装にしないという理由がない。
むしろscatter/gatherにエラッタがあった場合
マイクロコードでなければROM更新ではなくリコールするしかない。
- 176 名前：Socket774 ：2008/08/30(土) 12:57:12 ID:efBh6GPC
- >>175
はいはい
gather/scatterがマイクロコード命令でなかったら首吊ってれるかい？
- 177 名前：,,・´∀｀・,, ：2008/08/30(土) 13:03:11 ID:DThLhIVJ
- 「SSEサポートだったら死ぬ」と明言し
x64準拠と判明しても見苦しく詭弁を
まき散らす行為を、君の定義で「死ぬ」というのなら
俺はそんなみっともない真似はお断りだ
- 178 名前：Socket774 ：2008/08/30(土) 13:06:50 ID:fCHg5zW2
- >俺はそんなみっともない真似はお断りだ
団子さんからこんな言葉が聞けるなんて
ちょっと感動
- 179 名前：Socket774 ：2008/08/30(土) 13:11:07 ID:efBh6GPC
- >>177
> x64準拠と判明しても
インテルのどの資料？
- 180 名前：Socket774 ：2008/08/30(土) 13:12:49 ID:efBh6GPC
- >>177
> 俺はそんなみっともない真似はお断りだ
人気のないところで潔く首吊るか腹を切るかしてくれれば結構
電車などは迷惑がかかるからやめてね
- 181 名前：,,・´∀｀・,, ：2008/08/30(土) 13:16:17 ID:DThLhIVJ
- さーな、俺の情報筋はWebじゃねーし。
ソースの在処はMACオタにでも聞けよ
>>115って言ってることだし。
- 182 名前：,,・´∀｀・,, ：2008/08/30(土) 13:18:43 ID:DThLhIVJ
- これから死ぬ人間にやるような約束などないよ
最後までバカだったね
- 183 名前：,,・´∀｀・,, ：2008/08/30(土) 13:25:10 ID:DThLhIVJ
- とりあえずSSEをサポートしない64ビット拡張が未だかつて「standard」であったためしは無いからね。
AMD64/Intel64(EM64T)以外にないんだよ。
- 184 名前：Socket774 ：2008/08/30(土) 13:29:39 ID:efBh6GPC
- >>181
> さーな、俺の情報筋はWebじゃねーし。
さすがに団子の妄想を根拠に首を吊るわけにはいかんからなあ
- 185 名前：Socket774 ：2008/08/30(土) 13:31:15 ID:efBh6GPC
- >>182
> これから死ぬ人間にやるような約束などないよ
お、団子の敗北宣言か？
> scatter/gatherに限ってマイクロコード実装にしないという理由がない。
これが怪しいことに気づいたかな？
ほかの軒かな？
- 186 名前：,,・´∀｀・,, ：2008/08/30(土) 13:31:50 ID:DThLhIVJ
- じゃ、MACヲタの出したソースを根拠に死ね
- 187 名前：Socket774 ：2008/08/30(土) 13:35:44 ID:efBh6GPC
- >>175
> scatter/gatherに限ってマイクロコード実装にしないという理由がない。
ごく一般的な物の考え方として、マイクロコードとステートマシンの二通り(と、その組み合わせ)がある場合には
それぞれの長所短所を考えるものだが、団子にはそんなことが念頭によぎった気配すらない
- 188 名前：MACオタ＞団子 さん ：2008/08/30(土) 13:36:07 ID:rRKT6K+V
- >>183
いまのところ>>96の意見なので、私を引き合いに出すのわ勘弁して欲しいす。
---------------------
とりあえずSSEをサポートしない64ビット拡張が未だかつて「standard」であったためしは無い
---------------------
この業界、自分に都合の良い部分だけ切り取って『業界標準』(industry standard)を名乗るのわ、
ありふれた話なんすけど。。。
- 189 名前：MACオタ＞団子 さん ：2008/08/30(土) 13:44:32 ID:rRKT6K+V
- >>175
補足すけど、これスカラ整数ユニット限定す。
-----------------
LarrabeeがP5が土台ということはマイクロコードベースなんだよ。
-----------------
躁状態になると騙りやらコピぺやら、何でもアリの相手すから、死ね死ね言わない方が良いと
思うすけどね。。。
- 190 名前：,,・´∀｀・,, ：2008/08/30(土) 13:46:33 ID:DThLhIVJ
- 既存のIAでSSEのミスアラインドロード・ストア命令は例外なくマイクロコードだったな。
agner.orgにオペレーション数の解析結果まで載ってる。
複数回かかる仕様のロード・ストア命令がマイクロコード実装なのは
P5以降Intelアーキテクチャでは100％そうだし
逆に、実行ユニットで初めて分解するようなのはP5ベースではなく
新規のマイクロアーキテクチャということになってしまう。
実行ステージに突っ込むまでサイクル数が解らないオペレーションなんて、
スケジューラで管理しきれないしさ(笑
- 191 名前：MACオタ＞団子 さん ：2008/08/30(土) 13:49:23 ID:rRKT6K+V
- >>190
------------------
既存のIAでSSEのミスアラインドロード・ストア命令は例外なくマイクロコードだったな。
agner.orgにオペレーション数の解析結果まで載ってる。
------------------
複数のuopsに分解するという話と、マイクロコード実行わ『別物』でわ？
- 192 名前：,,・´∀｀・,, ：2008/08/30(土) 13:54:28 ID:DThLhIVJ
- ＞MACオタ
君の解釈は聞いてないからただソースだけを貼ってくれ。
- 193 名前：MACオタ＞団子 さん ：2008/08/30(土) 13:58:46 ID:rRKT6K+V
- >>192
x86わ良く知らないんで質問しているすけど、何か痛い所を突かれて逆切れしたすか？
- 194 名前：Socket774 ：2008/08/30(土) 13:59:14 ID:efBh6GPC
- >>192
> 君の解釈は聞いてないからただソースだけを貼ってくれ。
団子さんからこんな言葉が聞けるなんて
ちょっと感動
- 195 名前：,,・´∀｀・,, ：2008/08/30(土) 14:05:24 ID:DThLhIVJ
- >191
本質的同じものだよ。粒度が違うだけ。
IntelのいうマイクロオペレーションはP6で初めて使いだした言葉で、
マイクロコードに対してもっと粒度の小さいRISCライクオペレーションという意味。
複数マイクロオペレーション使う命令は必ずマイクロコードROMを参照する。
あ、PenM以降のμOPs Fusion可能なものだけは、一般デコーダでダイレクトにデコードできるけどね。
いずれにしても各実行ステージの手前で切り離す。
- 196 名前：MACオタ ：2008/08/30(土) 14:05:45 ID:rRKT6K+V
- 妙に報道が少なかったHot Chips 20すけど、富士通の発表もあってか安藤氏わ参加していた
様す。とりあえず今日の更新わ、Larrabeeとr龍芯、3Leaf Systems社のネットワーク経由でのccNuma
の話題す。
http://www.geocities.jp/andosprocinfo/wadai08/20080830.htm
ちなみに最後のわ、EDNのブログでも取り上げていたす。
http://www.edn.com/blog/980000298/post/450032245.html
- 197 名前：MACオタ＞団子 さん ：2008/08/30(土) 14:08:13 ID:rRKT6K+V
- >>195
----------------
本質的同じものだよ。粒度が違うだけ。
----------------
それでわ、何故マイクロコード実行わCRISCの概念より古いすか？
agner氏の資料を見れば明らかなように、単一のuopsで複数サイクル実行のモノもあるし。。。
- 198 名前：,,・´∀｀・,, ：2008/08/30(土) 14:16:45 ID:DThLhIVJ
- 浮動小数のこと？
P5にはP6にあるようなfxchによる依存関係の解消の機構がないから
レイテンシがそのままサイクル数になってしまうだけだよ。
- 199 名前：,,・´∀｀・,, ：2008/08/30(土) 14:19:02 ID:DThLhIVJ
- ロードやストア回数が複数にわたる場合は必ずその回数分以上の
マイクロコードあるいはマイクロオペレーション数に分解されているはずだ。
- 200 名前：,,・´∀｀・,, ：2008/08/30(土) 14:21:29 ID:DThLhIVJ
- おっとrepは小さいループに変換されるだけだがな
- 201 名前：MACオタ＞団子 さん ：2008/08/30(土) 14:25:33 ID:rRKT6K+V
- >>198
----------------
P5にはP6にあるようなfxchによる依存関係の解消の機構がないから
----------------
P5にuops分解機能わ無いす。P6で複数サイクル実行のuopsを含む命令わ、
IMUL, AAM, DIV, IDIV, 複雑なFP命令(SSE含)す。
- 202 名前：Socket774 ：2008/08/30(土) 14:29:48 ID:efBh6GPC
- >>199
ARMでもか？
- 203 名前：MACオタ＠補足 ：2008/08/30(土) 14:33:09 ID:rRKT6K+V
- 別にもったいをつけるつもりわ無いすけど、ハードウェアロジックでも複数のユニットを占有したり、
回帰計算を行うために複数サイクル必要な命令わ在るす。
おそらく現代的な設計のプロセッサで、実行ステージでマイクロコードROMを一々読んでプログラムを
実行するモノわ無いと思われるす。
命令に関するエラッタが存在したとしても、パッチわデコードユニットでトラップして代替命令に置き換
える程度じゃ無いすかね。
- 204 名前：,,・´∀｀・,, ：2008/08/30(土) 14:36:54 ID:DThLhIVJ
- たとえば
add eax,[edx]
を
分解せずに実行してたのがP5まででありいわゆる従来のCISC
ロードと加算に分解して実行するのがP6でありいわゆる内部RISCと言われるやつ。
その意味ではK7やPenM以降はCRISCって言っていいのかは疑問だな。まあ最終的には分解してるんだが。
- 205 名前：,,・´∀｀・,, ：2008/08/30(土) 14:51:06 ID:DThLhIVJ
- 分解しないと実行できないような複雑命令はそもそも載せないのが
P&Hの理論にもあるような純RISCだったじゃね？
複雑な命令の実行をマイクロコードに頼ってたのはCISC
でも昔ながらのRISCをうたうCellですら倍精度はマイクロコードだったような。POWERには8バイト命令もあって、固定長ですらないしな。
CISC/RISC論は既に現代では通用しない。
- 206 名前：Socket774 ：2008/08/30(土) 14:56:26 ID:efBh6GPC
- >>205
やっぱりマイクロコードとステートマシンの違いがわかってないようだ
- 207 名前：Socket774 ：2008/08/30(土) 15:01:28 ID:efBh6GPC
- >>206
おっと、実行ユニットがマイクロコードを持っていることもあるから、正しく団子用語の
>>168
> パイプラインにおいて、パラメータに依存して複数サイクルかかるような複合タイプの命令を、
> マイクロコードに置き換える機能があるのは次のうちどれでしょう？
>
> 1.デコーダ
> 2.実行ユニット
- 208 名前：,,・´∀｀・,, ：2008/08/30(土) 15:27:17 ID:DThLhIVJ
- ＞実行ユニットがマイクロコード
はい？
それいつの時代のどこのアーキテクチャですか？
もちろんIntelのP5以降のCPUの話ですよね？
パイプライン化すらされてない時代の話なら笑うしかないよ？
ま、どっちにしろ、まだExecuteにも達してないフェンス命令が前の命令の例外が起きてもパイプラインから棄てられないなんて
脳内動作の根拠にはならないんだが。
- 209 名前：,,・´∀｀・,, ：2008/08/30(土) 15:32:52 ID:DThLhIVJ
- まあ、こいつはおそらくP5以降のIntelアーキテクチャのブロックダイアグラムで
マイクロコードROMがどこにぶら下がってるか見たこともないんだろうな。
デコーダで解決した方がデコード後のスケジューリングコストがかからないんだけどな。
- 210 名前：Socket774 ：2008/08/30(土) 15:46:12 ID:efBh6GPC
- >>208
> ま、どっちにしろ、まだExecuteにも達してないフェンス命令が前の命令の例外が起きてもパイプラインから棄てられないなんて
> 脳内動作の根拠にはならないんだが。
そりゃこんなこと言ってるの団子だけだし
おれが言ってるのは「例外ハンドラ内で」フェンス命令を実行した場合
- 211 名前：,,・´∀｀・,, ：2008/08/30(土) 15:51:03 ID:DThLhIVJ
- ＞例外ハンドラ内で
バカすぎる
なんの目的で使うんだよ
お前プログラム組んだことないだろ
- 212 名前：,,・´∀｀・,, ：2008/08/30(土) 15:58:26 ID:DThLhIVJ
- あ、例外発生前にパイプラインに投入されたフェンス命令が例外後も残ってるなんてのは論外な
- 213 名前：272 ：2008/08/30(土) 16:06:43 ID:efBh6GPC
- >>211
> ＞例外ハンドラ内で
> バカすぎる
> なんの目的で使うんだよ
あっ、団子は例外ハンドラがどういうものか理解してなかったんだよな、ゴメンゴメン
例外が発生した後は、どうしても
・共有データであるところのページテーブルを更新したり
・ページインのためにI/Oを開始
したりするんだぜ？
バカでもわかりやすいかと思って「例外ハンドラ内で」というシチュエーションを考えたけど、逆効果だったかな
例外ハンドラから抜けてからフェンス命令を発行しても同じこと
中断したscatterの扱いはどうなるの？
- 214 名前：,,・´∀｀・,, ：2008/08/30(土) 16:13:35 ID:DThLhIVJ
- 余談だけど、ノンテンポラルストアはLarrabeeにおいてはキャッシュプライオリティモデル
おける優先度最低のそのまた下と位置付ければ、
プライオリティモデルに基づく既存プロトコルの延長でL1をスルーする動作を実現できるかもしれないね。
実装次第ではフェンス命令はNOP扱いしてよくなる。
- 215 名前：Socket774 ：2008/08/30(土) 16:20:58 ID:efBh6GPC
- >>214
上半分もトンチキだが
> 実装次第ではフェンス命令はNOP扱いしてよくなる。
まーだこんなこと言ってやがんの
プププのプ
- 216 名前：,,・´∀｀・,, ：2008/08/30(土) 16:24:30 ID:DThLhIVJ
- ＞例外ハンドラ
昔は知らんが最近はC++/javaでいうcatchブロックなんかののことを言う。
現行32ビットアーキでは復帰可能なページフォルトはCPU内で解決される。
OS→アプリに通知されるのは無効命令やアクセス違反など続行不可能なもの。
何年もののバカだよ
- 217 名前：,,・´∀｀・,, ：2008/08/30(土) 16:27:39 ID:DThLhIVJ
- まあ#PFが飛んでくる条件なんて32ビットOSのソースもさわったことないおっさんには解らんだろうがな
レベル低すぎる
- 218 名前：,,・´∀｀・,, ：2008/08/30(土) 16:33:15 ID:DThLhIVJ
- まさかリアルモードでSSE使おうとか思ってねーよな？
- 219 名前：Socket774 ：2008/08/30(土) 16:38:31 ID:efBh6GPC
- >>216
団子はちゃんと答えてくれるんで好感度は高いが
> ＞例外ハンドラ
> 昔は知らんが最近はC++/javaでいうcatchブロックなんかののことを言う。
一般的に例外ハンドラというのは、CPUが例外を起したときに、例外ベクトルテーブルを参照して飛んでいく先のこと
団子も説明も嘘ではないけど、文脈的におかしいんだわ
x86だと、IDTで例外ベクトルテーブルを指定してたっけ
インテルのマニュアルにも例外ハンドラの説明あると思うよ
> 現行32ビットアーキでは復帰可能なページフォルトはCPU内で解決される。
それはページミスの説明
> OS→アプリに通知されるのは無効命令やアクセス違反など続行不可能なもの。
ページフォールトは、こちらの続行不可能なものに入る
これでは話が通じないわけだ
- 220 名前：,,・´∀｀・,, ：2008/08/30(土) 16:43:26 ID:DThLhIVJ
- だからOSのソースも読まずに妄想ほざいてろ。
どこに例外拾って*fenceを呼ぶ実装があるんだよ。
Linuxカーネルのソースでもgrepして引っかからないのを確認して
そして即刻氏ね
- 221 名前：Socket774 ：2008/08/30(土) 16:50:11 ID:efBh6GPC
- 一番シンプルな説明だと
TLBにヒットしない→ページミス
ページミスすると、CPUが自動的にページテーブルを参照して、必要なページテーブルエントリを探す
必要なページテーブルエントリがない場合→ページフォールト
ページフォールトが発生すると、CPUは例外テーブルを参照して、(通常はOS内の)例外ハンドラに制御がうつる
- 222 名前：,,・´∀｀・,, ：2008/08/30(土) 16:51:32 ID:DThLhIVJ
- はい、その時点で復帰不可能だよ。
- 223 名前：Socket774 ：2008/08/30(土) 16:53:11 ID:efBh6GPC
- >>222
復帰不可能というのをどういう意味で使っているのかがわからんのだが
少なくとも半分は正しい
とりあえず>>221を理解して、
> 現行32ビットアーキでは復帰可能なページフォルトはCPU内で解決される。
これを撤回してくれるかな？
- 224 名前：,,・´∀｀・,, ：2008/08/30(土) 16:54:22 ID:DThLhIVJ
- めんどいからLinuxカーネルソースでいうどこのコードの何行目でやってるか引用してみろ。
- 225 名前：Socket774 ：2008/08/30(土) 16:58:04 ID:efBh6GPC
- >>224
お前さんが一般論が苦手なのは知っているが、説明のためのただの一例に、そのまでするのはやなこった
- 226 名前：,,・´∀｀・,, ：2008/08/30(土) 16:58:05 ID:DThLhIVJ
- OSに飛ぶ段階で既にOSがフェンスを呼ぶ必要はない。
それとも、キャッシュをバイパスして例外ハンドラのコードをフェッチできるんか？
- 227 名前：Socket774 ：2008/08/30(土) 17:00:37 ID:efBh6GPC
- >>226
> OSに飛ぶ段階で既にOSがフェンスを呼ぶ必要はない。
なんか妙なこだわりがあるな
ページフォールトを起こした命令と、OS内(でもどこでも)のフェンス命令は、無関係だよ
ページフォールトが「起きたから」、フェンスを呼ぶ必要があると捉えているなら、間違いだ
- 228 名前：Socket774 ：2008/08/30(土) 17:03:06 ID:efBh6GPC
- アプリプログラマの団子とは縁のない命令だが、iretにはそもそも逐次化作用があるんだけど、忘れてたのかな？
- 229 名前：Socket774 ：2008/08/30(土) 17:05:19 ID:DThLhIVJ
- OSがトラップする前にCPUは自分自身である程度の後始末はすんでる。
とりあえず例外ハンドラの実装読んでみろと。
読まないことには始まらない。
- 230 名前：,,・´∀｀・,, ：2008/08/30(土) 17:07:25 ID:DThLhIVJ
- 俺が指摘するまでCPUIDのフェンス効果も知らなかったバカがなんか言ってるよ
- 231 名前：Socket774 ：2008/08/30(土) 17:08:43 ID:efBh6GPC
- >>229
> OSがトラップする前にCPUは自分自身である程度の後始末はすんでる。
どういう例外の場合にはどういう処理をするのかな？
ニヤニヤ
- 232 名前：,,・´∀｀・,, ：2008/08/30(土) 17:13:59 ID:DThLhIVJ
- Intelが64ビット拡張が「standard」であることを示すソースを未だに探せない頭の悪い子にはうまく説明する自信がないな。
ヒント：今年で20回目
- 233 名前：Socket774 ：2008/08/30(土) 17:15:50 ID:efBh6GPC
- >>232
話を逸らさなくても優しくしてやるから、ページミスとページフォールトの違いについては理解できたかな？
- 234 名前：,,・´∀｀・,, ：2008/08/30(土) 17:16:23 ID:DThLhIVJ
- ていうか>>113
- 235 名前：,,・´∀｀・,, ：2008/08/30(土) 17:20:47 ID:DThLhIVJ
- まあトラップの仕組みはまあいいよ。ミスした命令を再実行すればいいじゃん。
どう考えても破棄可能なバッファは必要ないね。
- 236 名前：Socket774 ：2008/08/30(土) 17:21:53 ID:efBh6GPC
- >>234
Plus standard 64-bit instruction extensions
は
Plus Intel64(R) instruction extensions
じゃないよね？
- 237 名前：Socket774 ：2008/08/30(土) 17:24:19 ID:efBh6GPC
- >>235
> まあトラップの仕組みはまあいいよ。ミスした命令を再実行すればいいじゃん。
誤ちを認めてくれるのは結構なこった
が、気軽に
> ミスした命令を再実行すればいいじゃん。 どう考えても破棄可能なバッファは必要ないね。
こんなことを言ってくれるようでは困る
- 238 名前：,,・´∀｀・,, ：2008/08/30(土) 17:26:27 ID:DThLhIVJ
- で、なんで二度書きしたら困るんだ？ﾆﾔﾆﾔ
- 239 名前：Socket774 ：2008/08/30(土) 17:27:39 ID:efBh6GPC
- >>238
アプリプログラマの知らなくていいことだけど、I/Oなんかの都合上とてもまずい
- 240 名前：,,・´∀｀・,, ：2008/08/30(土) 17:28:09 ID:DThLhIVJ
- >>236
どこにx64以外のstandardがあるんですか？バカですか？
だからとっとと死ね
- 241 名前：,,・´∀｀・,, ：2008/08/30(土) 17:30:30 ID:DThLhIVJ
- I/Oの都合がある処理でSSEなんて使わないから。ハイハイ
- 242 名前：,,・´∀｀・,, ：2008/08/30(土) 17:33:43 ID:DThLhIVJ
- むしろ規格準拠くらいの意味だな
- 243 名前：Socket774 ：2008/08/30(土) 17:39:08 ID:efBh6GPC
- >>241
> I/Oの都合がある処理でSSEなんて使わないから。ハイハイ
団子の大好きなインテルのマニュアルに、I/O領域に対するメモリアクセス禁止って書いてあるの？
- 244 名前：,,・´∀｀・,, ：2008/08/30(土) 17:42:58 ID:DThLhIVJ
- ＞I/O領域
ハードウェア予約領域のことか？
そもそもアプリじゃさわりませんｗｗｗ
- 245 名前：Socket774 ：2008/08/30(土) 17:47:00 ID:efBh6GPC
- >>244
アプリプログラマに聞く質問じゃなかったサーセン
- 246 名前：,,・´∀｀・,, ：2008/08/30(土) 18:01:52 ID:DThLhIVJ
- ライトコンバインなんてカーネルモードですらやんねーよ普通
マルチスレッドなんぞ論外だし
- 247 名前：,,・´∀｀・,, ：2008/08/30(土) 18:09:27 ID:DThLhIVJ
- カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。
- 248 名前：MACオタ＠補足 ：2008/08/30(土) 19:32:01 ID:rRKT6K+V
- >>247で団子さんの書いているのわ、この話題す。(ということで良いすか？)
http://www.nabble.com/ABI-change-for-device-drivers-using-future-AVX-instruction-set-tc18116359.html
- 249 名前：Socket774 ：2008/08/30(土) 19:54:26 ID: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 名前：,,・´∀｀・,, ：2008/08/30(土) 20:02:01 ID:DThLhIVJ
- 聞いてない。
x86の64ビット拡張の「standard」とは何ですか？
さっさとけじめつけろや、ｺﾞﾙｧ
- 251 名前：Socket774 ：2008/08/30(土) 20:06:02 ID:efBh6GPC
- >>250
インテルがIntel64(R)でなくstandardとしか言ってない以上、わかるかボケ
- 252 名前：Socket774 ：2008/08/30(土) 20:06:59 ID:efBh6GPC
- >>250
んで、
団子> カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。
のソースは>>248でいいのか
いいわきゃないよな？こんな恥かしい間違いわ
- 253 名前：,,・´∀｀・,, ：2008/08/30(土) 20:14:00 ID:DThLhIVJ
- standardがx64以外にあるかボケ
詭弁も甚だしい
結論から言ってカーネルモードで使えるけど保証はないのはガチ。
- 254 名前：Socket774 ：2008/08/30(土) 20:15:59 ID:efBh6GPC
- >>253
団子> カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。
誰がどこから何という回答を貰ったのかな～？
Agnerという人は"One problem that has not been resolved yet"って言ってるよ
- 255 名前：Socket774 ：2008/08/30(土) 20:18:24 ID:efBh6GPC
- >>253
おっと
> 結論から言ってカーネルモードで使えるけど保証はないのはガチ。
「保証はないのはガチ」ってねえ、>>248のリンク先ちゃんと読んだの？
memcpyのあたりだよ
- 256 名前：Socket774 ：2008/08/30(土) 20:19:42 ID: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 名前：,,・´∀｀・,, ：2008/08/30(土) 20:19:53 ID:DThLhIVJ
- 「死人」には黙ってて貰いたい。ゾンビくん。
俺は一切回答もしないよ。
それとも未だにx64非準拠の確信(笑)あるのかな
単に生きたいだけかな？ｗｗｗ
- 258 名前：Socket774 ：2008/08/30(土) 20:23:08 ID:efBh6GPC
- >>257
> 俺は一切回答もしないよ。
まあ、これ以上何か言ったところで恥の上塗りだから、それがいいと思うよ
> カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。
団子の英語力からすれば>>248を理解できなかったは不思議ではないが、これは許してやんよ
まさかお前の妄想に箔をつけるためにAgner氏の名前をデッチ上げたんじゃないだろうな
- 259 名前：Socket774 ：2008/08/30(土) 20:24:02 ID:0ZjjQu1D
- で、ローエンドGPUのlarrabeeでXが使えるようになると
何が面白いのかね
- 260 名前：,,・´∀｀・,, ：2008/08/30(土) 20:25:40 ID:DThLhIVJ
- 生き恥がなんか言ってるよｗｗｗ
ま、ライトコンバインなんかまともに動く保証はないんじゃね？
- 261 名前：Socket774 ：2008/08/30(土) 20:28:09 ID:efBh6GPC
- >>260
今なら白状しても許すよ
「わたくしこと団子は、Agner氏の名前で大嘘をデッチあげました」
> ま、ライトコンバインなんかまともに動く保証はないんじゃね？
SSE完全互換じゃなかったの？？
- 262 名前：Socket774 ：2008/08/30(土) 20:29:51 ID: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 名前：,,・´∀｀・,, ：2008/08/30(土) 20:39:01 ID:DThLhIVJ
- ＞Xが使える
生き恥のさらに上塗りだな。
「X」なんてVESA準拠のカードなら専用ドライバなんてなくても使えるよ。
GPUの機能使わずフレームバッファに直に書くだけならな。
PS3のLinuxもRSXのドライバは用意されてない（アクセスすら禁止されてる）がGNOMEが普通に立ち上がる。
ま、OpenGLのドライバが使えるのは有意義だよ。かなり。
ぶっちゃけMS環境自体にはあまり期待できないんだよ。
メニーコア周りのサポートとか。
未だに上限32or64スレッドまでしか使えないし。
その点、IntelコンパイラもLinux版は無償で使えるからな。
- 264 名前：Socket774 ：2008/08/30(土) 20:42:21 ID:0ZjjQu1D
- だからそれの何が面白いことになったの？
発言者さん
- 265 名前：Socket774 ：2008/08/30(土) 20:44:14 ID:efBh6GPC
- Larrabeeでlinuxを動かして、本体CPUをXアクセラレータにして遊ぶ
- 266 名前：Socket774 ：2008/08/30(土) 20:48:09 ID:4mz2eK7O
- x用のドライバが出来ても
OpenGLが使えるかどうかってのは
また別なはなしだが
- 267 名前：,,・´∀｀・,, ：2008/08/30(土) 20:49:17 ID:DThLhIVJ
- 専用ドライバなしでもWindowsすら動くしな
死ぬほど遅いけどww
よりにもよって「Xが動く」ｗｗｗｗｗｗ
ドライバすらいらねーっつーのｗｗｗｗｗｗ
- 268 名前：,,・´∀｀・,, ：2008/08/30(土) 20:50:22 ID:DThLhIVJ
- >>266←ｗｗｗｗｗｗ
- 269 名前：Socket774 ：2008/08/30(土) 20:51:21 ID:efBh6GPC
- おい団子、他の人に迷惑かけるな
団子> カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。
これのソースはどこなんだよ
- 270 名前：,,・´∀｀・,, ：2008/08/30(土) 20:53:44 ID:DThLhIVJ
- MACヲタに代理回答なんて頼んだ覚えはないが。
ま、推奨か非推奨かはIntelのマニュアルにもあることだな
- 271 名前：,,・´∀｀・,, ：2008/08/30(土) 20:56:20 ID:DThLhIVJ
- 死人は棺桶のなかでおとなしくしてて下さい。
書き込むだけで迷惑ｗｗｗｗｗｗ
Intelがｗｗｗｗｗｗ
Larrabeeでｗｗｗｗｗｗ
SSEをｗｗｗｗｗｗ
サポートしたくないｗｗｗｗｗｗ
- 272 名前：,,・´∀｀・,, ：2008/08/30(土) 20:58:45 ID:DThLhIVJ
- 「IntelはSSEをサポートしたくない」のソースをお願いします。
他人にソースを求める立場ではないの自覚しような
- 273 名前：Socket774 ：2008/08/30(土) 21:01:25 ID:NI1xX8WB
- x.orgのドライバーだけでGLXが動くと思ってる馬鹿がいるな
仕様を公開してるATIやVIAならともかく・・
- 274 名前：,,・´∀｀・,, ：2008/08/30(土) 21:02:28 ID:DThLhIVJ
- フェンス命令に中途半端に完了
のソースまだー？
死人に無知鬱
- 275 名前：MACオタ＞269 さん ：2008/08/30(土) 21:04:51 ID: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 ：2008/08/30(土) 21:06:40 ID:CvxpbjGE
- 団子は何か勘違いしている
おれのは予想で、出しているのは傍証
証拠もないのに事実だと決めつけているのはお前だけだ
予想と事実、傍証と証拠の違いくらいわかるよな？
- 277 名前：MACオタ＠補足 ：2008/08/30(土) 21:06:45 ID:rRKT6K+V
- Arjan van de Ven氏の身分の参考に。
http://www.linuxjournal.com/content/interview-arjan-van-de-ven-intel-and-lesswattsorg
-------------------
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 名前：,,・´∀｀・,, ：2008/08/30(土) 21:09:05 ID:DThLhIVJ
- GLXｗｗｗｗｗｗ
つかOpenGL自体プログラミングスタックにあるし。
IntelがLinux環境に好意的なのは有名な話だしな。
AtomベースMIDのSDKはLinux版以外あったっけな
- 279 名前：,,・´∀｀・,, ：2008/08/30(土) 21:12:03 ID:DThLhIVJ
- 「Standard」の意味が解らないと見苦しい事を言ってる馬鹿ならいるな
- 280 名前：,,・´∀｀・,, ：2008/08/30(土) 21:17:29 ID:DThLhIVJ
- standard 64-bit extensionの意味も解らないって素敵だね。
英語がわからないから約束守る必要ないなんて理屈がまかり通るなら
英語知らない方がいいようだな
- 281 名前：,,・´∀｀・,, ：2008/08/30(土) 21:19:18 ID:DThLhIVJ
- standard 64-bit extensionにフェンス命令は含まないんですか？
Intelは含めたくないんですか？
- 282 名前：,,・´∀｀・,, ：2008/08/30(土) 21:21:40 ID:DThLhIVJ
- P5アーキがデコーダでマイクロコードに展開するという常識もない人間に傍証も糞もない
詭弁とこじつけだけ
- 283 名前：Socket774 ：2008/08/30(土) 21:22:24 ID:0ZjjQu1D
- はいはーい、またまた精神破綻者の独り言の始まり始まり
- 284 名前：,,・´∀｀・,, ：2008/08/30(土) 21:26:53 ID:DThLhIVJ
- あ？精神病がなんか言ってるよ
死ぬって言って死なないのはメンヘル女の特権だぞボケ
男ならけじめつけろや
- 285 名前：Socket774 ：2008/08/30(土) 21:32:29 ID:CvxpbjGE
- >>275
続きがあったのは気づかなかったが
Arjanとケンカしてんじゃん
Andiの指摘までAgnerは納得してない
だいたいこれ、Linux固有の話しじゃん
一般論のできない君らとはいえ、こいつぁひどい
- 286 名前：,,・´∀｀・,, ：2008/08/30(土) 21:36:02 ID:DThLhIVJ
- P5のマイクロコードがデコーダから供給されることも知らない人の一般論には
説得力があるな
- 287 名前：Socket774 ：2008/08/30(土) 21:42:24 ID:CvxpbjGE
- >>286
捏造するのはヤメテ
罵倒するときはアンカーつけて
- 288 名前：,,・´∀｀・,, ：2008/08/30(土) 21:47:28 ID:DThLhIVJ
- AMD64/Intel64はx86の64ビット拡張のstandardでない
ですね、わかります
- 289 名前：,,・´∀｀・,, ：2008/08/30(土) 21:51:28 ID:DThLhIVJ
- SSEやCPUIDを排除してLNIをサポートしたのを64ビット新標準にすればいいですね、わかります
- 290 名前：Socket774 ：2008/08/30(土) 21:52:44 ID:CvxpbjGE
- >>288
十分条件と必要条件の区別のつかない団子らしい発言です
- 291 名前：Socket774 ：2008/08/30(土) 21:56:36 ID:CvxpbjGE
- >>289
CPUIDを実装しないなんて一言も言ってないが
他人を罵倒するために捏造するのはやめて
- 292 名前：Socket774 ：2008/08/30(土) 21:57:06 ID:lAKSJLJJ
- 確かに288は頭の悪すぎる発言だなw
- 293 名前：Socket774 ：2008/08/30(土) 21:59:23 ID:CvxpbjGE
- 捏造しているのか、理解できていないのかはともかく、
罵倒するときはアンカーかコピペたのんます
- 294 名前：,,・´∀｀・,, ：2008/08/30(土) 22:01:24 ID:DThLhIVJ
- x86アーキにおいてスタンダードな64ビット拡張であるにはx64準拠は必要条件。
x64準拠であることはSSEサポートの十分条件。
ですね、わかります。
わかったら氏ね
- 295 名前：,,・´∀｀・,, ：2008/08/30(土) 22:03:59 ID:DThLhIVJ
- standardであることとSSEをサポートしないことは「矛盾」
- 296 名前：,,・´∀｀・,, ：2008/08/31(日) 01:25:06 ID:AQd+hwdB
- 完璧であったはずの論理が覆されたのはどう思った？
- 297 名前：,,・´∀｀・,, ：2008/08/31(日) 02:01:44 ID:AQd+hwdB
- 前提に誤りがあると微塵も思わないんだもんなー
固定観念に縛られすぎて常識とずれてしまってることは自覚しような。
- 298 名前：,,・´∀｀・,, ：2008/08/31(日) 09:11:17 ID:AQd+hwdB
- 「ページフォールト時のスワップ処理」
→ビデオカードにはそもそもスワップできるデバイスなんて載らないよ。フローなんて復帰できるわけがないよ。
あとHPC版はメモリ馬鹿みたいに積むからなあ。スワップ？なにそれおいしいの？
ま、スワップアウトありでいいや。でも
「ページ解決後に2度書きするのイクナイ！」
→なんならプログレスカウントに汎用レジスタでも使う仕様にすれば？
たとえば1ビット×16でストア対象要素を指定し、正常完了したものから対応するビットにマスクをかける。
最終的に0またはFFFFになる。そうすれば途中中断しても復帰できるよ。
スカラとベクタは並列実行できるし。
「メモリコンシステンシモデルを緩める必要がある」
→だからそうすればいいじゃん。フェンス命令の実装関係ない。
「SSEは非対応。x64とは非互換になる」→Intelは標準の64ビット拡張と言ってはりますよ。どこにそんな標準があるんですか？
- 299 名前：,,・´∀｀・,, ：2008/08/31(日) 10:13:18 ID:AQd+hwdB
- ま、せっかくだから「ぼくのかんがえたさいきょうのめいれい」書いておくか。ま、我ながらいかにも「Intelアーキらしい」仕様だな
vscatvps [mem32],zmm1,zmm2
[mem]：起点アドレス
zmm1：ストアデータ
zmm2：アドレスのオフセット×16
ecx：下位16ビットで処理するビットのマスクを指定。ストア毎に順次要素に対応するビットをマスクしていく。
これもあくまで一案だが、デコーダのマイクロコードで実装するから可能な仕様だな。
VPU実行ステージでマイクロコード分解するなんてIntelが経験したことない珍妙な仕様じゃ不可能だよね。
ストリング命令同様、スワップを挟んでも復帰できる仕様は満たせる。
ま、俺も彼の言い分を理解してなかったのは認める。
カーネルソース読んでみて言いたいことの意味分かったよ。
俺もスワップなんて想定してるとは想定外だったからね。
ビデオカードにHDDでも接続するなんて発想はなかったからさｗｗｗ
HPC版じゃスワップなんて普通させないくらいメモリ積むだろうし。
- 300 名前：Socket774 ：2008/08/31(日) 14:35:28 ID:K6NM5XfT
- WDDM2.0からVRAMをスワップアウトするようになったはずだけど
- 301 名前：MACオタ ：2008/08/31(日) 16:12:55 ID: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オタ＠補足 ：2008/08/31(日) 16:36:43 ID:Ng1mcTQb
- "xxpermdi"命令すけど、DMフィールドが4-bitなら曲がりなりにもvector permuteっぽい動作に
なるすけど、何故か2-bitの模様す。単なるコピーとやsplat命令、"xxmrghd", "xxmrgld"命令と組み
合わせて全16通りをカバーするのかもしれないす。
でも、これ並べ替えをレジスタの内容でダイナミックに変更できるAltivecのvperm命令と比較すると
命令や直値で指定するのって、何か意味があるすかね？
- 303 名前：,,・´∀｀・,, ：2008/08/31(日) 16:49:46 ID:AQd+hwdB
- 決めうちできる場合は1命令減らせる。
- 304 名前：MACオタ＠訂正 ：2008/08/31(日) 17:08:26 ID:Ng1mcTQb
- 自分でカーネルプログラミングに浮動小数点わ無い(>>275参照)とか書いておきながら、データを
倍精度浮動小数点とか書いていたのわ大間違いす。ニーモニックに含まれる"d"わ"Doubleword"の
略すね。。。
で、命令の行わ修正す。
- 命令 (XT/XS/XA6/XB6: VSXレジスタ, RA/RB, 汎用レジスタ)
lxvd2x XT, RA, RB (Load Doubleword X-Vecor Indexed X-form ?)
RAとRBの和で求められる実効アドレスから2つの64-bit整数データをXTにロード
lxvd2ux XT, RA, RB (Load Doubleword X-Vecor with Update Indexed X-form ?)
RAとRBの和で求められる実効アドレスから2つの64-bit整数データをXTにロード後、
RAに実効アドレスを格納
stxvd2x XS, RA, RB (Store Doubleword X-Vector Indexed X-form ?)
RAとRBの和で求められる実効アドレスへXSの内容(64-bit整数 x 2)をストア
stxvd2ux XS, RA, RB (Store Doubleword X-Vector with Update Indexed X-form ?)
RAとRBの和で求められる実効アドレスへXSの内容(64-bit整数 x 2)をストア後、RAに実効アドレス
を格納
xxmrghd XT6, XA6, XB6 (X-Vector Marge High Doubleword ?)
XA6の上位64-bit整数データとXB6の上位64-bit整数データを並べてXT6に格納
xxmrgld XT6, XA6, XB6 (X-Vector Marge Low Doubleword ?)
XA6の下位64-bit整数データとXB6の下位64-bit整数データを並べてXT6に格納
xxpermdi XT6, XA6, XB6, DM (Permute Doubleword Immediate ?)
XA6とXB6の64-bit整数ベクトルを2bitのDMフィールド表現に従って並び替えてXT6へ
格納
xvcpsgndp XT6, XA6, XB6 (X-Vector Copy Sign of Doubleword?)
XB6の64-bit整数ベクトルを符号ビットのみXA6からコピーして、XT6へ格納
- 305 名前：MACオタ＞団子 さん ：2008/08/31(日) 17:10:22 ID:Ng1mcTQb
- >>303
なるほど、コメント感謝するす。
- 306 名前：,,・´∀｀・,, ：2008/08/31(日) 17:36:45 ID:AQd+hwdB
- AVXのvpermil2psって便利だな。
xmm1,xmm2,xmm3,xmm4から任意の要素をピックアップしてxmm0にマージする場合
メモリにパターンデータを用意しておいて
vmovdqa xmm7,[mem]
vpermil2ps xmm0,xmm1,xmm2,xmm7,2
vpermil2ps xmm5,xmm3,xmm4,xmm7,3
vorps xmm0,xmm0,xmm5
逆に256ビット版がいまいち使いにくい。128ビット版AVXの2並列実行でしかないからね。
- 307 名前：GPU ：2008/08/31(日) 21:28:38 ID:AQd+hwdB
- >300
GPUが自発的に？
- 308 名前：Socket774 ：2008/08/31(日) 22:27:52 ID:VTeVamka
- >>307
「自発的に」の意味を明確にしてくれないとなんとも。
CPUのスワップアウトだってCPUが「自発的に」HDDにアクセスするなんて曖昧な表現しないだろ？
もっとも、4亀によればOSに対してGPU自身が「自発的に」スワップアウトを要求するそうだけど。
多分GPUがやる仕事は、コマンドプロセッサでタスク毎にメモリ不足を検出してドライバ側に通知するのと
ドライバが用意したスペースにDMA転送するくらいだろうね。
ttp://www.4gamer.net/news/history/2006.05/20060530200736detail.html
- 309 名前：Socket774 ：2008/08/31(日) 22:47:27 ID:PukrVIoW
- 団子の実装では、Larrabeeは自意識に目覚めて自発的にページングします
- 310 名前：Socket774 ：2008/08/31(日) 22:57:40 ID:PukrVIoW
- 書き込み制限が解除されたよ！
>>298
言い訳がまじっていて見苦しいが、そう的を外してなさそうだからいいか
ダ> 「メモリコンシステンシモデルを緩める必要がある」
ダ> →だからそうすればいいじゃん。フェンス命令の実装関係ない。
これは半分正しいし、半分は団子の主張と一貫性が書けてるんだ
- 311 名前：,,・´∀｀・,,）っ ：2008/08/31(日) 23:00:35 ID:AQd+hwdB
- マイクロOS側で透過的にやれるのか、ホスト側のドライバで確保してやるのかって話だよ。
SSEをサポートしてないことにしたい珍説の新作が見たいものだ。
- 312 名前：,,・´∀｀・,,）っ ：2008/08/31(日) 23:11:09 ID:AQd+hwdB
- 現時点の公開情報をみてもSSE非サポートってのはまずあり得ないわけだし、
スワップを考慮した実装要件から新命令の仕様考える方が有意義だと思うけどね。
新命令の仕様の思いこみありきで整合の取れない既存の概念を否定しようとするから
事実上の自殺宣言になっちゃうんだよ。
ちなみに俺はx64命令セット準拠って最初から知ってたぞ。何度も言うことだけど。
- 313 名前：Socket774 ：2008/09/01(月) 00:07:48 ID:ay7aamyT
- >>311
一応言っとくと300=308≠ID:PukrVIoWね。
透過的にとかそこら辺の具体的な意味がわからないとなんとも言えないてばさ。
- 314 名前：,,・´∀｀・,,）っ ：2008/09/01(月) 00:22:12 ID:x5FAhWGX
- 資料読んで気づいたこと
P5ではUとV、どっちでデコードするかで実行ユニットもU側かV側か決まってしまっていたが
Larrabeeはデコードは2機のうちComplex/Simpleどっちを経由してもデコード後にマイクロ命令が合流し
Scaler/Vectorどちらに流し込むか改めて振り分けを行うように見える。
この構造はぶっちゃけP5というよりはAtomに近い。
- 315 名前：,,・´∀｀・,,）っ ：2008/09/01(月) 01:55:52 ID:x5FAhWGX
- 【standard 64-bit extensionなんて表現をした理由】
他の用語を使いたくなかっただけじゃね？
・Intel 64
Core2 Duoで初めて使った言葉だから、SSSE3までを含むと誤認されるかもしれない。
・EM64T
旧称だから使いたくない
・AMD64/x86-64/x64
すごく、屈辱です
結局のところSSSE3以降をサポートしないんじゃね？デコード容易とは言い難いし。
逆に3バイトOpcodeデコードに対応するならSSE4まで全部対応できそう。
邪推してもしかたないな。
ただ単にあくまで学会発表だから、Marketecture的な名称を出すのを
避けただけという考えるのが妥当かもしれんよ。
たとえば「Hyper-Threading」ではなくSMT(FGMT)というようなレポートになってるし。
「Intel 64」とかの具体的名称が出るのは次のIDFくらいじゃね？
- 316 名前：MACオタ＞団子 さん ：2008/09/01(月) 02:26:59 ID:oXl/Aq1S
- >>315
裏を取っているなら、そんなにキョドる必要わ無いと思うすけど。。。
--------------------
・Intel 64
Core2 Duoで初めて使った言葉