[x86]CPUアーキテクチャについて語れ！[RISC]

お前らいい加減、無能なAMD房・Intel房に振りまわされず、
エンコ時間がどうとかPIがどうとかじゃなく、
CPUコアのアーキテクチャについて語りましょう。

x86/RISC/CISC/スーパースカラ/VLIW/MIMD/SIMD
等について語ってもよし、

フリップフラップ回路が小さいPentium Mマンセー、
CISCなのに内部はRISCなPentium 4マンセー、
x86なのに32/64bitコンパチなOpteronマンセー、
昔々8086の時代は(以下略・・・等もよし。

さあ、不毛な争いを止めてCPUアーキテクチャについて語ろう！

２げっとおおお

3

ヤダ！

PC用CPU作ってる主な半導体メーカ：

IBM
http://www.ibm.com/

Intel
http://www.intel.com/

AMD
http://www.amd.com/

VIA Technology
http://www.viatech.com/

お前らはこれからRISCかCISC、どちらになると思いますか？

最近は元気の無いRISC陣ですが、.net frameworkが普及すれば、
ちょっとしたきっかけで逆転するかもしれませんよ。

むつかしすぎて分かんない・・・orz

お前ら・・・まさかCPUのアーキテクチャも理解しないで、
HTだのパイプラインだの語っていたわけじゃあるまい？

なーんも知らん

禿同

http://e-words.jp/w/RISC.html

RISC　【縮小命令セットコンピュータ】
読み方 ： リスク
フルスペル ： Reduced Instruction Set Computer

マイクロプロセッサの設計様式の一つ。
個々の命令を簡略化することにより
パイプライン処理(並行して複数の命令を処理する方式)の効率を高め、
処理性能の向上をはかっている。
ワークステーション用のCPUにはこの型のプロセッサが多い。
Sun Microsystems社のSPARCや
DEC社(現在はCompaq Computer社の一部門)のAlpha、
IBM社とMotorola社のPowerPCなどが有名。

http://e-words.jp/w/CISC.html

CISC　【複合命令セットコンピュータ】
読み方 ： シスク
フルスペル ： Complex Instruction Set Computer

マイクロプロセッサの設計様式の一つ。
個々の命令を高級言語に近づけ、
複雑な処理を実行できるようにすることで処理能力の向上をはかっている。
パソコン用のCPUとしてあわせて9割以上のシェアを持つ
Intel社のx86シリーズとその互換プロセッサがこの型である。

http://e-words.jp/w/SRAM.html
SRAM
読み方 ： エスラム
フルスペル ： Static Random Access Memory

RAMの一種。記憶素子としてフリップフロップ回路を用いるもので、
記憶保持のための動作を必要としない。
そのぶん高速に動作するが、
回路が複雑になり集積度を上げにくいという欠点をもつ。

http://e-words.jp/w/E38395E383AAE38383E38397E38395E383ADE38383E38397E59B9EE8B7AF.html

フリップフロップ回路　【flip-flop circuit】
読み方 ： フリップフロップカイロ

　「high」と「low」の二つの安定状態を持つ電子回路。
二つの状態を「0」と「1」に対応させることで、1ビットの情報を保持できる。
加える信号によって二つの状態が交互に変化するようにできている。
大規模な電子回路を構成する基本的な素子で、SRAMや、
マイクロプロセッサ内部のフラグやレジスタ等の記憶回路に使われる。

ちなみに、SRAM(=フリップフラップ回路)は4〜6回路で構成され、
Intelは従来より6回路で構成するSRAMを頑なに使ってきたが、
Pentium Mでは4回路のフリップフラップ回路を使用。
電気的な特性による4回路のSRAMの脆弱性については、
公表していない方法にて解決したもよう。

http://e-words.jp/w/E38391E382A4E38397E383A9E382A4E383B3.html

パイプライン　【pipeline】
読み方 ： パイプライン

マイクロプロセッサ(MPU)の高速化手法の一つ。

　プロセッサ内での1つの命令を処理は、
命令の読み込み、解釈、実行、結果の書き込みなどのように、
複数の段階からなるサイクルで構成されている。
通常は、前の命令のサイクルが完全に終わらないと、
次の命令を処理し始めることはできない。

　各段階の処理機構を独立して動作させることにより、
流れ作業的に、前の命令のサイクルが終わる前に
次の命令を処理し始めるのがパイプライン処理である。
工場の流れ作業で使うベルトコンベヤのようなものだと言える。

　パイプライン機構を備えたプロセッサでは、
前の命令の実行を行なっているときに
次の命令の解釈を行なうといった処理が可能になる。

　複数のパイプラインで並列に命令を
処理できるようにする機構をスーパースカラという。
パイプラインのうち段階数が多いものは
「スーパーパイプライン」と呼ばれる
(最も極端なパイプラインを持つPentium 4では
特に「ハイパーパイプライン」を自称する)。

http://e-words.jp/w/E382B9E383BCE38391E383BCE382B9E382ABE383A9.html

スーパースカラ　【superscalar】
読み方 ： スーパースカラ

マイクロプロセッサ(MPU)の高速化手法の一つ。
プロセッサの中に複数の処理系統(パイプライン)を用意し、
複数の命令を並列に処理すること。

http://e-words.jp/w/VLIW.html

VLIW

読み方 ： ブイエルアイダブリュー
フルスペル ： Very Long Instruction Word

マイクロプロセッサの高速化技術の一つ。
依存関係にない複数の命令を一つの命令としてまとめて同時に実行する。
同時実行される命令の数は常に一定に保たれ、
規定の数に達しない場合は「何もしない」命令で埋められる。
1命令の長さが従来のプロセッサに比べてきわめて長いため、
このような名前で呼ばれる。


追記：有名なのはノートPCに使われているT社のCPU。

http://e-words.jp/w/SISD.html

SISD
読み方 ： シスド
フルスペル ： Single Instruction/Single Data

　マイクロプロセッサにおいて、
1つの命令で1つのデータを扱う処理方式。
SIMDやMIMDとの対比に用いられる用語である。


http://e-words.jp/w/MIMD.html

MIMD
読み方 ： ミムド
フルスペル ： Multiple Instruction/Multiple Data

複数のマイクロプロセッサを搭載した並列コンピュータ上で、
複数のプロセッサが複数の異なるデータを並行処理する方式。
SISDやSIMDとの対比に用いられる用語である。


http://e-words.jp/w/SIMD.html

SIMD
読み方 ： シムド
フルスペル ： Single Instruction/Multiple Data

マイクロプロセッサにおいて、1つの命令で複数のデータを扱う処理方式。
DSPやスーパーコンピュータで利用されている。
Intel社のマイクロプロセッサに組みこまれている
MMXやSSEなどのマルチメディア拡張機能もSIMDの応用である。


追記：1つの命令で1つのデータを処理するのがSISD、
1つの命令で複数のデータに同じ処理をするのがSIMD、
複数の命令で複数のデータを処理するのがMIMD。

パイプラインとスーパスカラ(別読：スーパースケーラ)についてご覧あれ。

第1章　パソコンの基礎知識
http://pc1.moo.jp/kiso/cpu5.htm

最近よく耳・目にするアウトオブオーダー(Out of Order)とは何だろうか？

Pentium(全)やAthlon(全)はパイプライン方式のCPUである事は言うまでもないが、
このパイプライン制御ではある問題が発生します。

パイプライン方式のプロセッサでは、その構造上、
各命令が完全に処理される前に次の命令(仮に命令2)の処理が始まる事になりますが、
この時、先に読み込まれた命令(仮に命令1)に分岐命令等が含まれていた場合、
つまり命令2が命令1の実行結果によって異なる場合、
命令2を命令1の処理完了前に読み込む事が出来ません(実際はもうちょっと複雑)。

一般的にこのような命令1と命令2の関係をインオブオーダー(In of Order)と呼び、
この関係の無い命令1と命令2の関係をアウトオブオーダー(Out of Order)と呼びます。

この時、当然アウトオブオーダー関係の命令を実行していった方が、
全体の処理時間は短くてすむことになります。
その為、最新のPC向けプロセッサでは、
出来るだけOut of Order関係の命令を同時に処理するよう、
命令の処理順序を入れ替えたりします。

また、いくら並べ替えるといっても全ての命令が
アウトオブオーダーになるわけではありませんので、
先に実行されると"予想される"命令2の処理をやってしまう、
という考え方も行われています。

この場合、予想が当たれば、分岐しない場合と同じように、
連続して次々と命令を実行出来るため大変高速です。

しかし、一度予想が外れるとそれまで処理していた
命令2の処理を中断しなければならないばかりか、
新たな(本来処理すべき)命令2の処理を初めから行わなければなりません。
このような負の遺産を一般にペナルティと呼びます。

そしてこの考え方では、どの命令2を実行するか、
その"判定があたる確立"が大変重要となります。
その判定の事を"分岐予想"と呼び、最新のプロセッサでは、
分岐予想テーブル等を用いて、当る確立を高める努力がなされています。
例えばPentium 4の分岐予想は、
80〜90%の確立で当たるといわれています。

>>1が一生懸命なのは判るが、正直カラ回り気味かと

こゆまじめな話をまじめに聞けないから便所の落書きっていわれるんだよな…

しかし信じられん。こんなにCPUスレが乱立しているから、
さぞ知識のある奴がいるのかと思ったら、
まさか誰も興味すら持たないとは・・・

削除依頼出してきた方が良いか・・・

正直SMID以外の内容は1990年(１月号ぐらい？)のSuperAsciiに全て書かれてる
今更語るほどの事でもない

そもそも板違いじゃないの？

ああすまん、１０月号だったかもしれん

そこで萌えCPU作成本みながら2ch式ﾊｲｴﾝﾄﾞCPUの設計するんじゃないのか。
自作板だけに。

いくら知識つけても、CPUの設計なんて世界中で何人がやらせてもらえるんだよ

FPGA使えば個人でもできる

>>29
AlteraMAXで4004でも作れば？('A`)

とりあえず32bit全加算器を 1段でつくるのと
32段でパイプ処理するのとを、設計して比較してみると楽しいぞ？

>>25
そんな事を書くと、
それを書きたいがためにスレ立てたのではと邪推してしまうぞ。
脳ある鷹は鷹のつめですｗ

>19
MISDは?

ARMﾜｼｮｰｨ

スルーされる>>26。

ここは15年前に2chがあったらスレになりました。

SPARCの、メモリ待ちの間に別スレッドの作業するっつー技術は面白いと思った。

>>38
たしかにSPARCは色々と面白い仕組みを搭載していると聞きいています。
そういえばAlphaも似たような仕組みを搭載していませんでした？

http://www.ieice.org/jpn/books/kaishikiji/199910/19991001.html

>>37
喪前の世界は2chだけで構成されてんのか

スーパースカラの説明にただのスカラプロセッサ
ベクトルプロセッサが全く見えてこないのは
如何なものかと。

21364は、単にコア4つ統合して4スレッド並行作業させてるだけじゃ
なかったっけか。

他のCPUだとメモリアクセス時にボケーっと待ってるのに対し、
SPARCのは別スレッドの作業して、メモリが反応する頃に
元のスレッドの作業を再開するんだと思った。

遅いと評判のC3と同じシングルスケーラコア1つで4スレッドを処理、
これを8つ格納した1個のCPUパッケージで合計32スレッドを処理する。

あまり細かい事は知らないので専門家カモン。

>>43
同時に32スレッドですか？すげーな。

Pen4やAthlonってスレッドの切り替えに何クロックくらいかかるんですか？

３クロックくらい？

>>45
スレッドの切り替え時間は，そのOSに依存する。

x86アーキテクチャについて語るだけならCPUハード部分に深入りしすぎ。
まぁ、RISCとCISCについての比較とかはx86アーキテクチャ依存部分でも
あるから解るけどさー（x86はCISC系）

で、ついでに上記の補足CISCは従来型のCPUと思ってok
RISC:
命令語が少ないので、CPU内部の命令語解析処理部分が小さい。←これが目的
命令語が少ないので、語長が揃いパイプライン化しやすい。
命令語が少ないので、同じ処理ならCISCよりメモリが必要。

最近のCISCは内部でRISC変換、RISCは命令数増やしまくってCISCみてーになってるし。
なんかおかしくね？ それとも理想的なCPUに近似してきてるって事？
その挙句100W駆動てバッカじゃねーの・・・

メモリ−レジスタ間の処理がロードとストアしかないだけで
A=B*C+Dとかが１命令でできるし

>>49
x86もWindowsも普及しすぎた為に互換性(以下略

パイプラインが深いと分岐予測ペナルティーによる喪失が大きいのは解るのですが、
スーパースカラーで並列に処理しようとしても、依存関係がある場合は、
他のパイプラインに振り分けて処理出来ないので同じに思えてしまいます。
依存関係の有る処理に対する二者の優劣はあるのですか？
あるとすればどのような事に起因するのですか？
そこが解らない。

依存関係のある命令では、スーパスケーラでもスーパパイプラインでも
結果が出るまで次の命令の実行に移れない点で同時実行はできません。
命令を入れ替え、パイプから出てくるのをまってから次の命令を投入する
形になり、その点では優劣はどっちもかわらないんじゃないかな。

スーパスケーラが、一サイクル中に同時実行できる演算数を増やす工夫に対し、
スーパパイプラインは一サイクルにかかる時間を短くする工夫※なので、ふつうは
両方をバランスよく同時に投入してCPUを作ります。Pentium4然り。

※ロジックのゲート速度は今やほとんど上げられないため、回路が複雑になると
その回路に入った信号が出てくるまでの時間は長くなります。つまり一サイクル
にかかるが長くなってしまうわけで、その逆数たるクロックは高くできません。

二進の足し算はご存知でしょうか。
二進は0か1しかありませんから、1+1の答えは0で、桁上がりが一つ発生します。

二桁の足し算の場合、一桁目の桁上がりを、二桁目に足します。
これは十進数の足し算でも同じですよね。
11+11の場合、最初に 1+1を計算して 一の位は 0、桁上がりは1。
次に 10+10に10を足して、ニの位は 1+1+1ですから 1、桁上がりは1
同様に、32bit分の計算を行う場合、下の桁から順番に桁上がりを考えながら32回足していきます。

一つ分の桁と桁上がりの分を足す回路を全加算器っていいますが、この回路でかかる時間を
たとえば1秒としてみましょう。32bitの加算は下の桁の桁上がりが出てくるまで次の桁の計算に
入れませんから、全加算器を32回繰り返すのと同じ時間がかかり、32秒かかります。

スーパスケーラは、この加算回路をたとえば二つもっているものです。
同時に別の足し算を二つこなせますから、32秒の実行時間中に二つの演算が行えます。
倍の処理性能ですね。

一方、スーパパイプラインは、たとえば1bit全加算器一つ一つを1ステージにしちゃいます。
32個のレジスタを用意しておいて、1bit計算したら1bitずつストアしていきます。
一回の計算に32回1bitの全加算器をまわします。でも、1ステージは 1bitの全加算器を一回
しか通しませんから、なんと1秒で処理が可能になり、先ほどと比べて32倍も早く次のステップ
に進めます！

でも、32回繰り返すので一つの足し算にかかる時間は結局32秒かかり最初と
変わりません。ただ、1ステージ終ったら、下の桁では別の計算をさせることが可能ですね。
結果として、なんと！32秒で32個の足し算が可能になります！（最初に31秒の空白時間があります）

なんかすごそうですけど、カッコの中身もすごく気になりますね（笑
つまり、そーゆーことなんです。

>>53
お答えいただきありがとうごさいました。
という事は、アス論系がペン�C系に比べて、分岐の多い処理に強いというのは、
ペン�Cよりスーパースケラー方向である事とは直接関係はないとの理解で良いのでしょうか？
別の言い方をすると、ペン�Cのパイプが深い事自体が原因ではなくて、
パイプ深い割にはクロックを稼げていない事で、分岐の多い処理
で不利に なっているとの理解で良いすか？

>>54を読んで
>>55の疑問も解けました。
丁寧な説明本当にありがとうございました。m(__)m
クロック速さをパイプの段数で割って考えないと、依存関係の有る処理の速さは見えて来ない
と言う事ですね。

x68なら語れるんだが、よくワカンネ

おい、CRISPはどこに消えたんだ?

ほらよっと　がんばって勉強してね〜

広島市立大学 アーキテクチャ　お勧め
http://www.arch.ce.hiroshima-cu.ac.jp/~kitamura/public/architecture_2003.htm

東大 コンピュータハードウェア　資料だけだとわかりにくい
http://www.mtl.t.u-tokyo.ac.jp/~sakai/hard/

京大 コンピュータアーキテクチャ　細か過ぎ
http://www.lab3.kuis.kyoto-u.ac.jp/members/tomita/lecture/lecture.html


東工大 計算機システム講義・演習　ハードウェアの設計の話が中心
http://matsu-www.is.titech.ac.jp/~naoya/ta/compsys2003/


英語のは有名大学のをふたつ

Stanford Computer Architecture & Organization
http://www.stanford.edu/class/ee282/handouts.html

MIT Computer System Architecture
http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-823Computer-System-ArchitectureSpring2002/LectureNotes/index.htm

パイプラインの各段の処理時間が等しい時、

処理時間 = ( パイプライン段数 + 命令数 - 1 ) × 1段の処理時間

となることが知られています。

一般にPentium 4はAthlonやPentium 3系よりもクロック当りの性能が低い事が知られていますが、
これはハイパーパイプライン(余りに長いためIntelがつけた名前)という仕組みだけでなく、
Pentium 4のコア構造、半導体テクノロジー等、様々な要因が密接に関係しています。

俺自身かなり技術論は好きなんだが、このスレが盛り上がらないのは
技術について語り会うってよりもネットちょっと調べれば分かる程度の
内容を、独り言のように連続投稿する人がいるので
それでひいちゃう人が多いんじゃないかとｵﾓﾀ。

Itanium2スレとかIntel次世代はちゃんとコミュニケーション(煽り合いも含めて)
があるからそれなりに技術論が盛り上がってるし。

まずはCPUというか半導体の仕組み自体をおさらいしておきましょう。
CPUは2進数で計算をするという事は良く知られていますが、
これは実際には電気回路によって構成された論理回路によって実現されています。
そして論理回路は、さらに次の原始的な仕組みに分解する事ができます。

ソース<->ゲート<->ドレイン

この時、ゲートは通電可能か通電不可能を変更する事ができるシリコンです。
ゲートが通電可能な場合、ソースに電力を与えるとドレインからも電力を取れます。
ゲートが通電不可能な場合、ソースに電力を与えてもドレインからは電力が取れません。

この単純な仕組みによってCPUは構成されています。

>>62
OK。じゃあ連続投稿止めるからネタ提供してくれよ

>>63
いい加減な事書くな
トランジスタの基礎をもう一回勉強してこい

>>65
確かに、FETの説明で「電力を取れます」は無いよなw

俺もこのスレタイみた時は、いいスレできたじゃんとか思っだけど
正直スレの内容読んだらなんか自閉症的な連続投稿ばかりで
書き込む気がしなくなったな。
Intel vs AMDスレみたいな過度の煽り合いは不毛だと思うが、
ある程度の煽り合いはスレの肥やしになるんだよな。
そういう意味で>>65みたいなレスは貴重。

>>1の方針自体は悪く無いスレだから方向転換しつつ巧く育てていきたいスレだとは思う。

漏れもここで一つネタ振っておこう。
x86CPUが内部RISC化してCISCの弱点を克服してきたって言われてる
訳だけど、プログラムレベルでレジスタがたった8本ってのは糞過ぎる。
レジスタリネーミングとかコンパイラの最適化で逃げているが
やっぱり元が糞なものはどうしょうもない。この点に関しては絶対に今時のRISCに勝てない。
煽り的反論大歓迎。

>>66
AMD64で解決しませんか？

>プログラムレベルでレジスタがたった8本ってのは糞過ぎる。

今時x86をアッセンブラで組むやつなんてほとんどいねえんだし
もしも本当に論理レジスタ本数で困ってるなら64bit拡張の際にたったの
16本程度の拡張で済ませる訳ねーだろｳﾞｫｹ!!
内部レジスタ使ってスケジューリングで誤魔化せば8本でもたいして困ってないんだよｳﾞｫｹ!!
それに拡張命令セットの方の方なら潤沢にレジスタあるだろｳﾞｫｹ!!

知ったかは氏ね!!

16個は多杉
使いきれない

そもそもトランジスタの説明で

電力を取れます

はねぇだろ。
バイポーラとかFET以前の問題。

つーかリア厨か？
電圧何Aとか
電流何Vとかいうような馬鹿？

>>66
x86のレジスタが少ないことを克服するのがPentium4(Willamette,Northwood)の
低レイテンシL1キャッシュ。「x86のL1なんてしょせんスピルがほとんど
でしょ」と割り切って、小容量(8KB)・低レイテンシ(2cyc)に振った。
IA-64のレジスタが2KB(8B*128本*2セット)であるのに比べて、その4倍でしかない。
これの効果は明らかで、Northwood(ベースのXeon)は明らかにRISCと互角。
(Itanium2スレのベンチマーク結果見てるよね)
要するに「高速にスピルできればレジスタなんて少なくてもOK」ということ。

せっかくのこの特長を、L1キャッシュ容量を16KBに増やしてレイテンシ4cycと
増やしてしまったPrescottがクソなのはこの板の常識。

正直8本とか言って有り余ってる。

PICとかAVRで完全アセンブラで組むと2本（つーかALUが足し算できる最低本数）
あれば事足りる。
アセンブラで組むとしてもレジスタを考慮したくない。

>>68
同意。

そもそもx86アーキテクチャなんて終わってるんだから、
今更レジスタ増やしたりされてもかえって迷惑。
これからはJavaや.net frameworkどんどん使って、
早く新しいアーキテクチャに移行しないと、業界が滅びる。

漏れ>>33 = >>53-54 なんだけど、>>1 や>>11-22とは別なんでよろしく^^;

>>66のネタは http://pc4.2ch.net/test/read.cgi/jisaku/1081898975/
の>860あたりで既出なんだけど、まぁ25年も前の腐れたアーキテクチャを
後生大事につかってる漏れらが悪いんだわさ。嫌ならとっととItaniumに
逝けってことﾃﾞｽﾖ。

それ以前にSparcだってAlphaだってMipsだってあったわけだし。
AMDならAm29kだ。肉まんﾏﾝｾｰ

未だにコンパイラは386でも動作するコードしか吐けないわけだ・・・通常は。
MMX・CMOV・SSE・SSE2、それぞれジワジワと効いてくる命令だけに、なーんも使ってくれんのはキツイ。

そこで出てきたのが、CLIを環境に合わせて最適にJITコンパイルする、と。
ｘ86 → 最適なx86に再コンパイルしてくれるのが一番良いんだが・・・無理な話か。

>>75
いや、だからこその.net frameworkとLongHornなんじゃないか？

>>７５
通常じゃない場合は拡張命令を自動生成使用してくれるの？

前処理で、人間が手動で拡張命令が実行できる形にしないと
いけないイメージがあったんだけど、コンパイラが拡張命令が
使用できる形に無理やりデータの順番とかいい感じの塊だとか
に直してくれたりする？

趣味だとその辺りの資料が殆どなくて、人間が手動で前処理する場合の
解説は、日本語のネット上だと午後とかまるもが解説してた程度なんで資
料キボンヌ。

もっともっと煽りЩ(ﾟДﾟШ)ｶﾑｫｰﾝと言うことで煽り返したいところだが
俺の知識レベルでは正直苦しい。。。。
もちっと必死にググってネタ仕入れて煽り返してやるからな覚悟してよろ藻前ら

>>69
>16個は多杉使いきれないぞw　お前プログラム組んだことないだろ(ﾌﾟ

くらい言ってくれたらなお嬉しいw

>>74
いいぞ、そのイキだ。
それとお前はもっと言葉遣いに気を使え。
とにかくデス、マス調の丁寧言葉はヤメとけ。
レス読んでるやつを挑発して馬鹿にするくらいの書き方をしろ。

やーいばか

>>77
GCCにCMOV使用の最適化オプション有り。
VC7でfloatをSSE系で演算する最適化が追加・・・ま、その程度。やる気ナシ。

>>69
おまえさん（人間）がasmでカリカリ書くのなんか想定しとらん。
コンパイラの最適化自由度の為にレジスタ本数は重要。

>>80
つーかSSEはAthlon系で遅いんでイラネ。

>>80
ああ、やっぱその程度か・・

素人考えにも難しそうだからなぁ。

>>78
え〜、だって淫厨vs明日厨の>873あたりで煽ったら、ついてきてくんなかったじゃん。
漏れ様寂しさのあまり枕をｳｨｽﾊﾟｰ夜用に変えたんだぞ。

>>83
>ｳｨｽﾊﾟｰ夜用
お前、ｶﾜｲｲ香具師だな。

ところで、ゲーム系はさておき浮動小数点演算ってそんなに使いまつか？
今まで組んできたプログラムでは、一度も使った事が無い・・・

ごめん。誤：今まで組んできた　正：最近組んだ

>>84
多いか少ないかは案件によるんじゃねーの？
使うべきところで使うようにしてるとしか言い様がねぇ…

>>84
ｹｺﾝするかい？ﾔｻｼｸしてね（藁

ゲーム用なんてそれこそ固定小数点演算でいいじゃんよ。
とかいうとなんか一部の、自称異様に目がいい香具師等から非難GoGoなんだけどさ。

最近はテーブル参照するより複雑な浮動小数点計算さしてｷｬｽﾄしたほうが速いなんて
ｱﾌｫな事が平気でおきうるから、そゆときにはいいんじゃね？

前略)おまいら、Pentium-Mの凄さをもっと実感するべきだと思います(以下略

やっぱり究極的には、>>71が示すように、L1キャッシュのレイテンシをレジスタ並にして、
mem-memで直接演算する（レジスタ無し）アーキテクチャとかあったら楽チンそうだなー

>>77
MSコンパイラは知らんが...
intelコンパイラは自動ベクトル化でSSE使ってくれる。
実行時環境に合わせて動作変更するコードも自動的にやってくれるから便利〜。

>>89
実効アドレッシング・モードをハードウェアレベルで実装するってことか？
CISCのRISC化の流れと逆行してて正直メリットがあんまりワカラン。
命令サイズも無駄に大きくなりそうだし。
それこそ素直にレジスタ増やした方がいいんちゃうか？

過去との互換性を捨てて新しい命令セットアーキテクチャを作るなら、レジスタは
少ないよりは多い方がいい。しかし、128本×２組あるItaniumの性能がx86よりすごく
高いか，というと大したことない。Itanium2スレでは、『確かにItanium2は高性能だが
わざわざアーキテクチャを変更してまで移行する程の差はない』というのが主な
意見だった。

>89
すでにクロック向上の足かせになってたりしてな

>>94
Northwood→PrescottでCMOSテクノロジの進歩以上にクロックを向上させる必要は
あったのか、Intelを小一時間．．．
無理してクロックを引き上げるのはかえって性能を落とすのは当然で、
IBMはPOWER4→POWER5でクロックを同じにして、マイクロアーキテクチャの
改善だけで性能を上げている。
"クロック周波数マーケッティング"に毒されていません？

>>95
そいつはわかりきっているが、いざやると全く売れなくなるから。
クロック周波数だけで性能を予測する素人厨がユーザーの過半数
である限りクロック至上主義マーケティングはゆずれまい。

『レジスタがもっと必要か』に関するAMDの資料があった。

これ↓の10ページ。
http://www.hotchips.org/archive/hc14/hc14pres_pdf/26_x86-64_ISA_HC_v7.pdf
アプリ毎に、それの何%の関数がレジスタがいくつあればいいか出てる。
例えば、スプレッドシートだと75%の関数はレジスタは7個以下でOK、20%が8〜15個、
4%が16〜32個、33個以上レジスタが必要な関数は1%、とか出てる。
全体だと、7個あればどのアプリでも60%はカバー、15個なら一部のアプリを除き
90%以上で、「レジスタは16個」というAMD64(このプレゼンではまだx86-64って
言ってる)の設計理由になってる。
本当は実行回数の重み付けをすべきだと思うけど。(１回しか実行されない関数なら
どうでもいいし、100万回実行される関数なら１個でもがんばって対応した方がいい)

14ページには、SPECint2000でどうなったか、が出ている。
　　�@平均命令長　3.4→3.8に増えた。 　　REX prefix分が増えた。
　　�A実行命令数　10%削減。 　　レジスタが増えた効果でロード・ストアが減った。
　　�Bロード数　26%削減、ストア数　36%削減。　　すごい減ってる。
これはAMD64のコードとは言っても計算は32bitでやっていると思うので、
レジスタ拡張の効果がでているのだと思う。

AMD64/EM64T(←両方書かないとアム厨って言われちゃう)は「メモリが4GB以上無いと
意味がない」と思ってたけど、レジスタ拡張は意外と性能に効くかもしれない。
AMD64/EM64Tをサポートしたアプリが出てくるのが楽しみだな。

上で１個は紹介したけど、ここ↓にあるAMD３部作とItanium2の発表は詳しいのでお勧め。
http://www.hotchips.org/archive/archive_hc14_toc.html

>>96
今度Intelがモデルナンバーの大キャンペーンをやるから
マイクロアーキテクチャの進歩の方向性は正常化する？

（ ´,_ゝ｀）

>>91
レジスタ構成・本数に縛られるより、メモリアドレッシングのみに縛られるアーキテクチャの方が、
何かと都合がいいんじゃないかと思ったんだよね。

ビジネス・サーバ・ゲーム他、大半のソフトウェアがC++もしくはC#・Javaで書かれ肥大化しており、
移植性・保守性を求めて抽象化させられている現状・・・ （バイナリすらバイトコード ＝ 抽象化）
Itaniumの128*2・64bitなんていつ窮屈になるかわからんし、いずれまた現状のCPUみたいに、
論理レジスタ構成を内部で独自の物理レジスタ構成に変換するハメに・・・

それだったらいっその事、メモリ同士の四則論理演算だけを表向き定義して、
CPU内部で自由にゴチャゴチャやってもらえりゃ良いんでないの？と。
キャッシュ容量その他ダウンサイズして携帯CPU・・・は無謀かｗ Itaniumじゃそうはいかんだろうしなぁ

「分岐命令を如何に使わずロジックを実装するか」という問題を少しでも軽くする為にも・・・
（関数の強引なinline化、ifの置換をソース・コンパイラ双方が積極的に行っていく必要がある）

ねえ、例えばパイプラインの段数だけ仮想CPU作って、
個々のスレッドを処理するってのはどうだろうか。
そうすれば、依存関係はなくなるし、
レジスタなんかを仮想CPU分用意すれば・・・

>>102
もしかしてCPU内部命令レベルでも
命令語レベルと同じ本数だけしかレジスタが無いと思ってるとか？

第一依存関係はパイプラインよりもむしろスーパースカラーの方の問題だろ。

>>103
違う違う。

現状、x86系プロセッサのパイプライン・スーパスカラは、
分岐処理等によってパイプラインハザードが起こるでしょ？
でも、パイプライン上の全ステップで、常に異なるスレッドを処理すれば、
つまりパイプラインで連続して実行する処理を常に異なるスレッドからフェッチすれば、
ハザードはほとんど発生しない、のではないかと考えた。

で、さらにそれを実現する為に、同時実行可能なスレッド数(=パイプライン段数)
分のレジスタを用意して、各スレッドの扱うレジスタをマップしてやれば、
メモリのロード・ストアや、タスクの切り替えオーバーヘッドも
節約できるのではないか・・・と思ったんだが。

つまり、レジスタ数=従来のレジスタ数×パイプライン段数、ね。

スレッドの並列性が上がっても単一スレッドのIPCは下がる一方

>>104
それはHTTを拡張したような話をしてるのか
マルチコアの話をしてるのか、投機スレッドの話をしてるのか
それとも全然違う話をしてるのかいまいちよく分からん。

>>104
パイプライン段数分くらいのMulti Threadingをやるというアイデアの問題点は以下。

(1) サーバ以外のクライアントPCやワークステーションでは、そんなにたくさんの
　　実行すべきスレッドが存在していない。絶対10個もないでしょう。
(2) レジスタを大量に持つのが大変。8本×20セットとして160本。
　　このくらいだと、面積も大きいし、クロック周波数のネックになり易い。
(3) 共用資源(キャッシュやTLB)の容量が不足する。

つまり、インプリメントするにはたくさんのトランジスタが必要な割りに
それを活かせるだけの仕事が無いので遊んでしまうので、非常にチップ面積の
無駄使いになるような気がする。

そもそも依存関係のないパイプラインってなんだよ
それはパイプラインにならんだろう
各ステージが依存関係があるからこそ細分化が可能なのに

皆レスthanx

>>107
HTTを拡張したような話です。

>>108
1&>>106. 仮想CPUの数を動的に変化させれば改善されません？
2. キャッシュを考えたら微々たるものでは？
3. キャッシュを減らしてしまえ！

>>109
？

つまりPentium 4のように分岐予想の為に豪華な資源を用意せず、
分岐自体を減らしてしまってはどうか？というアプローチだったり。

整数絶対値命令くらいいい加減に載せてくれ

>>110
取り敢えずシミュレーション結果出せ。
つぎに回路規模を見積もれ。

>>110
(1) 仮想CPUの数を減らしたら結局パイプラインが遊んでしまうのでアイデアの前提が成り立たない。
(2) レジスタは多ポート・高速である必要があり、読み書きポート数が少なく数サイクルかけて
　　アクセスして良いキャッシュとは世界が違う。
(3) 20個のスレッドを同時に動かせばいくら共通部があるといっても、1スレッド当たりの容量は
　　1/10くらいかな。1.6KBのキャッシュって意味ありますか？

やはりパイプラインを理解してないんだな
投機スレッドの話をしてるに過ぎない
ハイパーマルチスレッディングって感じだが

なんにせよ、ネタを振ってくれた>>102には感謝する。

>>102
ちなみにネットワークプロセッサで似たような奴ある。

>>108
1)10個くらいは普通に動くけどね。In-active ではあるかな。
2)現状のPenitum4でも128個、時期NetBurstだと256本位は普通に乗せるし、
UltraでないSparcでも160本もってました。
3)これを解決するのがNetBurst的アプローチなんですけどね。

で、無理にThread意識する以前にReOrderingってのがあってですね、HTTや
>>102のような発想をしないですむようにできる「はず」なんですよ。

しかし、想像を絶するほど深いPipeLineをつくっちゃったおかげで、局所的な
オプティマイズによる命令の入れ替えの限度を超えてしまい、パイプがスカスカ
になっちゃった。そのつじつまあわせたるHTTや投機スレッドなんぞに力入れる
くらいなら、もっと他に力入れる所は、ありますよね：）

RC5-72 の専用回路とSETI@homeの専用回路を付けて
あとは普通のPenで十分でないだろか。

つまりね、パイプラインに投入する各命令を、
異なるスレッドから順番に取り出すわけよ。
例えば、スレッド1の命令を1つ投入したら、
次にスレッド2の命令を1つ投入、次はスレッド3といった具合にね。
そして、最後までいったら始めのスレッドに戻る。
だから、有効スレッド数に応じて、擬似マルチタスク度も変化するわけ。

キャッシュは遅いとの指摘だが、
だからこそ、レジスタを増やして速度を上げるんじゃないか。

またこの構造のCPUでは、パイプラインが20段もあるCPUを想定していない。
そもそも、分岐予想やリオーダリングを無くして、
パイプライン段数を減らそうという考えなので、想定段数は多くても10数段。

そして、このアイディアの最大の特徴は、
OSが行っていたタスクの切り替えを少なくする事にある。
つまり、レジスタからキャッシュ・メモリへの待避が、
格段に少なくなる、とう点にある。

にしても、何もレジスタを各ステージ毎に持つ必要は無いと思うが。
従来通り内部レジスタ増やしてレジスタリネーミングでいった方が
リソースの効率高いんと違うか？

それとスレの盛り上がりのためにも引き続き頑張ってくれ>>102
あえて重箱の隅をつつくような反論しつつw応援してるぞ。

>>121
それは、インプリメント時の問題と考えますがどうでしょう？

PS.これからもスレを盛り上げるようがんがってゆきます

だからシミュレーションしてみろと…

最大何スレッド動かすと良いかなんて性能と回路規模のトレードオフなんだからさ。
使える半導体ルールにもよるんだよ。

>>123
流石にそこまで技術・時間ともにありません。
もし可能ならば、代わりにやってみてください。

>>120
誰が”そのスレッドが依存関係がない”と判断してｷｬｯｼｭにもってきてくれるのかね？
”ｷｬｯｼｭ内から”ならばBTBにﾃｰﾌﾞﾙ作るのは誰なんだ？

あと前提がおかしい

>分岐処理等によってパイプラインハザードが起こるでしょ？
>でも、パイプライン上の全ステップで、常に異なるスレッドを処理すれば、
>つまりパイプラインで連続して実行する処理を常に異なるスレッドからフェッチすれば、
>ハザードはほとんど発生しない、のではないかと考えた。

現状のHTTで2ｽﾚｯﾄﾞが動いている時
片一方のｽﾚｯﾄﾞでﾐｽﾋｯﾄが起これば全てのｽﾃｰｼﾞは廃棄される
どのｽﾃｰｼﾞがどのｽﾚｯﾄﾞかﾁｪｯｸする機構がないからだが
そんな機構を導入するより読み直したほうが速いからだ

もし10ｽﾃｰｼﾞあって10ｽﾚｯﾄﾞ動かしても同じこと
ﾐｽﾋｯﾄ以外の9ｽﾚｯﾄﾞは実行されることになるが
その後のｽﾚｯﾄﾞ=ﾐｽﾋｯﾄしたｽﾚｯﾄﾞはﾊｻﾞｰﾄﾞになる
9ｽﾃｰｼﾞ分しか有利にならない

現状のHTだってｷｬｯｼｭ内ﾐｽﾋｯﾄ程度のﾊｻﾞｰﾄﾞはたいしたことないんだよ
ﾒﾓﾘまで読みに逝かなきゃならんときが巨大なﾊｻﾞｰﾄﾞなんだ
9ｽﾃｰｼﾞ有利にするためにｽﾚｯﾄﾞが無依存であることをﾁｪｯｸする機構をいれるのか？
投機ｽﾚｯﾄﾞでいいんでないか？

スレッド数可変なら、OSからはどう見えるの、
固定スレッドじゃないと XP 様は対応できないような。

>>127
いやまぁOS,ｱﾌﾟﾘは作り直しでしょう
そこは目をつぶらないと・・・

OS・アプリにはあまり変更を加える必要はないと思う。
OSは次に実行すべきスレッドの一覧と、次にカーネルが呼ばれるタイミングをCPUに提供し、
CPUはそれに従って一定量の処理を行えばいいんだし。

それから、どのステージがどのスレッドであるかは、意識する必要すらない。
なぜならレジスタリネームのような機構を用いれば、
CPUからは1つの断続的なプログラムとして扱えるから。

つまり、OS側から見れば複数のスレッドを実行しているが、
CPU側から考えれば、単一のスレッドを処理しているのとなんら変わらない。

もし相互のスレッドに依存関係がある場合、
それは既存のプログラムと同じ依存関係を示すから、
単にハザード処理をするだけでよい。

しかもこのアーキテクチャのよい点は、各スレッドの動作が遅いという点、
スレッドの動作自体が遅い為に、L1キャッシュのレイテンシが解消される。
つまり、あるスレッドがメモリから値をロードしたとしても、
そのスレッドが次に処理されるのは、最大でパイプライン段数分だけ後になる為、
その間にキャッシュからデータを読み込める。

>OS・アプリにはあまり変更を加える必要はないと思う。
は誤植。たしかにOSのスレッド管理には変更を加える必要がある。

このアーキテクチャは>>38氏が書いているSPARCのそれみたいなもの。

>>131
同じつもりならHTも同じ。
違うつもりなら何が違うかまとめたほうがよい。

>>129
相当OSをいじらないと
>OSは次に実行すべきスレッドの一覧と、次にカーネルが呼ばれるタイミングをCPUに提供し、
>CPUはそれに従って一定量の処理を行えばいいんだし
はできないよ。ｽﾚｯﾄﾞ=.exeじゃない
またそのOS自体もそのCPUで動かすわけだし、たいへんだわ

またやはり>>108の問題点が解決されない
>>126に書いたようにHTの問題はｽﾃｰｼﾞ分のｸﾛｯｸが無駄になるﾊｻﾞｰﾄﾞではない
HTでもｲﾝｵｰﾀﾞｰでﾌｪｯﾁされるときはｷｬｯｼｭﾚｲﾃﾝｼは隠蔽される
問題なのはﾄﾚｰｽｷｬｯｼｭにすら分岐先がないときなんだよ
それを10仮想CPU分用意するのか？
ﾚｼﾞｽﾀの増量はﾃﾞｰﾀﾁｬｯｼｭに有効なだけだよ

もしﾄﾚｰｽｷｬｯｼｭにﾋｯﾄすれば
>そのスレッドが次に処理されるのは、最大でパイプライン段数分だけ後になる為、
>その間にキャッシュからデータを読み込める。
になるがﾄﾚｰｽｷｬｯｼｭになければ現状のﾈｯﾄﾊﾞｰｽﾄと変わらない
しかも分岐予測を減らすって？？
余計ﾊｻﾞｰﾄﾞが増えるよ

現状のHTの問題は単純なﾊﾟｲﾌﾟﾗｲﾝﾊｻﾞｰﾄﾞじゃない
そんなのAMDだって同じだよ
2ｽﾚｯﾄﾞ動作ですらｷｬｯｼｭや演算器の奪い合いで
綺麗にﾊﾟｲﾌﾟﾗｲﾝが流れないんだよ？

>>133
そもそも長いパイプラインは想定してないんだよ。
このアーキテクチャの目的は、現状の長いパイプラインを捨て、
膨大な資源を分岐予想に使うのを止め、
無駄なオーバーヘッドを極力少なくする事。
Athlon 64なんて4ステップもフェッチとデコードに費やしてるぞ。




だから、そもそもトレースキャッシュなんて必要ない。
キャッシュに無かったら主記憶から読み取れば良い。
その間に他の処理を出来るんだから。
もちろん、クロックを落として、そのかわりに
複雑な演算をすべて1クロックで完了するようにしる。

何度も書いてるが、このアーキテクチャではハザードを阻止しない。
ハザードの発生を容認し、発生しても空き時間を有効利用する。

パイプライン作らないとスループットが出ません。
簡単に言うといつもハザードが出ているパイプラインと同じ速度になります。

キャッシュミスしたときに他の処理をすると言いますが、他の処理はどこから
読めるのか考えてみた？

複雑な命令が1クロックで終わるようにするということは、すべての命令が一番
複雑な命令の速度にあうまで待ちが入ると言う意味です。その待ちは回路設計の
余裕にはなりますが、別のスレッドへの割り当ても出来ません。

ハザードが発生した飽き時間を使うということはハザードの阻止をしているんだよ。
ハザード無視と言うのはR3000みたいなものを言う。

>>134
10といったから10ｽﾃｰｼﾞとして書いてるんだが？

ﾄﾚｰｽｷｬｯｼｭがいらない？
つまりﾃﾞｰﾀとｺｰﾄﾞを区別なくｷｬｯｼｭするってことね
いずれにしろｷｬｯｼｭ格納時に10ｽﾚｯﾄﾞなら10個の領域にわけなければならない
共有できないからな
共有してるとﾊｻﾞｰﾄﾞのたびにｷｬｯｼｭﾁｪｯｸが必要になる
それならやはり膨大なｷｬｯｼｭが必要
10CPU分のﾈ

基本的にはﾒﾓﾘから直に読まない
ｷｬｯｼｭになければ、ﾒﾓﾘ>ｷｬｯｼｭ転送してからｷｬｯｼｭを読む
そうでなければﾚｲﾃﾝｼがでかいからな
またﾒﾓﾘ>ｷｬｯｼｭ間も別ｱﾄﾞﾚｽから読み込むか
ﾒﾓﾘ上ですでに依存関係のないようかつ連続読み込みできる配置になってなければならない
10ｽﾚｯﾄﾞ周期に配置させるわけだ
そうしなければｷｬｯｼｭへの転送するたびに莫大なﾚｲﾃﾝｼが発生する
CPU内のｵｰﾊﾞｰﾍｯﾄﾞなんかより
CPU<>ﾒﾓﾘ間のｵｰﾊﾞｰﾍｯﾄﾞを選択するってことか？
ﾌﾟﾛｸﾞﾗﾑ組むのもたいへんだが、ﾒﾓﾘｺﾝﾄﾛｰﾗも相当賢くないといけない
1ｽﾚｯﾄﾞ毎ﾗﾝﾀﾞﾑｱｸｾｽし続ける気か？

ﾊﾟｲﾌﾟﾗｲﾝを短くして5ｽﾃｰｼﾞとしよう
1ｽﾚｯﾄﾞがﾐｽﾋｯﾄする
1ｽﾚｯﾄﾞ分のｷｬｯｼｭがﾘｽﾄｱされる
残り4ｽﾚｯﾄﾞは1ｽﾚｯﾄﾞ分処理があがる
そのかわりﾐｽﾋｯﾄした1ｽﾚｯﾄﾞは莫大なﾊｻﾞｰﾄﾞが発生する
無論ｷｬｯｼｭが5倍あればﾊｻﾞｰﾄﾞはたいしたことない
でもｷｬｯｼｭが5倍って・・・・

あぁわかった
486DXをｵﾝﾀﾞｲ10ﾏﾙﾁｺｱにしろってことか？

>>136
Trace CacheはただのI-Cacheでは無いよ。
だからTrace Cache無し=Unified Cacheではない。

>>138
それはわかるが、おまいさんのｼｽﾃﾑでは
ﾃﾞｰﾀｷｬｯｼｭもｺｰﾄﾞｷｬｯｼｭもわけないんでしょ？
というかわけたらえらいことになるが

要は
ﾚｼﾞｽﾀでｷｬｯｼｭのかわりを務められるのはﾃﾞｰﾀｷｬｯｼｭだ
といっているのよ
ｺｰﾄﾞ用のｷｬｯｼｭはどうするのかって訊いてる
ｷｬｯｼｭを増やさない、というなら10もの仮想CPU分のｺｰﾄﾞを
頻繁にﾒﾓﾘ＞ｷｬｯｼｭしなければならない以上
ﾚｲﾃﾝｼが増大する
しかも依存関係皆無ならﾌﾟﾛｸﾞﾗﾑがそれ用か
ﾒﾓﾘｺﾝﾄﾛｰﾗが相当ｸﾚﾊﾞｰじゃなきゃ
ｲﾝｵｰﾀﾞｰでｷｬｯｼｭできない
それはどうするの？ってこと

>>139
138は102ではない。102のアーキはキャッシュは別けても問題ないと思うがよく
わからん。

102は>>131と言ったり>>134と言ったりわけわからん。
HTは性能が実際に出ているわけだけど、性能のでないのを作ってどうするんだ？

汎用性を減らして回路規模を小さくしつつ性能出すと言う考えなら、ターゲット
アプリをはっきりさせないと話にならないよ。

>>141
ごめんごめん
IDよく見てなかったわ
まぁ102がHTT拡張と定義してるんでﾄﾚｰｽｷｬｯｼｭにこだわったんだけどね
ﾃﾞｰﾀとｺｰﾄﾞを分けてなおかつ10CPU分というのはすごいことになるような気がするんだが
あくまでも汎用性を目指したHTTの拡張ってことなら、ね
汎用性を減らそうとは思ってないんでは？

とりあえず>>136は頭に血が上りすぎて、I-Cacheが一枚岩と勘違い:-)
ふつ〜はBlock(Page)サイズごとに独立したコードを収められる。

>>143
いや現状でどうこうということではなくて
10ｽﾃｰｼﾞが依存関係なしということは
ｲﾝｵｰﾀﾞｰで処理するには厳密に10ｽﾃｰｼﾞ毎
ｷｬｯｼｭ内にｽﾄｱされるか、10個に分割するしかないんじゃない？
ｷｬｯｼｭに対するﾚｲﾃﾝｼが毎ｸﾛｯｸ起きるでしょ
ところがﾐｽﾋｯﾄしたときでも他ｽﾚｯﾄﾞが止まらないってことは
10分割しかない
ところがｷｬｯｼｭの全量を現状から増加させる必要はないっていうんで
逆にそれじゃﾒﾓﾘに対するﾚｲﾃﾝｼが増えるだけで
ﾒﾘｯﾄないんじゃない？って訊いてるんだが
あくまでも
>だから、そもそもトレースキャッシュなんて必要ない。
>キャッシュに無かったら主記憶から読み取れば良い。
に対する疑問なんだが

1)ステージ分のAddressGeneratorを内蔵して、1ClockごとにFetchパイプにつめる
2)デコーダ部分で10CPU分をエミュレート、コア部分は完全シーケンシャル動作に
　してトレースキャッシュ部分はリングバッファ的に回す。

3分で思いついた手は上の二つ。他にも手はありそうだね。

HTと何が違うのかと…

>>143
136みたいに熱い書き方してくれる人がいないと
以前のような過疎スレに戻ってしまうからな

一部の人が巧い具合にレスが付く書き方してくれてるので
なかなか良い具合にスレが進行してるなと思ってたりする

レスついてもなぁ、内容がなぁ。

>>102のアイデアを要約するとだね、個々のスレッドにとってはパイプの無いCPUを
構成すれば、ハザードなんて発生しえないしそのための分岐予測は不要だ、っていう
ことなんだよね。つまり>>137が正解に近い。 が、1GHzでまわせる10段パイプのCPU
でそれを行うと、一つのスレッドにとっては100MHzのCPUでしかない点を忘れてる。
そして、残念ながら性能は100MHzのCPUｘ10個分にはならない※。

で、>>108の一連の指摘はさ、そういうところを指摘したいんだろうとは思うけど、
つっこみどころが間違っててさぁ、反論できちゃうんだよね ^^;
物理的な数の限界は、数で解決されちゃうからね。レジスタの数でいえば、Prescott
なんか64ビットの汎用レジスタを256本もってますぜ？（半分死んでるけど）。

※以前の研究とか見ると、密結合のマルチプロセッサはバス競合などの理由から、
有効なCPU数は4つないし多くても8つくらいまで、といわれてきた（性能がサチる）けど、
400MHzのメモリバスをもった100MHzのCPUが10個だと、案外性能でたりするかもね(笑

知らない間に良スレに成長してるな。

>>148

たしかに、実行すべきスレッドが10かそれ以上あれば、
100MHzのCPUが10個という状況になるが、>>145氏のいわれた通り、
コア部分はシーケンシャルな動作になるので、
バス競合等の問題は起こりえないと考えます。

そして、実行すべきスレッドが10以下ならば、
順番に繰り返し実行されるので、200MHzのCPUが5個、
300MHzのCPUが3個、500MHzのCPUが1個、といった状況が考えられる。

つまるところ、今までに私が提示したアーキテクチャは、
OSの内部からスレッドの情報を取り込み、
異なる複数スレッド間では、処理依存度が極端に低い事を利用して
出来る限りパイプラインの各ステップで実行する処理に依存関係のない状態を作り出し、
さらにOSのタスク切り替えの一部分もCPU側でやってしまおう、
という考えの元に考えられた実行系サンプルです。

つまりはOSとCPUの密統合といえるかもしれません。

私はそんな知識も技術もありませんので、
多少理論が無茶苦茶な部分もあったりしますが、
その辺はフォローよろしくお願いしますぽ。

> そして、実行すべきスレッドが10以下ならば、
> 順番に繰り返し実行されるので、200MHzのCPUが5個、
> 300MHzのCPUが3個、500MHzのCPUが1個、といった状況が考えられる。

この状況を許す時点で、最初の前提が崩れるから、NG.
1GHz/10段のパイプに入ってから出るまで、次の命令を投入できないのが、
あなたのアイデアであり、投入しないからこそパイプの破綻が起こりえない。
暇なときは暇にしておかないと、元の木阿弥。

> つまりはOSとCPUの密統合といえるかもしれません。
OSはCPUにプログラムを投入するだけなんで、結合もなにもないです。
もっと正確にいうと、タスクやスレッドの切り替え毎に、各CPUの
プログラムカウンタ他、状態レジスタを設定しなおしてるだけ。
OS自身も、そこに含まれます。

あ、それからIDころころ変わって申し訳ないけど、
俺>>74=>>143=>>148=>>151なんでよろしく。

うう、>>145もな。

ここらでもう一度おさらいしてみよう。

「おしっこをして手をあらってでてくる」。
トイレが一室しかないと混雑時は長蛇の列ができます。

1.おしっこをする
2.手を洗う。

二段のパイプにすると、手を洗ってる間に別の人が用を足せるようになります。
トイレ一室で二人が気持ちよくなれて、効率が倍になります。

もうすこし深くしてみましょう。

1.ジッパーを下げる
2.ちんちんとりだす
3.放尿する
4.しずくを切ってちんちんしまう。
5.ジッパーをあげる
6.手を洗う
7.紙を使って手をふく

7ステージに分解すると、なんと 7人が同時に処理できます。
これがパイプラインです。

トイレの利用はおしっこだけではありません。
うんこもします。どういう手順でしょうか。

1.ジッパーを下げる
2.ズボンとパンツを下ろす
3.便器に座ってふんばる（出す）
4.汚れた尻を拭く
5.ズボンとパンツをあげる
6.ジッパーを上げる
7.手を洗う
8.紙を使って手を拭く

前半と後半は同じ処理ですが、途中がおしっことは別処理です。
ということは、小便器と大便器をわけると、途中は並列に処理ができそうです。

うんちとおしっこは処理時間が異なるので、手を洗ったりする所でどっちかが
待たされる事もありえますが、理想的には効率は倍になります。

これがスーパスケーラです。

うんこする時間と、ズボンとパンツを脱ぐ時間は同じでしょうか。
いいえ、うんこする時間のほうが圧倒的に長いです。

ということは、前の人がうんこしてる間パンツを下ろす人は尻をだしたまま
ぼ〜とまっていなくてはいけません。かかる時間を考慮してみましょう。
括弧内は、実際に処理に必要な時間です。

1.ジッパーを下げる(5秒)
2.ズボンとパンツを下ろす(20秒)
3.便器に座ってふんばる(60秒)
4.汚れた尻を拭く(30秒)
5.ズボンとパンツをあげる(20秒)
6.ジッパーを上げる(5秒)
7.手を洗う(60秒)
8.紙を使って手を拭く(30秒)

パイプラインは、一ステージ毎タイミングを合わせて処理をします。
一番時間がかかる処理は、例では60秒ですから、トイレにはいってから出てくる
まで60秒x8回、480秒の時間がかかります。

ちょっと発想を広げ、時間のかかる処理を分解してみましょう。

1.ジッパーを下げる(5秒)
2.ズボンとパンツを下ろす(20秒)
3.便器に座る(10秒)
4.一回目ふんばる(30秒)
5.二回目ふんばる(30秒)
6.汚れた尻を拭く(30秒)
7.ズボンとパンツをあげる(20秒)
8.ジッパーを上げる(5秒)
9.手に石鹸をつけて泡立てる(30秒)
10.泡を洗い流す(30秒)
11.紙を使って手を拭く(30秒)

ステージ数は増えてしまいましたが、1ステージにかかる時間は30秒と半分に
なりました。クロックでいうと倍のクロックに出来ることになります。

トータルでかかる時間はどうでしょう。30秒x11で 330秒ですね。
前より早く処理が完了しました。しかしクロックが倍になったけどトイレに
かかる時間は半分にはなりません。

これが、スーパパイプラインです。

あなたは今、これから迎えるであろう至福の時を迎える為にパンツをおろし、
あとは出すだけという所です。しかし！あろうことか神の声が轟きます。

「なにをしている、ここは女子便所だぞ」

条件判断ミスです。あなたの後ろには、つられて入って来てしまった数人の男性が、
ジッパーをさげズボンを降ろし、尻をだしたまま待っています。
しかし、ここで用を足すわけにいきません。あなたは数名の男性と共に廊下に
ほうりだされます。

あなたはもう一度、正しいトイレにいってジッパーを降ろす所から始めなくては
いけません。

一方女子トイレはというと、あなた達がほうりだされた事により三つの席が
空いてしまいました。ステージは規則正しく順番に進みますから、この席は
もう埋まりません。三つ分の埋まっていない席の為、女子トイレは利用される
ことなく無駄な時間が経過するでしょう。

その分、女子トイレの利用率は下がります。
これがハザードです。

トイレの危険はまだまだいっぱいあります。
トイレットペーパーが無くなったらどうでしょうか。尻を拭くことが出来ず、
それ以降のステージは凍結してしまいます。

手拭きのペーパータオルが無くなる危険もあるし、汲み取り式のトイレだと
肥溜めがいっぱいになってしまう事もあるでしょう。

その度にあなたは、本来やりたかった放尿を一時中断し、紙をとってきたり
汲み取ったりしないといけません。

本来は放尿や脱糞だけできればどんなに気持ちの良いことか。
そこで、トイレ掃除の人を雇って紙の補充をしてもらったり、汲み取り業者
を雇って定期的に組み上げてもらいます。お金がかかりますが知っちゃこっちゃ
ありません。それで本来の目的が気持ちよく遂行できるなら安いものです。

そう思うでしょう？

トイレが汚いとあまり気持ち言いものじゃありません。
知った人が前にすましてたら、そのトイレがきれいかどうか聞いてみるといい
ですね。でも、その人がトイレから出てくるまで聞けませんから、待ってる事に
なります。

折角11ステージにも増えて、同時に11人処理できるトイレも、入って来て
くれなければ利用率は下がります。

あなたと連れが二人います。
一人がトイレに行きました。あなたともう一人の連れは入りたいけど綺麗か
気になります。

この時、全体にあかる時間は

1.一人目の連れがトイレに入って出てくるまで 330秒。
2.トイレがきれいか確認してあなたが入って出てくるまで更に 330秒。
3.もう一人の連れは、あなたに続いて入れるので出てくるはあなたから30秒遅れ。

聞かずに入れば330+30+30で390秒で済む所が、トータルで690秒もかかって
しまいました。

これが依存関係です。

そこで、トイレがきれいか同か聞かなくてもいい人を先に通してみると
どうでしょう。どうせあなたは10ステージ分経過するまでトイレには
入れないんです。

丁度バスツアーの観光バスがサービスエリアに到着しました。あなたと、もう
一人の連れとの間に並んでます。おばはんは男トイレでも気にしません。

処理時間はどれだけでしょうか。

1.一人目の連れがトイレに入って出てくるまで 330秒。
2.トイレがきれいか確認してあなたが入って出てくるまで更に 330秒。
3.あなたの後ろに並んでしまったおばはんが10人。入りきるで300秒。
4.もう一人の連れはその30秒後にトイレに入れるので、入れるのは
あなたが入ってから330秒遅れ、さらに330秒の処理時間。

あなたのグループはトータル 990秒かかります。
おばはんは、あなたが入った後にしか入れませんから、330+30で360秒後に
トイレにはいって、全員がでてくるのは330秒後ですから、690秒後です。

先におばはんをいれてみたらどうなるでしょう？

1.一人目の連れがトイレに入って出てくるまで 330秒。
2.一人目が入って30秒後におばはんが入り始めて10人入るのに300秒。
3.トイレがきれいか確認してあなたが入って出てくるまで更に 330秒。
4.もう一人の連れは、あなたにつづいて入れるので出てくるのはあなたから30秒遅れ。

あなたのグループは、トータル690秒で済みます。
おばはんは30秒後にははいってますから、なんと360秒後には全員でてきています。

処理を入れ換えてあげると、トイレの利用率はあがり全体の処理時間が短縮
されることがあります。これがリオーダです。

大勢が素早く滞り無く気持ちよくなる工夫はいろいろあります。

トイレを二部屋用意するとか(Dualトイレ)、使用中のトイレに行列ができない
ように振り分けて上げるとか(Threadコントロール)、トイレに待合室とかつくっ
ておくと(Cache)、すれ違え無い程廊下が狭くてもまとめて入室させたり退室さ
せれば(WriteBack)混乱は減りますね。


とここまで書いておいて、トイレを流すのを忘れていたことに気がつきました。
くさいです。ちゃんと流しましょう。

ﾜﾛﾀ
他にまともなたとえはないのか・・・

しかもさらっと流し読みした感じ、言ってること正しいし・・・ｗ

スカラ

防御魔法のひとつ
仲間１人の守備力を５０％上げることができる
使用するとMP（マジックポイント）２ポイント消費される

俺もクチを突っ込もうとして、ざっと読んだ感じでは一箇所も破綻が無いのに感心した。

もう少し人に気軽に見せられる例えか、萌えられる例えだったら友人に見せたいくらいだw

>>150
それをえらい良い効率でやっているのがHTその他なんだな。
すでにアウトオブオーダ出来てるんで大した物量かけずにね。

固定でコンテキストを切り替えるのは前にも書いたけどネットワーク
プロセッサで使ってるのがある。スループット重視でレイテンシはあ
きらめるわけだな。

HT は入口は別々でも中では一つの便器しかない男女兼用トイレみたいなものか。

B6tZVOSSの偉業に拍手・・・ﾊﾟﾁ ﾊﾟﾁ ﾊﾟﾁ
こんなもの２ちゃんでしか読めない

　　　　彡ミミミヽ ﾉ彡ミミ)
　　　((彡ミミミミ))彡彡)))彡)
　　　彡彡ﾞﾞﾞﾞﾞ"ﾞﾞ""""""ヾ彡彡)
　　　ﾐ彡ﾞ　　　　　　　 　 ﾐﾐミ彡
　　((ミ彡 jニﾆｺ　iﾆニｺ. ,|ミミ))
　　ミ彡　 fｴ:ｴi　　 fｴｴ) .|ﾐミ彡
　　ミ彡|　　） ）　| |　｀（ （　|ﾐ彡
　 ((ﾐ彡| 　（ （　-し｀)　） ）|ﾐﾐミ　　　／￣￣￣￣￣￣￣￣￣￣￣
　　　 ゞ|　 ） ）　 ､,!　」（ (　|ソ　　　＜　B6tZVOSSよ 感動したぞ
　　　　　ヽ（ （￣￣￣' ) ）/　　　　 　＼＿＿＿＿＿＿＿＿＿＿
　　　　　,.|＼､)　 　　' ( ／|､　
　　￣￣| ｀＼.`──'´／ |￣￣｀
　　　　　 ＼　~＼,,／~　 /
　　　　　　　＼／▽＼／

>>169
ついでに紙は別々、といったところかｗ

米新興メーカー、稼働中に新命令を追加できるチップを開発
http://japan.cnet.com/news/ent/story/0,2000047623,20065688,00.htm
どうですか？

プレスコは３０人が１つのトイレに入れるっつーことだな。

>>174
という事は最初の一人が早速つまずくと、３０人目はそのうち
我慢できなくなってお漏らししてしまう罠（ｗ

ＣＰＵもあまり待たされた命令はスキップしてしまったらどうだ
ろうか。（ヲイヲイ）

P6 はオシリからうんこの頭が見えた人からトイレに入るように
改良した。これがアウトオブオーダだよ。

>>174
ﾌﾟﾚｽｺｯﾄ、というより、NetBurstの偉大な点は、排泄行為をまったく別のものに
置き換えた点にあります。

高性能な人工透析器を別途配することにより、腎臓->膀胱->放尿といった
古来よりつづく非効率的なプロセスを、連続的な透析により完全にカバーし
かつ（局所的な時間帯に限って言えば）滞る事無く処理が可能となります。

また、人工透析器に繋がっている間は新しく体内で尿毒素が発生しても
ちんちんをだしたりしまったりという放尿に伴う予備作業を行わずして
処理を繰り返すことも可能となり、ここでもさらに効率が上がります。

また人工透析器をより高性能なものに交換することや、人工透析器への接続
方法を改良することはまったく独立して行えますので、将来の改良も容易に
なるという利点も生みます。

通院し人工透析器に繋がるまでは若干の労力と時間を要しますが、それは些細な問題です。

NetBurstにおける目的はあくまで体内から尿毒素を排出することにあり、
効率的に排出できるのであれば、それは目的に対し完全な勝利だからです。

>>177

それでも昔ながらのやり方が好きな人の為に普通の便器も置いてあって
実はそっちの方が人気があるのは秘密だよ．

話の途中でスマンが、
アホな漏れにはSIMDとベクトルプロセッサの違いがわからん。
どちらも複数のデータを同時に処理するぐらいにしか書かれてない。
この二つの違いを教えて>エロイ人。

あとDSPとかゆう物について
漏れは今持ってるサターンについてるらしいことしか知らんが
決まった計算しかしない代わりに高速と聞いてる。
これは単にクロックが高いのか、それともSIMDみたく複数のデータを同時に処理できるからなのか
どっちなんだ。

ベクトルプロセッサはSIMDの特殊系っていうか一部。

行列計算にとにかく強烈に特化したもの。
もっと単純化すると、積和算を延々と行うだけになる
（減算、除算は加算、積算で代用できるから）。

DSPは、ある入力に対し一意に出力が決まるという条件で特化されたもの。
別にSIMDでなくてもいい。極端な話、メモリ素子で構成できる:-)

DSP=マイコンと考えて問題ない。少なくとも今は。
メーカーがそういう名前で読んでるから。別にPCのCPUと比べて速いわけ
ではない。

>180
>181
サンクス。
SIMDとベクトルプロセッサは元は同じなのね。
自動車に例えるなら普通車がスカラプロセッサ、
サーキットしか走らんF3000がSIMDで
F1マシンがベクトルプロセッサってとこか。

あとDSPの性能はCPUの16倍ってな話を見ただけなんで
それもCPUが25Mhzしか無い頃の話だしな
高速には出来るんだけど今でも必要十分で進歩してないってことか。

PCではRIVAなんかのの古いビデオチップやサウンドブラスターに乗ってる奴なんか
は固定の機能しかもっとらんからDSPに近いのかな。
(TNTクラスになると内部に積和算ユニットを備えているらしい。)



ま、こんな夜中にレスありがと！。

>>182
なんか違う。
SIMDの実装の一つがベクトルプロセッサ。
例えるならレースマシンがSIMDでF1マシンがベクトル。


DSPは名前の通りデジタル信号処理に特化したプロセッサ。
命令体系のほとんどがMMXみたいな専門命令なので
そういう処理をうまくやらせると同クロック・同規模のCPUよりは速くなる。
MMXみたいな専門命令とは要するに並列SIMDだったり積和演算が1命令だったりするってこと。
最近はCPUがそんな拡張命令を持ったり、CPUの演算速度がDSP並になったりして形無しぎみ。


ついでに外から見て固定の機能を持ってるかどうかと内部の実装はあまり関係ない。
たとえばキーボードはCPU（マイコン）入ってるけど固定の機能しかしないのと同じ。

クレイは別に SIMD とか意識して作ったわけではないので
分類方法としてあまりふさわしくないような。
SIMD っていう用語が人気なのは MMX命令のおかげ？

ベクトル長レジスタの中身で処理する要素数がかわるあたり
102さんの主張に近いような。

DSP は使える回路量が少ない頃に積和演算だけ豪華にしたというような。

P4 も得意なのはエンコード位じゃあ、DSP とかわらんような。

インテルが無理に詰めれば子供４人なら同時に便器に座れることを
発見して SSE 命令を作り、最近大人４人も座らせようとしてるが
これはさすがに評判がわるかったり、のような。

>>184
作った人の意識なんて関係ないけど。

DSPはディジタル信号処理を目的としている(た)けど、マイコンとそれほど違うわけじゃない。
メーカの商品に対する考え方の違いで、DSPとかマイコンとかに分類してるだけ。


あと、車にたとえるのはやめろ。

>>185
ここまできて例えをやめろはないだろうｗ

SIMDがトイレで、ベクトルが和式便器みたいなもんか。

>>186
dirty na tatoe ha YAMERO

実際にプログラム組むと普通のDSPの３倍ぐらいの命令ステップが必要なんだよな

何考えてSSEやMMXのアーキテクチャ決めてるんだか

>>186
SISD/SIMD/MIMDはFlynnによる分類で、ベクトルはSIMDになる。
この分類法が適切かどうかは別だが、この分類によればSIMD以外に成り得ない。

SIMDが便器で、ベクトルが和式便器と言うべきだろう。

>>188
汎用性

>>190
MPEGとか3D処理とかじゃないの？ MMXの頃はそんなことを言っていたような気がする。

>>188
3倍かかったプログラムってどんな処理？

Itanium2 1.5GHz → 64bit Windows Server2003
Opteron 248 → WindowsXP 64bit Edition
Athlon 64 FX-53 → WindowsXP 64bit Edition
Pentium4 HT Extreme Edition 3.4GHz → WindowsXP
Alpha21364 → Tru64 UNIX V5.1b
POWER4+ 1.9GHz → AIX 5L
SPARC64 V 1.3GHz → Solaris9 Operating Environment/SPARC

高パフォーマンスのCPUといえば
この辺が比較対象になるといえよう
あとのはちょっとアレ

PC向けCPUじゃなくてすまんが、EmotionEngineはVUに14個浮動少数点
演算器があるけどあの演算器全てに効率よく命令を送れるの？
VU同様Vliwアーキテクチャのia64でもコンパイラによる命令の並列化には
限度があるというし。

ここはハイレベルなインターネットですね。

>>193
送れるか？でなくて送れるようなアプリを多用するからそのようなアーキになる。
IA64の問題は、こちらの方がアプリの幅が広いと言う事だな。

>>191
１．ＭＭＸをＯＮにする。
２．ＭＭＸ命令を実行する。
３．ＭＭＸをＯＦＦにする。

実装当時は浮動小数レジスタと切り替えだったんで。まあ、命令数が3倍になるわけじゃないが
ロクでもないのは確か。 割り込み絡めばもうパフォーマンスの低下は必至なわけで。

MMXの最大の欠点は固定小数点で1.0を表現できないこと
SSE,SSE2,SSE3の最大の欠点はベクトル処理が加減算しかできないこと

>>197
＞ベクトル処理が加減算しかできないこと

mulps、divps・・・

>>197
おまい固定小数点知らないだろ。

ここは話が難しいねえ

SSEを誉めるヤツ＝＝アセンブラでSSEコードを書いたこと無いヤツ

>>201
コンパイラで性能がでれば良いのです。

…どういうふうに嫌なのか書いてくれないと話がつながらない。

そろそろあげとくか…。

>>197
｢積和算」ができなきゃ「ベクトル(行列）演算」にならんだろーが。
数学やりなおしてこいな ^^

>>196
いいんだよ、本来は2.のステップを延々と何千回も繰り返すんだから、
前後の手続きなんて小さい小さい。
DSP単体利用なら言うとおりだけど、CPU外部にベクトル演算器つけてた
時とくらべたら、ベクトルレジスタいじるステップが入るんだから
騒ぐほどのもんじゃないだろ。



それよりもだ、余計なレジスタ増えるわモードの保存もしなくちゃだわで、
例外処理発生時のペナルティが痛いﾝだＹＯ!

>>203
その積和の性能が低すぎるんだよSSEは
FPUの１．５倍くらいじゃバカ杉

>>196
ON（？）にする命令なんかねーぞｗ

ここ好きなんでAge

>>203
DX5.0以前ならMMXの使い道もいろいろあったけど、いまじゃな・・・。
サウンドとムービーエンコードくらいか？

>>205
あれ、そのままレジスタ叩いたら使えるんだっけか。FloatとMMXの切り替え命令が
あったと思ってたけど勘違いかな。

>>207
OFFにする時のみEMMS命令を実行だったかも。

拡張命令云々よりもCPU自体、コンピューターの中では
一個の演算ユニット何だから色々と騒いでもしょうがない。

それよりチップセット、マザーボード、OSの進歩の遅さの方が問題。
現状メモリ帯域6.4GBと言っても実帯域はその数分の一で
ｘ86CPUは一般OSじゃ４GBしかまともにメモリー扱えないし、
OSの方もXPじゃ、アプリ３GB制限あるので
自分的にはCPU性能よりそっちの方が気になる。

特に重い処理の大半が遅い大半がメモリー関係だと思うし、
FSBを現行４倍以上にし、メモリーも32GBぐらいにしないと
CPUは遊んでいる状態だと言ってみる。
・・・・ただし、それを上げる方がCPU性能上げるより遥かに面倒と言う罠

>>209
ちと、無い物ねだり杉

メモリの量は処理内容によって変わりすぎるからあれだけど、
バス幅はほんとにイタイよね。

リニアなメモリ空間マンセーになって久しいけど、そろそろ利用者側も
意識変える必要があるかも。

たとえばだけど、アドレスレジスタ毎に異なるメモリバスが存在していたら
どうだ？利用データによってメモリセットを選択できれば、今ほどのバス幅
は要求しなくても高速にデータアクセス可能にはなりそう。

>>211
実際動いてるバスは1本か2本になると思うのは気のせい？

>>211
メモリインタリーブ・・・

>>212
そこが味噌。

どうあがいてもメモリはCPUの速度においつけないから、メモリアクセスしにいったら
放置して別処理させるのよ。

大型機やHighEndなWSだと昔からやっている技術なんだけど、RDRAMでPCにようやく
導入か？っておもったら市場に受け入れられず消えたｗ

>>213
メモリアクセス待ちでバスを開放しないと、いくらインターリーブしてもダメ。
また、メモリデバイスが一つだと、バスを開放しても次のメモリリクエストだせないから
やっぱりダメ。


で、実はAm29000はインストラクションバスとデータバスを個別にもってて、
直線性のあるインストラクションバスはVRAMのシリアルポートにつないじゃえ
って発想なんだけど、ある意味、二つのアドレスレジスタに対し二つのバスを
用意した一例。

>>208
３DNow!の解説には無くても動くけど最初のMMX命令でEMMSと同様の処理が発生するから
FEMMSではさんだ方が速いと書いてあったな

CQから出てる中森章の「マイクロプロセッサ・アーキテクチャ入門」は
このスレ的に面白いと思うのでおすすめ

そういや本棚の奥にその手の解説書があったんだった。
いいことを思い出させてくれたよ、サンクス>>216

>>214
I/D分離するのはバーバードアーキテクチャと言ってそーとー昔からある。

＞最初のMMX命令でEMMSと同様の処理が発生するから

いい加減なこと書くなよ。

EMMS命令は8つあるFPUレジスタのタグワードをすべて有効にする(11)にする命令。
MMX命令によってレジスタに書き込まれると、タグワードは無効(00)になるんだよ。

>>218

そーなんだよなー。

で、I/D別にメモリバスを用意できないからってんでキャッシュだけ
分離して妥協したのが486/Pentinum。
キャッシュからの命令取り込みと実メモリとの並列動作を実現
(BSB/FSBの分離)したのがPentinumPro系バス。
で、メモリからキャッシュへの転送ってのはある程度まとめて
転送したほうが便利(メモリアクセスの局所性、キャッシュのラインフィル動作)。
そういう目的向けの機能が用意されたのがPB-SRAMであり、SD/DDR-DRAM。
FastPageなDRAMもそういう目的には便利に活用できる。

で、214が言う機能の壁はマルチタスク動作じゃないかな？

>>219
物理的なレジスタは別物だから切り替えにものすごく時間がかかるんだが
MMX>FPUは遅いけどFPU>MMXは速いのか
知らんかったよサンクス

>>219
君も間違っているし。
EMMS使うとタグは8つすべて「空」11になる。
EMMS以外のMMX命令を使うとタグはすべて「有効」00になる。
ちなみに無効は10。

あと、やろうと思えばEMMSを呼ばずにMMXとx87を混在させることができる。
遅いか速いかは分からないけど。

MPUの世界でハーバードアーキテクチャを歌ったのはMC68000あたりからなんだが、
残念ながらメモリデバイスに伸びるまずまで分離できてなかったんだよね。
けど、肉まんを例にだしたのはちょっと失敗だったかも。反省。

で、ノンリニアなメモリ空間の実装は以前からありはしたのだが、当時メモリは
高速かつ高価なデバイスでありCPUと同期動作が可能だったけど大量実装は出来なかった。
Z8000、MC68000あたりはインストラクションとデータ、スタックで明確に
アドレス空間を分離していた（68kにいたってはスーパバイザモードとユーザモード
も分けられた）けど、わざわざ分ける事はされなかった（した実装ってあるのかな？）

さて、211での問題点はなにかっていうと、各メモリバスにつながれたメモリデバイスに
相当の無駄がでるあたり。それと、PMMUの実装が面倒な点。そして、アプリケーションと
OSがメモリの実装状況によって最適化しないと効果が出ない点。
マルチタスク動作に支障はでないよ ^^

今やるとすると、、
・CPU内部
　CPUコア各部に独立したAGを搭載し、各Function毎にデータキャッシュへ
　同時アクセスさせる。排他アクセスにしないとイタイけどそれはブロック単位で制御

・外部バス
　データキャッシュをブロック単位で複数に分割し、個別にバスコントロール。
　もしくはRDRAMのようにメモリリクエストとデータをパケットにまとめてやり取り
　するようにし、リクエスト出したら一旦開放するとか。

かなぁ。

いまのメモリ帯域の狭さは、メモリバスがその名の通り「バス」動作している点にあって、
クロック倍にしても倍にしか速くならないのがイタイ。
どうせ外部記憶装置並みに遅いデバイスなら、外部記憶装置としてつかう事考えてもいいかもね。

あ、それと、
・シーケンシャルにしか動作できない
・片方向でしかデータをながせない
のもイタイ点。

>>223
>マルチタスク動作に支障はでないよ ^^

コンテキストスイッチ時のペナルティが大きくならねぇか？って話。

CPU性能＝命令セット×マイクロアーキテクチャ×製造技術
結局のところ設計や工場に投資できる金のあるところが勝つ。
金がある＝CPUが売れてる＝普及した古い命令セット＝汚い命令セット
かくしてAlphaやTRONのような美しい命令セットは滅び
x86やPowerPCのような汚い命令セットが世界を席巻する訳だ。

>>223
当時はパッケージング等の問題もあったと思われ。

ハーバードアーキテクチャが完璧かと言えばそうでは
ないよね…データテーブルとか面倒だし。

>>225
メモリ待ちになるのはどっちも同じ話だし、メモリリクエスト後待ち状態に
なったらその時点でもコンテキストの切り替えしてもいいから、むしろ
ペナルティは小さくならないか？

メモリ側は状態管理しないといけないからインテリジェンスになる必要はあるけど。

見落としてる点があったら指摘よろしく ^^

保守

なんとなくわかったような気もするが、かなり複雑な回路になりそうやな
そこまでやると、かえってレイテンシが増えてしまいそうな気もする
単純にL3キャッシュをアホみたいに積むほうが速くなりそうな

>>227
パッケージングの問題は過去のものでは無い気が。
ついでにCPUコア内部のバス引き廻しも爆発的に増えちゃって
クロック上げられなくならないかな。

ちょっと違うけど、漏れは10年位前に命令を分類して、種類毎に
別々のメモリバスにつながったメモリからプロセッサに供給する
っつーCPUの試作なんてのをやってたけど、やはりLSIデザインが
破綻しちゃった思い出が・・・

>>226
>かくしてAlphaやTRONのような美しい命令セットは滅び

TRONってTRONプロセッサってヤツ？

>>231
今時のは半分くらい電源用ピンのようなｗ

>226
美しい、汚いってのは?トーシロにもわかるように説明きぼん

無理（理解することが）？

>>226
キャッシュが内蔵する様になったからねぇ(´ー｀)y─┛~~

x86の有利な点を無理に言えと言われれば、レジスタが少ないので
コンテクストスイッチが少し速くなる可能性がある事かいな。

x86-64なんかでは、増えたレジスタをスイッチの度に全部待避する
んだろうか？

>>230
うん、メモリコントロール部分の回路もメモリ側も相当複雑になるだろうし、
コストも相当かかるようになっちゃうだろうね。実際 RDRAMって高くて市場に
受け入れられなかったわけだし。

>>231
やったんだｗ
内外のデータバスを双方向シリアルにして、外部数GHzでまわしたらどうなるかなぁ。

もうワイヤードロジックだのCRISPなどといった言葉は出てこないのね。
初期のCISC vs RISCで散々使われた言葉なんだけどさ。

>>237
今だったらそうするだろうねぇ。
しかし、高性能プロセッサ設計の仕事自体が漏れの周辺では殆ど
なくなっちゃったw

>>238
CISC RISC論争はもうほとんど意味無いと思う。強いて今からやるなら
これからは VLIW だよ派 vs スーパースカラまだ無敵だよ派
かな？

>>236
そりゃやらなきゃまずいでせう。
プロセス間でレジスタの中身を共有するなら、
その分はなにもしなくてもいいけど。

>>234
無理・・・じゃないかな。
アセンブラレベルを理解できれば、分かると思う。

そんな漏れはZ80→8086で泣きそうになった男・・・。

今どきのメモリは連続アクセスする分には充分速いから(プリフェッチとかできる)、
レジスタ退避みたいに連続したアクセスなら比較的性能を出し易いのでは。

>>239
IA-64も2006年のTukwilaで動的命令スケジューリングが入るらしい。
http://pc.watch.impress.co.jp/docs/2004/0305/kaigai070.htm
コンパイラの生成した順序とは違う順序で命令を実行できるCPUをVLIWって呼ぶの？

Any sufficiently advanced VLIW is indistinguishable from Superscalar.
(c) Arthur C. Clarke

http://pc5.2ch.net/test/read.cgi/jisaku/1083865295/542-549
でも書いたけど、Intelって

IA64コード -> μOps -> スーパースカラプロセッサ (out-of-order)

なんちゅうことをやろうとしてたみたいだからねぇ。
Tukwilaもバンドルあたり3つの命令を一度バラして、バンドルを超えて
out-of-order で発行するとかいう構造になるのかもね。

ついでにEfficeonは http://pcweb.mycom.co.jp/news/2003/10/16/19_10.jpg
見る限り、実行ユニットは in-orderだけど、CMSが命令スケジューリング
してるみたいだから

x86コード -> CMS (out-of-order発行) -> VLIWプロセッサ (in-order)

ですな。

これからは，スーパースカラプロセッサにしても，
VLIW プロセッサにしても，マルチスレッド化 (特にSMT) に向かうのでは？
などと最近勉強しはじめた新米の戯言をお許しください。
でもマルチスレッド VLIW って，初心者からみるとよさそうなんだけどなあ...。

>>223
68000はハーバードアーキじゃねー。

メモリスループットを増やしたかったら、インターリーブしたり、
リクエストをアウトスタンディングに発行できるようにする方が素直。
(互換性、汎用性、性能重視の場合)

>>243
VLIWはDelayed Branchやインターロック無し実行と同じように盲腸になった
ようだな。(性能を重視するプロセッサにおいては)

>>246

盲腸っつーか、当初からVLIWが抱えてる問題。
バイナリコンパチを捨てるなら簡単だが、
IA-64の場合はそこまでハイエンドにはなれないからね。

その点直接ネイティブを見せないEfficeonは上手くやった。

>>246
研究者方面での意見はしらんがMC68000はモトローラいわくハーバードアーキテクチャを
特徴の一つとしたMPU。内部バス構造がその所以。

インターリーブはバスを100%近く活用するための手段であって、100%をこえるための手段でもない。
パラレルにするかビット幅増やす方が素直。それができないからこその代替手段がインターリーブ。

アウトスタンディングにメモリリクエストを発行するってのが何を指してるかｺﾞﾒﾝ、わからん。
WriteBackなどの、コア側の要求に対し非同期にメモリ操作を行うものを指してるのなら、これも
100%近く活用するための工夫。

>>209が｢メモリおせぇ、FSB速くしろ（帯域増やせ）」と叫んでるから、その解決を考えてるんだよね。
現行のメモリ帯域を有効活用する手段の、さらに次。


うーん、期待してた突っ込みはそういう常識的な部分じゃなくて、、>>225的なのが欲しいなぁ^^
おそらくだけど、メモリ空間を細分化させた場合、その構造に特化されたデータ構造のプログラムは
劇的に速くなるけど、それから外れる場合はメモリマネージメントに恐ろしい手間がかかるはずなんだよね。

SunFireやSGI Originなんかは、システムとして非常に大きなメモリをもつことが可能なのだけど、
蓋を開けてみると実は2〜4CPUに通常の構造で共有されるメモリをのせたSMPシステムを一単位にして、
それを数十〜数百単位のせ、さらに相互にメモリ参照できるようにしてる。

ある程度以上は分散アーキテクチャにしちゃったほうがいいっていう割り切りなんだろうなぁ、って
僕は思ってみてるけど、どうだろう。

がーん。
間違えた〜。

VLIWが抱えてる問題じゃなくて「バイナリコンパチが抱えてる問題」だった…。

IA-64はバイナリコンパチのまま命令拡張が出来る改良型VLIWだから
動的スケジューリングを載せる必要性が出てくるのね…。

IA-64はVLIWとは言わず、EPICと言ってるな・・・。

Itanium→Itanium2で中身変わったけど、バイナリコンパチ。
ただし、どっちに最適化するかで、パフォーマンスは多少変わる。

>>248
内部バス分離でハーバードアーキかよ。マーケティング用語だな。

100%越えたら動かんだろ。チットは考えろ。

だいたいバスバス言っているけど、バスに拘ってる段階でダメなんだよ。
CPUにメモリコントローラ内蔵は安価で効果がありそうじゃないか。

Originは知らんがSunFireはSMP(厳密には違うだろう)で、分散アーキじゃねー。
どのCPUからも全メモリにアクセスできるだろうが。分散マシンとか言ったら
設計者泣くぞ。(多分パーティションは切れるだろうがそれは話が別)

うーん、煽りたいだけの半可通は放置したほうがいいのかな？

SunFireの場合SMP構造を持っているのはCPUモジュール単位で4CPUは一組になります。
これをクロスバスイッチ式のデータパスで相互に接続し、別モジュールに搭載された
メモリを直接操作できるようになっていますが、アクセス速度には相当のペナルティが
課せられます。

モジュールを一つのプロセッサとみなした場合、モジュール間は対称構造をもちますので、
その意味ではシンメトリックかもしれませんが、メモリを内包してるのでちょっとそれは
乱暴でしょう。

実際のプロセッサから見た場合、対称構造になるのは同一モジュール内に存在するプロセッサ
だけですから、別モジュールに存在するCPUはSMPとはいえません。

ソフトウェア的に見た場合にも、すべてのプロセッサをSMPとしてコントロールすると、
あるプロセッサがスレッドを実行しようとした場合、そのインストラクションおよび
データが自モジュール内に存在するとは限らず（むしろない場合のほうが多くなる）、
前述のメモリアクセスのペナルティが課せられることとなります。

残念ながら私もSunOSのソースを見たことはないんで、SunFireにおけるタスクスケジューラが
どのようになっているかはわかりませんので、ペナルティを甘んじて受けてるのか、素直に
スレッドを各モジュールごとにばら撒いてるかは想像の範囲を出ません。

そのクラスのマシンはNUMAでしょ。
Origin は cc-NUMA と明記してたと思うけど、SunFire はどうなんだろう。

>>252
SUNはSMPと言ってるがな。
Cacheを付けた段階で厳密な意味でのSMPなんて存在しないよ。
1つの保守単位となるボード上に複数のCPUを載せ、かつ複数ボードを搭載できる
製品をSMPと言っているのはたくさんある。もちろん厳密な意味ではSMPでは
ないが、それを気にしているのか？ キャッシュ無しバス結合マルチプロセッサ
以外はSMPになり得なくなる。

どこのメモリに載っているかより、どこのタグにヒットするかの方がレイテンシの
差が大きい場合もあると言っておこう。

あと、SunOSのソースを見なくても『Solaris Internal』に載っているかも知れん。
読んでみれ。

キャッシュがあってもSMPって普通は言うと思う。もし「キャッシュがあったらSMPではない」なんて言うのが
SMPの定義だったら「世の中にはSMPなんて存在しない」ということになってしまうからね。だから厳密な意味の
SMPの定義は「どのCPUから見てもどのメインメモリも等latency・等Bandwidthに見える」だと思う。
この条件に合うのは、いまだにシェアードバスにこだわっているIntelのXeon/Itanium2でシェアードバス結合が
使える4way以下のシステムとIBMのメインフレームだけでしょう。それ以外は全てccNUMAと言っても良いと思う。
(2coreのCPUを使った2wayのシステムも厳密な意味でSMPだけど)厳密なSMPを実現するには非常にコストがかかるので、
無理して厳密なSMPなんてやらないで、ある程度ccNUMA的なシステムを作って、あとはソフトウェアの使いこなしに任せる、
というのが現在の技術の流れだと思う。Linux kernelだって一生懸命NUMAサポートを入れているし。

255の主張ではSunFireはccNUMAになってしまいますが、そういう意味？
あと、SMPマシンにLatencyの違うDIMMを差すだけでSMPじゃなくなると言う
主張にも見えますが？
普通はそんな厳密な事は気にしていなくて、SunFireはSMPに分類するだろう。

ところでSunFireのボード内/ボード間Latency/バンド幅の差は公表されてる？

広義に言えばSunFireでもIBMのRegattaでもHPのSuperdomeでも大規模SMPはもうccNUMAと言えると思う。
たぶん、80年代だったらああいう構成ならccNUMAと呼んだと思う。(Opteronもそう)
ただ現実には昔のccNUMAと比べてローカルメモリとリモートメモリのアクセスタイムの差が大分小さいから、
あまり性能のことをうるさく言わなければ、普通のSMPとして使えるんだと思う。
だた、性能をうるさく言うとソフトウェアがローカルメモリとリモートメモリを意識した処理をする必要が
あって、今やLinux kernelだってそれを意識したCPU/メモリ割当てとかをやろうとしている。
Linuxがやろうとしている位だから、各ベンダーのUnix(Solaris/AIX/HP-UX)は既に絶対やっていると思う。

SunはSunFireをSMPとしか呼んでいないし、少なくともSolaris7はSMPにしか
対応していない。(『Solaris Internal』)

『Solaris Internal』では、システムインターコネクト(ボード間インター
コネクト)が均一なアクセスタイムを実現するために十分なバンド幅
があるものがSMPであるとしている。

だからSunFire/SolarisはSingle imangeでは性能が悪くて、パーティショニングして使うんだ。
Bandwidthが確保されていても、レイテンシの差は絶対あるんだから、それを意識した制御は
OS側でやるべきだと思うよ。

だいたいSunFire(SPARC)みたいな時代遅れの性能の悪いシステムの話がなんでされているんだろう。
元々SunFireもCrayが設計していたのをSunが買ったんだと思うから、Sunはもう何年も自分で
まともなハイエンドのハードウェアを開発していないんじゃないかな。
UltraSPARC�Wだって、結局UltraSPRAC�Vのデュアルコア版にすぎないし。

パーティション切らない時にローカルボードのメモリアクセスが遅くならない
ことを言わないとSMPで無い事を言えません。

> ところでSunFireのボード内/ボード間Latency/バンド幅の差は公表されてる？

257は知ってるのだろうが、知らなければSunはSMPだと言ってる以外何も言えません。
(というより何が言いたいのかさっぱり分からない)

パーティションを使わない場合、SunFireの構成ならローカルメモリとリモートメモリのレイテンシの差が
あるのはハードウェアの構成上明らか、という考察では不足？
Bandwidthはわからないけど、レイテンシは絶対違うでしょう。
でもSunのSMPの定義と私の"厳密な意味の"SMPの定義は違っていて、Sunの定義だとレイテンシが違っても
Bandwidthが違わなければSMPと言って良いから、SunのSMPの定義に従えばSunFireはSMPかもしれない。
でもどうせSunFireのBandwidthなんて激低だろうから、どうでもいいのでは。

あなたの定義だとSMPマザーボードにレイテンシの違うDIMMを差すとccNUMAに
なるんですね？

根拠もなくSunFireをccNUMAと主張するよりは現実的。
レイテンシは絶対違うという考察なんてどこにも出て来てない。まずSunFire
のキャッシュコヒーレンシプロトコルの説明から始めた方がいいですよ。

>>260
このスレは思い付きとか言い合って楽しんでる(?)んだから古くてもいいじゃん。
新しい方が良ければネタ振ってよ。

Efficeonマンセー

だんだんとスレが生きてきましたね。
一瞬削除願い出そうかと思ったが、出さなくてよかった。

またかなり話が難しくなってきました。
初心者を置いていかないように適度にトイレで例を示してください。お願いします

少なくとも性能対消費電力が重要視される分野ex)Embeddedなど)以外では、
Hardwareの仮想化ってのはここ数年来大分注目されてる分野だと思うけれど？

例えばIA64の性能向上がムーアの法則を上回るなんて言われてるのも、
それ遺体は眉唾だけど、IA32で同じ事を言うよりは信憑性があるように、
今後は最新プロセスと高度な論理設計技術を持ってるメーカーは
益々VLIW(CMS？)的なアプローチの方が有効になると思うんですがどうでしょう。

あ、>>267は>>247に対してス。

http://www.idg.co.jp/sw/back/series/200005_01_kernel.html
----
サン・マイクロシステムズが出荷しているマルチプロセッサ・システムは「SMP」と
呼ばれるアーキテクチャを実装している。これは、「Symmetric Multi Processor
（対称型マルチプロセッサ）」と「Shared Memory MultiProcessor（共有メモリ型
マルチプロセッサ）」という2つの用語の頭文字をとったものである。サンのシス
テムは、どちらの用語にも当てはまる設計がなされている。
----

もはや、SunFire15Kあたりは、前者の意味でSMPと言っているだけという気がする。
これなら、NUMAとSMPは直交する概念だ。

すまん、>269の補足。

リンク先を読めばわかるが、ここでいう「対称型」は、どのプロセッサも同じOSの
機能を処理できる構成を指していて、プロセッサからメモリが等距離とかいう
構成ではない。

しばらく見られんかった…age。

>>270
SunFireのSMPは、ある程度ハードウェア構造をさしてはいるけど、
どっちかっていうとSoftware(OS) Parspective な言い方だよね。
それで性能がでるかは別の話。

ただ、無駄にコストかけるよりは、こういう割り切りをある程度行って
アプリケーションチューニングするのが、今のトレンドなきがする。

スパコン方面のアーキテクチャは知らないのでごめん明るい人よろしく。

>>266
SMPやバス構造を便所で説明するのﾑｽﾞｶｼｲんだよな ^^;
考えてみるけどできなかったらｺﾞﾒﾝ

┌────┐　　　　　　　　┌────┐
│　 部屋 　│　　　　　　　　│　 部屋 　│　
│　 　 　　　│　　　　　　　　│　 　 　 　.│
└─┐┌─┘　　　　　　　　└─┐┌─┘　
　 　 ││　　　　　　　　　 　 　 　 ││
　 　 │└─────────-┘│
　 　 │┌─────────-┐│
　 　 ││　　　　　　　　　 　 　 　 ││
┌─┘└─┐　　　　　　　　┌─┘└─┐
│.　トイレ . │　　　　　　　　│.　トイレ　 .|
└────┘　　　　　　　　└────┘　

┌────┐　　　　　　　　┌────┐
│　 部屋 　│　　　　　　　　│　 部屋 　│　
│　 　 　　　│　　　　　　　　│　 　 　 　.│
└─┐┌─┘　　　　　　　　└─┐┌─┘　
　 　 ││　　　　　　　　　 　 　 　 ││
　 　 │└─────────-┘│
　 　 └─────┐┌───-─┘
　 　 　 　 　 　 　 　 ││
　 　 　 　 ┌───┘└───┐
　 　 　 　 │　　　　トイレ　　　　.│
　 　 　 　 └────────┘

>>272
上手い！

またトイレかよ！ｗ

これだとトイレがメモリで部屋がプロセッサになるのですか？

>274
266ですが、初心者にはこれが一番わかりやすいんですよ(･∀･)

>>275
排泄要求を出すのは部屋側だけど処理するのはトイレだし、
データ（人）の流れは部屋からトイレだから、プロセッサとメモリの関係と
ちょと反しちゃう希ガス…。

SunFireのメモリ管理について、ちょっと調べてました。
Sun Technical Bulletin 10/2002、「SunFire 3800-6800 動的再編成」、
Sun Technical Bulletin 7/2002、「SunFire V880サーバアーキテクチャ」他
テクニカルブリテンからの理解です。

少し古いんで、SunFireE25000などでは変更されてる可能性はあります。

まず、UltraSparcIII(IV)は、物理メモリのコントロールは8GB（16GB)まで
しか行えません。ここは大きなポイントで、これはシステム全体に存在する
32GB〜576GBという、大きなメモリ空間を透過的に扱うことができない事を
示します。

さて、この問題を解決するため、OSにおけるメモリ管理では、各CPUボード毎に
スワップを禁止した常駐エリア設け、ここに各CPU毎のリソースを動的に管理する、
OSの基礎部分を常駐させます。

それ以外の非常駐エリアはページ管理され、リソースの動的管理機構とvmのページング
機構により、必要に応じマップを行い、アプリケーション側に対し完全に隠蔽します。

こうして、アプリケーションから見た場合、SunFireのシステムはSMPシステムとされますが、
OSレベルではメモリ（以外にも、各リソース）配置を意識したものとなっています。

はしょった説明だけど、こんなとこで、どかな？
つっこみ訂正よろ。

＞リソースの動的管理機構とvmのページング機構により、必要に応じマップを行い、
ここ良く分らない
物理メモリが8/16GBしか扱えないんなら"必要に応じマップ"ってできるの？
テクニカルブリテンのURL貼って

>>279
一度に扱える物理アドレス空間が8/16GBってことちゃうの？これ。
何かにこんな仕組みがあった・・・。
あー名前が思い出せねえ・・・。

「マップを行う」っていうのはCPUが仮想記憶でVirtual→realの変換を行うことじゃないの？
そしてCPUの扱えるrealメモリの容量が8/16GBだとしたら、それ以上のメモリ空間をどうやって
マップするのかな？　と言う質問。

おそなりました。
TechnocalBulletinは紙媒体で保守会社（CTCとか）からもらってるので、
URLはｺﾞﾒﾝ。

かわりにこのあたり、かな？
http://jp.sun.com/products/wp/

アクセスできないはずのメモリにどうやってアクセスしてるのか、私もそれ
疑問です。

今WhitePaper読み漁り中ですが、SplitExpanderというのが各CPU/メモリボードと
バスの間に存在しており、ドメインの分離や合体をコントロールしてますので、
もしかするとここでバンク切り替え的に、同一ドメインに属したCPU/メモリボードの
メモリ空間を写してる、、のかなぁ？

…。
よく考えたらさぁ、核となるシステムプログラムが各CPU毎に独立して
存在してるなら、擬似SMPするのに別に他のCPUが占有するメモリにアクセス
しにいく必要、ないじゃん。

元々いまどきのvmは物理メモリなんてただの仮想空間のためのキャッシュに
過ぎないわけで、仮想メモリ空間のマップ情報だけ各CPUごとに共有していれば
いいわけ。

特にtextは thread 毎に各CPUに割り当てられた際に page-in すればいいわけで。

問題は data 領域なんだけど、これはキャッシュと一緒でコヒーレンシさえ
保っておけば、まったく同じコピーがあちこちに存在してても問題なく、実際
Sunのインターコネクトにはその機構が備わってる。

SunFireが実際そうかは、まだ理解できてないけど、vmの機構をうまく使って
隠しちゃえば、ユーザは簡単に騙せそう ;-)

遅くていいなら、Ethernet越しにだってできるよ。

遅かったらダメなんです。

http://www.diku.dk/undervisning/2004f/303/SunFireplane.pdf
"The Sun Fireplane System Interconnect"の6〜7ページを見る限り、
CPUからは全てのメモリ空間がアクセスできるようにみえる。

CPUが要求するアドレスをアドレスバスに出せば、Fireplane経由で
全部のCPU（メモリコントローラ）まで届いて、該当アドレスを持つ奴が
（それが自CPUのメモリコントローラか他CPUのメモリコントローラかに
かかわらず）データバスにデータを流してくれる。

小さいマシンの場合だとどうかと思ったが、UltraSPARC III Cu User's Manual
http://www.sun.com/processors/manuals/USIIIv2.pdf のpage2-14の2cpu
構成を見ると、あまり動きに違いはなさそう。アドレスバスにアドレスを流せば
データを持ってる奴がデータバスにデータを流すと。

>278
>まず、UltraSparcIII(IV)は、物理メモリのコントロールは8GB（16GB)まで
>しか行えません。ここは大きなポイントで、これはシステム全体に存在する
>32GB〜576GBという、大きなメモリ空間を透過的に扱うことができない事を
>示します。

メモリ空間を透過的に扱えないというのがわからないなぁ。アクセスを透過
的に扱う仕掛けはあるのだから（と俺は思ってる）、別の何かがあるのか？

>さて、この問題を解決するため、OSにおけるメモリ管理では、各CPUボード毎に
>スワップを禁止した常駐エリア設け、ここに各CPU毎のリソースを動的に管理する、
>OSの基礎部分を常駐させます。

常駐エリアを設けるのはCPU毎ではなくてCPUボード毎？CPUの制限を回避
するためならCPU毎に持ちそうなものだが。それとも、CPUボード＝1CPUの
モジュール？

では、そろそろ寝るわ。

UltraSPARC IIIはアドレスバスがあるのか？
初代UltraSPARCはUPAだったが。

http://jp.sun.com/products/wp/server/WP_V440.pdf
こいつなんかは、CPUとメモリが1:1で載って、JBusで合計4つが載るから、
CPU毎に常駐ｴﾘｱが存在するのだろうな。

一方で、
http://jp.sun.com/products/wp/UEarch/docs/UEARC03.html
は、メモリボードごとに複数のCPUが載り、一つのメモリモジュールを共有
するため、ここに限っては純SMP構造をとって、ボード毎に常駐ｴﾘｱを持つん
だろう。

で、各CPU/Memoryボードにはアドレスコントローラが載っているようだが、
こいつが搭載されたメモリの他FirePlaneを解したメモリリクエストを行っ
ているみたいで、UPA(たぶんFirePlaneも）に出力されるアドレスビット数が
42bit（＝4096GB)分ある。これはUltraSparcIII(IV）の33bit(34bit)を大きく上回る。

このアドレスコントローラが、いわゆるﾍﾟｰｼﾞﾏｯﾌﾟ方式のアドレス拡張機なんじゃ
ないかと思う。

>>285のいうメモリアクセスは、おそらくこの部分からのアクセスなんじゃ
ないかな。

>>288
UltraSPARCIIIはJBUSとか言ってるからもうUPAなんか使ってないんだ。

UltraSPARCIIIはわからんけど、IIIiはメモリコントローラ内蔵のようだから、
CPUあたりの「物理」メモリ容量が少なく決まっているんじゃないの？
CPUを沢山つないでしまえば、どのCPUからも全領域にアクセスできるんじゃない？

>>289
>CPUを沢山つないでしまえば、どのCPUからも全領域にアクセスできるんじゃない？

？？ どうやって？

UltraIIIiならOpteronのようにCPU直結でSMPができた気がする。
もっともCPU内部にはHyperTransportみたいなものやメモリコントローラは
入っているだろうから、表現にちょっと困るが。

ウソの記憶かもしれんので、まあ話半分で

CPU直結のSMPアーキテクチャって速度的にはデメリットはないの？
近例のOpteronだとHyperTransport使って他CPUに直結されたメモリにアクセスする際は、
大体4CPUで2ns、それ以上の構成だと最大で5nsのレイテンシがあるとか言ってたけれど。

それでもメモリコントローラ外付けの場合より速度的にメリットがあるのだろうか･･･？

>>292
自前のメモリーが(MC外付けより)速い

ttp://pc.watch.impress.co.jp/docs/2004/link/epfs.htm

反映されていないリンク分。
ttp://pc.watch.impress.co.jp/docs/2004/0528/epf05.htm


気になったこと。

NEC、VRどーすんだ？ラインナップを全部そろえとくってだけ？
UD3000って…1個のFPGAで実装できるのかな？本番はHardCopyなんだろうけど。

hosyu

トイレまだ？

>>296
もうトイレネタは要らない。

一部屋に１つトイレがあって、他のトイレにいきたい場合は、行きたいトイレが
ある部屋の主に話つけるって感じか。

遠いとお漏らししそうだのう。

初めて見たが凄いｽﾚだな。ﾌﾞｯｸﾏｰｸしますた。

保守age

Sun、暗号化プロセッサ搭載の8コア“Niagara”発表へ
http://www.itmedia.co.jp/news/articles/0406/18/news021.html

＞　Niagaraは8個のプロセッサコアを備え、それぞれが4個の独立した
＞プロセッシングタスク（スレッド）を同時に実行できる。

＞　Niagaraの各プロセッサコアには暗号化専用のコプロセッサがそれぞれ1個、
＞プロセッサには浮動小数点演算プロセッサ、3MバイトのL2キャッシュが含まれる。
32スレッド/チップなので、1スレッド当たり100KB以下しかL2キャッシュが無い。
いくら「スレッド毎のデータは共通部分がある」と言っても、小さ過ぎる
(OpteronのL1キャッシュより小さい)。

＞　Sunは取材に対しコメントを控えたが、Niagaraベースの出荷は2006年初めを予定している。
２００６！
「このchipは製品にならない」に５００ペリカ。

>>301
Niagara随分前に聞いた記憶がありますな。本当に出るのね。
でも32スレッド同時実行で3MB L2キャッシュが適合する
アプリって殆ど無いんじゃないかなぁ。
staticなコンテンツを配信するhttpd？でもそんなんだったら
激安IA-32数台並べりゃ良い訳で・・・うーん。

ブレードサーバー用だぞ。数台並べられるところにはいらんだろうな。

良スレage

CPU換装したらここで試せや。
http://www5e.biglobe.ne.jp/~liquor/raytrace/

>>292
Pen4では

CPU
|
北橋-RAM
|
PCIとか

てな感じ(ややこしいのでAGPは省略)

Opの場合、たとえばうちにあるK8T-Master2だと

CPU2
|
CPU1-RAM
|
AGPトンネル-グラボ
|
PCIとか

と従来の北橋がCPUに入れ替わった感じになってる


この場合、CPU2から見たら北橋がCPU1に変わっただけで、
速度的なデメリットはないと思われ。
むしろ、RAMコントローラが1.6GHz稼動してるわけで、
その意味での速度的メリットが少しあるかも(あくまで推測)

CPU1から見たらRAMが手元にあるわけで、
レイテンシの削減というメリットは大きい。
雷K8Wとかの二つのOp両方にRAMが刺さるタイプだと、
もっとメリットは大きいと思う、、たぶん

>1.6GHz稼動
メモリコントローラは1/2じゃなかったっけ？

OpとAth64のメモリコントローラはCPUクロックと等速です。

http://www.amd.com/jp-ja/Processors/ProductInformation/0,,30_118_4699_7980%5E7983,00.html

AMD Athlon 64 プロセッサとAMD Opteron プロセッサは、プロセッサ内部にDDRメモリ・コントローラを
内蔵することによって、そうしたボトルネックを直接解消し、x86ベース・プロセッサのメイン・メモリへの
アクセス方法を一新しました。プロセッサのコア周波数で動作する内蔵メモリ・コントローラは、プロセッサ
が直接使用可能なバンド幅を大幅に拡大し、しかもレイテンシは著しく短縮します。

と思いきやクロスバスイッチがHT接続な為HTの速度＝メモリの最高アクセススピード

Pen4
ハイパースルー
ttp://k.m-page.jp/m.asp?u=haraj

>>310 は広告。
スルーでおけ。

しかしあれだよな、Opteron、Athlon 64、そしてPentium Mに比べると、
Pentium 4の非効率さといったらとんでもないよな。
エンコード等、限られた用途にしか使えないCPU、Pentium 4。
NetBurst以外の部分は、色々と興味深いCPUだったんだが、
売りだったアーキテクチャが一番の足かせとなった良い例。

んだけど、普通の人にとってCPUパワーが必要なのはエンコードくらいじゃない?
だから、エンコードが速いというのは、いいと思う。

ただね、ハードウェア・エンコーダに比べてコスト高いね。ソフトのほうが柔軟だけど。

でも、な・ぜ・か
ソフトエンコーダのほうが、他で再生できないとかのトラブル多いんだよね。

柔軟性が高い分デコーダにとってイレギュラーなストリームを作りやすいんだろ

>>314
ハードウェアで再生できなかったら対処の使用もないな。

>>316
１：事実に対して仮定を持ち出す

漏れみたいな画質厨が求めるエンコーダーとなると
ソフトウェアエンコーダーしかないけど、
消費電力比で考えるととんでもなく効率が悪いよなあ。

RISCネタなのでこっちにも貼っておきましょう。

POWER5の性能　http://pc5.2ch.net/test/read.cgi/jisaku/1078614189/577n-585

記念ｶｷｺ

>>318
それ言い出したらPCなんて使えなくなるさ。

既に一定以上のコンピューティングパワーがあるから
効率とかの愚痴も言えるわけで、今更GHz以前のCPUも使えないし、
PCクラスタのスパコンの効率とか見たら、全てがどうでも良くなってきたよ。

MPEG4のエンコード、ハードウェアでやるとリアルタイムで、しかも消費電力は数Wですよ。

>>322
しかし、チップによって計算結果が異なる罠。

>>323
ソフトでもエンジンによって違うんだから、
その指摘にどんな意味が？

いっそのことUSB接続のハードウェアエンコーダーとか出ても良さそうな気がするが…
キャプチャーじゃなくて動画ファイルを専用チップでエンコードしてくれる物。
PCIボードのヤツはあるけどUSBタイプって無いよね？

USBもあるけど、ビデオ入力端子からの映像をエンコードしてUSB経由でPCに渡すもの。
みんなが欲しいのは、PCから映像を渡して、エンコード結果を受け取れるものだよね。

画質厨はパラメーターを弄れれば弄れるほど有り難がるからな。
ソフトエンコードに流れるのは致し方あるまいて。

俺は簡単操作で速いハードエンコードの方が好きだけど。

>>322
リアルタイムエンコードは普通に出来るようになったけど、
PC上にある動画データを実時間よりも速い速度でエンコー
ドする事って今のチップで可能なんですかね？

倍速になっただけでも実時間の半分になるのになぁ。

7倍速エンコチップとか民生用にさえ普通にあるじゃん

つか、なんでかんでも無意味に厨付けるのはやめれ。

エンコエンコってそんなに映像溜め込んでどうすんの？

>>328
ああ、>>318って付けた方がよかったかの？　たかが10レス
前の話だから、ちゃんと流れ読んでれば理解できると思った
からさ。まぁあれだ。彼が「画質厨」と名乗ってるから、
それを受けたまでの事っす。

それはさて置き、チップがあってもチップの応用製品がなきゃ
意味無いんだよな。PC向けの民生用ボードはないの？

>>329
同意。素直に"スゴ録"でも買っとけ。

http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20040715/147310/

この記事って既出？内容が噴飯ものなんですが･･･

>332
時代についてこれていない人がいるようですね > 日経

(P4 系を Intel がキャンセルした理由が全然分かっていないって感じ)

>>332, 333
どこが変なの?
詳しく教えて。

たるさんのパソコンフィールドとかDOS/V POWERREPORTとか適当に読めば分かる。

そこでたる某を持ち出すなよって気はする。

>>335
わかんねーよ

つまり記者は最後の一行が言いたかったんだな

たる坊のページ見てたら洗脳されそうになりました

たる坊はかなり素人だからなぁ…

たるさんは結構数字を持ち出してくるので何だか納得してしまう。
>>332
も既出でしょとか思いながら普通に読んだ。
これってトイレ話でいうとどういうこと？

あえていおう。　

　　日本にＣＰＵの専門家はいましぇん。

日本では専門家だったとしても、世界的にみれば研究生レベルだったりするorz

スーパースカラ機とベクトルパラレル機の違いって結局何なん？
どちらも命令を並列実行することには変わりないけど。

MIMDとSIMD

>>342 それは学問的にって事？
日立のSHとか東芝のエモーションエンジンとか作ってる人間は専門家の範疇じゃないのか？

日立やNECはいいCPUつくるよなぁ

>>343
スーパスケーラやVLIWはパラレルプロセッサの一部。MIMD。
ただ、スーパスケーラやVLIWはプロセッサ内の命令単位の並列処理に、
パラレルプロセッサはタスク毎の並列処理に言い分けられるｺﾄが多い。
誰が、どのレベルでスケジューリングしてるかの差なんだけどね。

ベクトルプロセッサは大量のデータを単一の演算でまとめて処理するもの。SIMD
行列計算に向くけど、最近はストリームの処理で良く使ってる。
y=f(x)っていう演算で、xが100万件の集合ならば、答えであるyも100万件の
集合なんだけど、それを一度に計算する。

なるほどな。しかもよく読んだら概出だった。すまん。
で、疑問な点が、（どこぞにかかれていたわけだがｗ）
スーパスケーラはメモリレイテンシの影響を受けやすい
アーキテクチャだということ。そうなのか？
結局ベクトルだろうが、スーパスケーラだろうが、同じように影響してきそうな
気がしてしょうがないんだが。

それは同じだと思うけどなぁ。

ただ、プログラム生成時にあらかじめ実行順を決めてしまい、
あとは淡々とこなしていくVLIWに比べ、
スーパスケーラは実行時に依存関係の抽出や実行順の変更を行うので、
インストラクションキューに対する要求は高いかもしれない。

スーパパイプラインとかと勘違いしてね？
こっちだと、無効になったパイプを埋めなおすのにメモリ(キャッシュ）から
再ロードするわけだけど、そのレイテンシが大きいとパイプは空いたままで
実行効率は落ちまくる。

だよなｗ
変だなと思って、その某･･･を読み返してみた。

「しかし、ベクトルプロセッサではベクトル演算機構に時系列で連続に
多くのデータを送り込む必要がある。そうしないと、せっかくの
ベクトルパイプラインがストールしてしまうのである。そのため、
ベクトルプロセッサではスカラプロセッサと異なり、 レイテンシより
むしろバンド幅がボトルネックになっている。 つまり、ベクトル型スパコンでは
まさにバンド幅こそ生命線なのである。」

なるほどな。相対的に、レイテンシが重要ってことか。

またトイレの話を使うと

・内部に便器が２つあるトイレが２軒ある。
・入ってくる人間は全て同じ時間で排便して出ていくと仮定する
・一方のトイレにはドアが２つ、もう一方には１つだけついていて
それぞれのドアの前に人が並んでいる

このとき
・ドアが一つのトイレでは列をなるべく早く進めることが重要(=レイテンシ)
・ドアが二つのトイレでは二つの入口を常に埋めておくことが重要(=バス幅)
ということでいいんでないか

>>351
ちがうちがう。別モノなのに同列で説明しちゃダメ。

いいか？
うんこしてケツ拭くのにかかる時間は>>157によると3,4のステージで合計90秒だ。
4のステージ後に水でうんこを流したとしても、次のFlush要求は90秒後だから、
90秒かけてタンクに水を貯めても間に合う。レイテンシは90秒でOkだ。

大便器と小便器が分けられてる分けられてるのに水タンクが一つだとうどうなる
だろう。おそらくFlush要求は90秒より短い。同時に要求があったときはあきらめる
としても、少なくとも半分の45秒以内で貯められないと、理想状態である二倍の
処理には追いつかない。

脱糞や放尿する、という「行為そのものを滞りなく処理しつづける」ためには、
滞る要因を極力排除しなくてはいけないわけで、レイテンシが重要になる。

ただし、うんこをきちんと流すためには、一回分の水が時間内で流れてくるだけの、
必要にして十分な管の太さが必要なことは、言うまでもないことだ。

一方、「大量のうんこをとにかく早く流したい」という要求も世の中には存在する。
>>157のように一連の脱糞行為をこなすわけではなく、ただひたすら溜まったうんこを
流し続けるという非常に限定された条件だが、これが可能になると例えばイベント会場
で何万人という人間が脱糞したうんこを、瞬時に会場外へ流せるためすっきり感が違う。

>>157のﾄｲﾚでは、千人にうんこをさせて、そのすべてを流すには 480秒x1,000で
なんと480,000秒という気の長い時間がかかってしまう。実に5日半だ。
「うんこする」のが目的ではなく「うんこを流す」のが目的なんだから、
パンツ下ろしたりする時間ははっきりいって無駄である。無駄な時間がつもると
こんな非現実的なことになってしまうわけだ。

そこで、一人分のうんこを5秒で流す装置を導入してみよう。
なんと5,000秒、つまり一時間半ですべてのうんこを流すことが可能になる。

実際には流す水をためなくてはいけない。何せ千人分のうんこをながす水だ。
そのレイテンシたるや膨大で、一人分に90秒として 90,000秒かかってしまう。
しかし！すべての時間は合計でわずか95,000秒。わずか一日ちょっと、
一人一人処理する時間とくらべ 1/5で済んでしまう。

気をつけなくてはいけないのは、管の太さだ。
一人一人寄りする場合、90秒で流しきれればそれほど困らなかったのに対し、
今回は僅か 5秒で、一回分のうんこと水を流さないとあふれてしまう。
実に18倍の太さが必要となるわけである。

j=x[0];k=z[0];i=j*k;y[0]=i;/*xとzの要素をメモリから読み出して*/
j=x[1];k=z[1];i=j*k;y[1]=i;/*掛け算して、メモリに書き出すのを*/
　　　：
j=x[999];k=z[999];i=j*k;y[999]=i;/*1000回繰り返す。ﾙｰﾌﾟが展開されたと思いねぇ*/

っていうプログラムを >>352、

y[0..999] = x[0..999]*z[0..999]/*xの要素列とzの要素列をかけてyの要素列に書き出す*/

っていうベクトル利用を>>353って思いねぇ。

ｳﾝｺ━━━━(ﾟ∀ﾟ)━━━━ｯ!!

クサ〜

ager

これだけウンコの話しててクソスレにならないところが萌え

今月のDesignWaveに載ってたリコンフィギャブルデバイスってどうよ？
CPU+再構成可能演算機アレイって構成で、
内部にコンフィグメモリが3バンクくらい積んであって、1クロックで切り替えられるらしい。

V33Aマンセー

>>358
稀にみる良スレだな。

>>359
アイピーフレックスのヤツかい？
FPGA使いから見ると、ツールまだちと高いような。
ASIC屋さんはどう見ているのかな？

Ajinomoto
General
Foods

まじかよ。

CPU換装したら、ここで試せや↓
http://www5e.biglobe.ne.jp/~liquor/raytrace/

644 名前： 名無しさん＠初回限定 投稿日： 04/08/10 19:29 ID:Hi629IqC

・ゴーストうんこ　　出たと思って下を見ると、便器には落ちてない。でも紙にはちゃんと付くうんこ。
・クリーンうんこ　　出たと思って下を見ると、確かに出ている。でも紙はよごれないうんこ。
・ウェットうんこ　　50回ふいても、まだ付いている気がするうんこ。万一のことを考えて、パンツにトイレットペーパーをあてがってトイレを出ることも。
・セカンドうんこ　　終わってパンツを上げかけたところで、再びもよおすうんこ。試してみると、確かにまだ出る。
・ヘビーうんこ　　　食べ過ぎ飲み過ぎの翌日のうんこ。重くて流れにくい。
・ロケットうんこ　　すごい速度で出てくるので、パンツをすばやくおろさなくてはならない、そんなうんこ。
・パワーうんこ　　　勢いがあるので、水がピチョンとはねかえってくるうんこ。広範囲を拭かなくてはならない。
・リキッドうんこ　　液状で、一般に痛みと音がすさまじいうんこ。３日たっても肛門が痛いことがある。
・ショッキングうんこ　　においが強烈なため、便後１時間は誰もそのトイレに入れない、そんなうんこ。
・アフターハネムーンうんこ　　すぐそばに他の人がいても、平気で音とともに出せるようになる、そんなうんこ。
・７１１うんこ
・ボイスうんこ　　あまりにも固くて切れないので、出すのにかけ声が必要なうんこ。
・ブレイクうんこ　　量が多すぎるため、休憩をとっていったん水を流さないとあふれてしまううんこ。
・バック・トゥ・ネイチャーうんこ　　森の中や田舎のあぜ道、時にはビルの地下などにナチュラルにしてあるうんこ。
・インポッシブルうんこ　　絶対にトイレに行けない状況のときにもよおすうんこ。すべてをあきらめるか、バック・トゥ・ネイチャーうんこしかない。
・エアーうんこ　　出そうな気はするのに、何回やっても屁しか出てこない仮そめのうんこ。
・ダイナマイト☆うんこ
・ノーエアーうんこ　　屁だと思って軽く力を入れたら、出てきてしまったうんこ。多くの場合、取り返しのつかないことになる。
・ホップステップうんこ　　徐々にでてくるうんこがでかくなってくるうんこ。
・フェイクうんこ　　最初はクリーンうんこだったのに、その後リキッドうんこがでてくる、そんなうんこ。

>366
それ、このｽﾚでは凄く浮いてるから、キミが恥ずかしいだけだよ。

場違い晒し上げ

エアーうんこ、にはテネスムスという立派な別称があります。

それ、このｽﾚでは凄く浮いてるから、キミが恥ずかしいだけだよ

おまいら、Pentium Mのアーキテクチャについてはどう思う？
節電機構なんかはかなりの優れものだが・・・

それよりプロセッサーナンバーをどうにかしてくれないか？
周波数がイヤならせめてベンチマークと数字を比例にしてくれよ。

　アプリケーション（プログラムって言うべきか）によって大きくパフォーマンスに
差が出てくるから、性能指標って結構難しいよね。
　新命令関係って用途が限られてくるから、マルチ演算みたいなものを排除した
平均CPIとクロックを掛けたものを表示してくれるだけでも良い感じ。

　まぁそんなことしたら差別化が難しくなってしまうわけですが・・・。

　CPIじゃない、IPCだよ・・・。脳内変換よろ・・・

ところでだ。
いま現在新品パーツでPCなりワークステーションなりを自作(自組み)する場合に、
x86とその上位互換のCPU以外に選択枝はあるのか?

>>375
これはx86以外のATXフォームファクタのマザーはあるかという質問だと思っていい？
ttp://www.simtec.co.uk/products/EB110ATX/
ここあたりのARMとかだとATXだし楽。値段も...まぁぎりぎり許容範囲だろう。
中古ならSPARCとかAlphaとかあるがねぇ。新品だとこの辺ぐらいしか知らん。

ATXでなくていいならSBCの類がいくらでもあると思うぞ。

StrongARMの存在を忘れてた、すまぬ。
この板がSBCを扱う所かどうかが判らないからSBCの類は考えに入れてなかった。
スレタイトルの[]の中が自作PC板的におかしい気がしたから聞いてみただけなんだ(´･ω･`)

Alphaは今でも欲しいと思うことがある。

　

http://www.sbc21.co.jp/
ここの事かな？いや、やけにローカルすぎる。
http://www.sbc.co.jp/
こっちだな。

>>379
マジレスするとPICMGやPC104でぐぐれ＞SBC
VMEやCompactPCIでもいいぞ。

>>371
極めて効果の高い節電機構は素晴らしいが、実行アーキテクチャについては陳腐の一言に尽きる。

大容量キャッシュとQDR、そしてSSE2を採用しただけで、本質的にはP6コア。
P6コア自体は間違いなく傑作だが、十年ほども前に開発したアーキテクチャに今でもすがるのは
名実ともに業界のリーダーであるIntelにあるまじき恥ずかしい状況。

特に今は、AMD64やメモリコントローラの統合、デュアルコアを見据えたバス設計などの
革命的に斬新なK8アーキテクチャがあるからこそ、よけいにIntelの不甲斐なさが際立ってしまう。

P6以来のIntelはP6コアのマイナーチェンジと
クロックのみ優先のNetBurstなんかにすがり続けた数年だったから
IPC向上技術についてAMDに差を付けられている感が拭えないが…

とはいえ技術力と資金力のある会社だから、もう少しAMDにシェアでも技術力でも煽られて
今度こそP6の後継となるような新しいコアアーキテクチャの開発に取り組むことを期待したい。

K8って、K7を64ビットに拡張して、メモリコントローラを内蔵して、HTを持っただけでは?
外側は変わったけど、中身については変わってないと思う・・・。

確かにP6->Netburst程のインパクトはないね＞K7->K8
もっともNetburstが成功したかというとあれなわけだが

>381
陳腐で使えるものと、革命的に発熱するばかりの斬新なDSPモドキとが
あれば堅実に使えるものを選ぶのが人の道です。

Hammer の設計は好きだけど、挙げられている機構は
大体 Alpha のパクリ(というか Alpha 人を買った)なわけだし、
"革命的に斬新" は AMD厨の私から見てもちょっと...

>382
そもそもそんなに各社のプロセッサがモデルチェンジする度に
設計を全面変更できるほど学術レベルでもネタはないんじゃ?

あ >384 の最初の2行は P-M と P4 の話で、hammer の話はまた別ね。

>>382
演算機の数は変わってないが、かなり手が加えられてるぞ。
少なくともP6→PentiumM程度には。

>>382
64に拡張すること自体、Pen4のNBみたいなアーキテクチャじゃない限り
けっこう大掛かりだと思うが。

転んだら会社が消えるくらいには大がかりだったかも＞64bit拡張
Intelが3GHz超えて北森＞ﾌﾟへの移行をスムーズに、64bit対応を独自で前倒ししてたら、
今頃AMDはどっかに身売りしてたかもしれん。それくらいｽﾚｽﾚのタイミングで濱は出てたと
思う。

ある意味、Athlon64を出せたAMDは経営哲学の神。

結局1コアだと消費電力は上がるのにクロックも性能も思うように上がらないので
断念してマルチコアへ移行するんでしょ？
そうすると性能はOSが重要な役割を演じるようになるの？

AMD って一時期倒産の危機に見舞われなかったっけ？

>387
一応 hammer は x86-64 がコケても 高速 IA32 としての道は
十分にあると踏んでいたし、HPC 市場向けには勝算はあったはず。
64bit 化によるダイの拡張は10%以下(5%だったかな?)だったし、
3DNow! みたいなもんと言えなくもない。

x86-64 がなければ Intel も IA64 以外の IA32e 64bit を
やろうとは思わなかっただろうし、その場合は(じり貧かもしれないけど)
32bit 世界で戦っていただろう。

予想以上の成功なのは確かだが、そこまで博打だったわけではない。

>>391
それは388へのレスではないの？

【AMDが倒産しかけた日】

>>388よ。お前みたいな奴をみると、あの日のことを思い出すよ。
２００２年。ＡＭＤが本格的に倒産になりかけた日だよ。
ＣＰＵの研究費が多すぎて、費用が月７００万ドルもかかってるって発表されて
「数日中に倒産」って予告されてさ、 その日のうちにあっちこっちの
部署がリストラされてた日だよ。
あのときのドレスデンの人、カッコよかったんだぜ。「総力を結集」 ってのはまさにああいう状態だよ。
ＣＰＵを６４bitにしないと倒産ってもんだから、新しい設計組んでさ、 そしたらほんの何時間かで完成したんだよ。
それが聞いてくれよ、目標は64bitCPU開発だったのに Intelを倒すことに成功しやがったんだよ。
職人技なんてもんじゃねえよ、神技だよ。
でもよ、そうやって頑張る人がいた一方で、「ボクの肛門も64bit化されそうです」
とか駄スレ立ててたバカも いたわけだよ。ちょうど、今のお前みたいにな。
だからよ、俺たちは総力を結集して、お前のＩＱを64bitにしようと思うよ。

> そしたらほんの何時間かで完成したんだよ。
ﾜﾛﾀ

Athlon64は妥協に妥協を重ねて現在の形になったのも事実なわけで。

「ボクの肛門も64bit化されそうです」

皺が増えるのか

>392
あ、そうかも。まあここ最近の数レスへのレスということで勘弁してくれぃ。

　でもさ、64bit化は遅かれ早かれ来るとして、AMDが取った方法は最も安易で
あることは間違いない。
　Ia32の限界を見越して、無理を承知で命令セットアーキテクチャを刷新するってのも
また必要な考えなんじゃないかと思う。x86を作ってきたIntelとしては、当然やらなくちゃ
いけないことだったんじゃないかと思うんだよね。x86命令って、無駄にデコード
時間がかかるのは避けられないみたいだし。

　まぁつまりだ、AMDはIntelの築いた土俵で強くなってきた、でも、Intelの敵は
他の土俵を作り上げようとしている者達なんだよ。ってのはいいすぎ？。
そういう意味では、内にも外にも敵を抱えて大変だよな・・・。

まぁでも・・・

IntelがIA-64に最新プロセスを使ってないにしても、
IA-32を捨てた割にはIA-64の性能が悪いと思う。

Itanium2は浮動小数点の演算は速いけど、それはx87が、あまりに古いため。
Intelのコンパイラは、x87の代わりにSSE2を使ったコードを吐けて、それは速いから。

しかし、いままでIntelがIA32以外のアーキで作った石は(Xscaleは別として)
ことごとくこけているのだよねぇ。iAPX然り、i860然り。
＃後者はI/Oプロセサとして生き残ってはいるが...
さらにIA64もその後を追おうとしているわけで...

いやいや、隠れた名作のMCS-48がありますよ。
キーボードに内蔵されているので、セカンドソースやカスタムを含めると、
もっとも売れている・・・かもしれない。

ちなみに、iAPXはIntelのアーキテクチャにつく冠なので、
iAPX-432まで書かないと、何のことだかわからないよ。

i860はモノが悪すぎたのだと思う。
マイクロソフトがWindowsNTを最初にi860で実装しようとしたけど、
あまりにダメダメなので、やめてしまったのは有名な話だよね。
某国内メーカーが、i860でUNIXワークステーションを作ってたけど、
ほとんど売れなかったようで、在庫を社内にバラまいて撤退したよ・・・。
i860で唯一ちゃんと使われたのは、SGIのグラフィック用マシンかな。
筐体に何枚も刺された基板にi860がびっしり積まれた写真を見たような気がします。

>396
でも long mode って IA32 と全く同じじゃなくて
IA32 の癌(は言いすぎ?)のいくつかの命令は外してあるんじゃなかった?

デコードの負担とは言うけど、似たような事情で初期の
RISC 陣営が過去の互換性を気にせずにパフォーマンスで優位に立ったが
時間経過と共に RISC サイドも互換性問題等で結局身軽ではなくなった、
ということもあるし、ダイに関しては対した負担じゃなし、
x86-64 というのは今考えても現実的な選択なんじゃないかな。

>>402
再取得したほういいぞ。

>>400
>＃後者はI/Oプロセサとして生き残ってはいるが...
そりはi960でi860とはまったくの別物であ。

>>401
>某国内メーカーが、i860でUNIXワークステーションを作ってたけど、
○kiか？○kiのｺﾄだなっ!?
K〓〓はちがうぞ、○kiのOEMだからなっ

PC・WS市場ではIA-32以外確かに不発で終わってるけど、
i960等の組み込み系は強いよ。PXA系とか。

>>404
むむぅ。i860/i960と一緒くたに語られることが多いので全然別アーキとは知らなかった。
＃しかしPXA=Xscaleでわ。

あとi960のアプリケーションってIOP以外に何があるの？
＃他で使われているのは見ないので。

>>404
OKIの社史の205ページで、7300のことがちろっと書かれてますね。
ttp://www.oki.com/en/profile/120y/pdf/OkiHe7.pdf

クボタのTITAN VISTRAですか。中の人は、
ttp://search.luky.org/fol.1998/msg01256.html
うーん。よっぽど黒歴史だったんでしょう。

しかし、わらかないのはi860のどこが悪かったのか。
マイクロソフトは使いこなせなかったけど、SGIやOKIは使いこなしていたわけで・・・。

>>405

>あとi960のアプリケーションってIOP以外に何があるの？

レーザービームプリンタ。
90年代前半はi960とAMDの29000がこの市場で争っておった。
Weitekなんていう会社もここに参戦してたな。
ちなみに、i860が出現する前は高速浮動小数点演算の雄と言えば
Weitekであった。

>>400
Xscaleの基本設計はDECだったような。
ロジックはIntelで再設計された様だが。

>>401
生き残っているのは51じゃないすか？
まあ似たような物だが。

>>407
性能が問題外とか、バグバグだったとか色々あったようですが…
MSにi860マシンを開発するだけの技術が無かっただけかもしれんが。

>>407､408
性能は悪くなかったんです。
IntegerUnitと独立してFloatingAdderとFloatingMultiplierが同時に動いたんで、
40MHz駆動で120MOPSとかいうてました。VLIWです。籍和算最強。
当時ベクタ演算といえば>>408氏も言われてるWeitekのチップをCPUと別に載せて
実現してたけど、これを単独で行えました。LINPACKで7〜10MFlopsくらい。

問題は、コンパイラの最適化が追いつかなかったことと、
DataStoreに2clockかかって折角の演算性能が生かせなかったこと。

Intelの発表では、i860は後にi860XPと改名し、ClockUpとStoreを1clockで
こなす高速版のi860XRを出す予定だったんですが、こけました。

それが出てればなぁ、出てればなぁぁぁっ

AstaVistra, Baby.

>>408
ｺ｣ｻ�､ﾎLBP､ﾃ､ﾆﾂ酘IPS､ｫPowerPC､｢､ｿ､熙ﾀ､ﾈｻﾗ､ｦ､ｱ､ﾉ｡｣
ｺ｣､ﾇ､稱960､ｬLBP､ﾋﾆ�､ﾃ､ﾆ､?､ﾎ｡ｩ･ｵ･ﾖ･ﾗ･�ﾁｻ･ﾃ･ｵ､ｫ､ﾊ｡｣

うぅ。化けた。
>>408
今時のLBPって大体MIPSかPowerPCあたりだと思うけど。
今でもi960がLBPにのってるの？サブプロセッサかな。

>>412

うーん、今はi960がメインに載っているLBPはあるのかなぁ？
流石になくなっているかもね。
インテルのWeb見てもi960はもう売る気ないみたいだし。
408で書いたのはあくまでIOPとして延命される前の話ということで。

クロック非同期型CPU・・。
どうなったんでしょうね？

最近トンと噂すら聞こえてこないですね。

i960
最近はRAIDカードでも見なくなってきた。
そろそろ消滅かな。
最近のレーザープリンターはMIPSかPowerPCしか見ない。
NECのは無論自社のVRばかり。
本体はゼロックスそのものですが。

XScaleってARMじゃないの?

>>416
ARMの定義による。
ARM社は自分のところのコアをほかにいじらせない(→だからICEなど開発環境の互換性が極めて高い)
のだけどIntel(というか元DEC)だけにはコア自体をいじるライセンスを与えている。
＃だから命令セットもびみょーに違う。

ARM純正コアをARMと呼ぶとするならXscaleはARMではなくARM互換プロセッサと呼ぶんじゃないかと。

>>417
なるほど。

>>407
カトラーが怒ってたのは例外まわりだったかな。
まあ例外関係は88000もクソだったわけだが。
ほかのRISCはどうだったっけ。

ちなみのどのようにクソかというと、
・すべての割り込みと例外が単一のハンドラに飛ぶので、ハンドラ内で
要因を特定しないといけない
・TLBミスでもミスした命令のアドレスしかわからないので、ハンドラ内で
命令のinterpretをしないといけない
・分岐遅延スロットで起きた例外の扱いも面倒で死ぬる

>>420
数値演算プロセッサとして使ったSGIはともかく、
SystemVを移植したOKIって根性あったんだ。
報われない努力だったのが、OKIらしいな・・・。

>>421

根性っていうより趣味の問題でしょ。
あの程度の例外仕様でプログラム書けないんじゃOSなんてとても書けないよ。
結局嫌いだというのを誇張するために色々と言ってみる訳だ。
CPUアーキテクトから見るとあの程度のプログラムかけない方がクソなのかも。

960はゲーセン基板で使われてた
FinalLapやModel2がこれだったな

>>422
１回こっきりしか使わないハードにそんなCPU乗せられたら切れるだろ。
１タイトル作ったらもう全部のソースは必要なくなるんだよ。

>>422
しかし例外ハンドラが重いと性能にひびくからな。

>>422
＞あの程度の例外仕様でプログラム書けないんじゃOSなんてとても書けないよ。

>>420の２番目の
＞・TLBミスでもミスした命令のアドレスしかわからないので、ハンドラ内で
＞命令のinterpretをしないといけない
なんかは明らかにアーキテクチャ設計不良だと思う。
だってハードウェアはミスしたアドレスを知っているはずで、それをソフトウェアに
知らせられれば例外処理が簡単で速くなるのが明らかなのに、アーキテクチャとして
そういうインターフェースを作っていないんだから。ミスしたアドレスを知らせる
仕組みを入れても、それでダイサイズが増えるようなことは無いだろうし。

「チーフアーキテクト逝ってよし」だな。

って言うかさ、割り込み＆例外が一箇所に全部集まっちゃったら
多重割り込みとかの優先順位付けが楽になるかも知れないけど、
どー考えてもオーバーヘッドでかいだろ。
さっさと処理する必要があるハードウェア割り込みとかどーすんだ？

>・TLBミスでもミスした命令のアドレスしかわからないので、ハンドラ内で
>命令のinterpretをしないといけない

特権命令例外とかだって大変だろ、これだと。

エントリポイントが１個でも、割り込みコードみたいなものを読めば、簡単に割り込み要因の
解析ができるなら、それほど問題ではないような。
しかし、このヘボ チーフアーキテクトのデザインだとそう簡単ではなくて、あっちこっちの
レジスタを見ないと割り込み要因解析ができないような悪寒。

センスねーな・・・

Intelの設計したアーキテクチャで、これはきれいだと言えるのはあるのか？

インテルのCPU設計の創始者は、化学屋さんだから・・・とか言ってみる。

Jargon Fileに
The Intel i860's exception handling is extraordinarily funky.
とか書かれてるな。

それはともかく80286は美しいと思うぞ。
設計思想は明確だしよく練られているし性能も悪くない。

俺、歴代のIntelCPUだと486とPentiumProが好きなんだけど
最近知ったんだがどっちも同じチームの開発らしいな。

ちなみにPentiumProは好きだが、L2を外に出してるのとL2が無いのは好かん。

IA-64はどうよ?
VLIWという一時期の流行に過ぎないものを採用してしまった悲劇のアーキテクチャに思える。

>>432
286の設計時点で386のような拡張を視野にいれてたんでしょうか？

286は386までの繋ぎだったような
最初から386を作ることを想定していたようなリザーブが多々ある

>>426

>だってハードウェアはミスしたアドレスを知っているはずで、それをソフトウェアに
>知らせられれば例外処理が簡単で速くなるのが明らかなのに

ん？　アドレスは知らせているのだよ。

>＞・TLBミスでもミスした命令のアドレスしかわからないので

ほらね。

iAPX432>430

486は良かったな…DX4であっという間に処理速度３倍になったんだから…

Cyrixの方が好き。

Cyrix5x86は速かったよね。

>>434
今、「一から作った」ハイ・ミドルエンドCPUでVLIWじゃないのあるか？

IA-64はむしろバイナリ互換性にこだわってEPICなんて作ったのが（ｒｙ

しかしそれをいうなら
「今、「一から作った」ハイ・ミドルエンドCPU」
ってIA64以外にあるのか？

ちなみに普通にVLIWで作っちゃうとnopのスロットばかりでバスを食っちゃう
ので適当につめる仕組みを作るのが普通。EPICなしで全部並べたらコード
スカスカになると思うよ。

>>443
NOPばかりだとバスも食うしI-Cacheも無駄が多くてダメだもんな。

>>437
ミスした命令のアドレスと、TLBミスしたアドレスは全然違うぞ。

>>445

そっか、命令フェッチのミスじゃなくてデータフェッチのミスなのね。
理解した、ありがとう。
もっとも80860はTLBミスは勝手に処理してくれるみたいよ。
詳しい資料が手元にないのだけど、例外が発生するのはページフォールトの時。
それなら性能に対するインパクトはあまりないと思う。

>>443

>IA64以外にあるのか？

CELLとか言ってみる。

>447
ベースは MIPS 流れじゃネーノ?

TLBミス時の処理はハードウェアで自動処理なのに、
ページフォルトはアクセスアドレスすら返さないというのは
ずいぶん偏った実装だな。>i860

Transmetaもあるし

>>435,436
まあ、拡張の余地を残した設計ではあるけど、
アーキテクチャとしては完成形ではないか。
386以降の拡張はあまり美しいとはいえんじゃろ。

まあ、x86のセグメントと非直交性をこよなく愛する68k嫌いの意見なので
割り引いてくだされ。

68kはどうも小学生の考えたドリームチップみたいで嫌いなんだよ。

86も小学生が考えてればもうちょっとマシになっただろうになあ
こんなもんが普及してしまったせいで世界中の人が苦労した

>>448
powerPCだったりする。

俺はx86で苦労した覚えはないのだが、世界中の人はどこで苦労したんだろ。

64KBの壁は面倒くさかった。

Cを使った時nearとかfarとかhugeとかウザかった。

NECの中の人はバンク切り替え(ﾌﾟで苦労したんだろうし、
EMSだのXMSだので苦労した香具師も多かろう。

セグメントで苦労しなかったやつなんているのかね
まあ419は実際にはさわったこともないんだろうけど
プログラム組まない人でもUMBとかEMSとかムダに苦労しただろうな

プログラムが組みづらい＝汚くなるだけでなく、遅くなるし。

EMSだのXMSだので苦労するのははゲイツの糞DOSのせいだろ。
Macなんて32KBの壁があったしな。

セグメントに触れないのは認めたからかw

8086で64KBを越えるデータ構造を扱うのは面倒くさいが、
それはそういう使い方をするほうが間違いだろう。

ついでにいっとくがEMSで苦労するのはべつにMSのせいではない
8086が1Mbytesのアドレッシング空間しか持ってなくてしかも将来の
拡張を見越した仕様になってなかったから

8086では64KBをこえるデータはアクセスしてはいけないそうです
グラフィック画面とか実装するのは間違いってことだな

>>465
そうだよ。知らないかったのかい？

おぃおぃ。

そっかー。
ＭＳのせいにしていいんだったら、セグメント使いにくいのも
ＭＳのせいだよな、うん。

しかしINTELもよくこんなクソなもん作ったよなあ
8086はあくまでその場しのぎの急ごしらえで本命は8800だったらしいが

8086に1MB以上積もうとするのは、明らかに間違ってたと思う。
ただ、セグメントサイズそのままに16MBに広げた286はどうかと思うよ。

セグメントには正しい使い方というのがあって、
DOSはそれに外れた使い方をしていたというだけのこと。

>>469

よくよく考えると、Intelが狙った方向にはちっとも行かないのね。
なんか、本業はミュージシャンのつもりなのに、人生相談の人として
評価されている…みたいな感じがするｗ

>>472
他の優れたアーキテクチャにつぶされることもなく主流をいく
X86にはCPU運とでもいうべきものがあるのかもしれんな
おかげでダーティなアーキテクチャに苦労させられるわけだが

>>452
V60〜V80はもっと嫌だろ?

メアド前のが残ってた_|￣|〇

IBM360とスーパーファミコンでアセンブラプログラミングしたことがあると、
8086の命令体系は、まだ綺麗な方だと思えるようになってくるぞ。

べつに汚くは無いよ。美しくはないが。＞8086
MMU内蔵8080だよ。インテルも制御用を主目的に作った。
あれでモダンなOSを走らせることなど想定してないし、
また実際走らなかった。
68000はメモリ効率が悪い。冗長性に腹が立ってくる。
トランジスタを浪費してる割に速くもない。
パクリ元のVAX自体からしてウンコ。設計思想がオナニー。
x86にはマイコン的楽しさがあるね。

そーかぁ
68000は乱暴な言い方だけど、とりあえずメモリとかくっつければ動くから
ワンボードなんか作るのは結構楽だった
配線は多いけど

まぁ、x86と68000 どっちがマイコン的に楽しいかは、趣味の問題だろう

ワンボード作りやすいかどうかは寧ろ、バス設計によると思われ。
確かに68Kは作りやすかった。
当時8086と違って特権モードをサポートしてたので、格好良い印象はあったね。
実際はバグがあって、仮想メモリ実装できなかった記憶があるが・・・

68000の仮想記憶サポートのバグ説は微妙っぽ。
ttp://www.st.rim.or.jp/~nkomatsu/mc68kperipheral/MC68451.html

スーパールカニ

分かっている奴にはウザイ話だろうけど・・・
CPUのアーキテクチャなんてぇものはその時に使える半導体関連技術によって
最適点は変わるのよ。
68000なんて見た目はすっきりしているけど、32bitのPCに対してバスは16bit
しかないからサブルーチンコールする度に2回バスサイクルを起こしてPCを
チンタラ退避してた。だけど、PGAが使えるようになった68020ではその問題は解消。
だけど、将来の半導体関連技術に頼るアーキテクチャは大抵はビジネス的に失敗するね。

>>479
命令の再実行に必要なパラメタが、スタックフレーム上に全部積まれていない。
ってのが原因...でこれは010で修正。おかげで例外時のスタックの構成に互換性
が無くなるわけだが。

まぁ、仕様と呼ぶかバグと呼ぶかは立場によって異なるだろうねぇ。

仕様書に無い実装はバグ

8086以外の当時の16ﾋﾞｯﾄCPUって64kB越えられなかったんだぞ？
Z8000も、NS32016も。1Page64kBでアドレッシングが16ビット。
それから考えたら、遅いなりにも1MBまでアクセスできた8086って偉大だろう？

糞なのは80286採用時に8088互換としてつかったIBMだろ。
挙句に脳障害呼ばわりしやがった。

メモリアドレスが64bit化される前のアーキテクチャはだいたいアドレス空間不足が
ネックで死んでいった(ないしは64bit化された)。組み込み用でない今残っている
アーキテクチャ(AMD64/EM64T,IA-64,PowerPC,SPARC,IBM Z series,Alpha)は全て
64bit化された訳だが、次にアーキテクチャのネックになるのは何だと思う？
単純に命令を足せば実現できる機能は必要だと思えば、そういう命令を足せば
いいのでネックにはならないとすれば、何が次のネックだと思う？
Virtual Machineを実現する機能なんか必要だと思うが(IBMのにはもう入っているようだし)、
アーキテクチャ全体を考え直すような必要は無さそうだし、ちょっと思いつかない。
とすると、今のアーキテクチャをあと何10年も使い続けるのだろうか？

>>484
8086が1MBまでアクセスできたのは面白いアイデアだったけど、中途半端だった。
結果論だけど当時のDRAMの進歩の速度を考えれば、「4bitシフトで1MBまで」にしないで、
「8bitシフトで16MBまで」にしておけば、あまりストレス無く、32bitアーキテクチャである
80386までつなげられたと思う。
(ちょっと遅れて出て来た68000は24bitリニアアドレスだった訳だし)

一度Protect modeになると命令でReal modeに戻れないのは『脳障害』級のアーキテクチャバグだと思う。

80286時代に80286用のプログラムをみんなが書いていたら、80386が出た時にまた書き直す必要が出て、
無駄な努力になっていたと思う。80286は単に高速な8086として使っておいて、OSのAPIを変えるのは
80386 nativeのWindows95(実はWindows386というのもあったが)まで待ったのは正解だと思う。

まあ、俺もExtended MemoryだのExpanded Memoryだの、near/far/hugeだので苦労したことがあるから、
8086/80286のことをあまりよく言いたくけど。

問題の本質は1Mbytesのメモリ空間に64Kbytes単位でしか
アクセスできないことにあるわけで
どういいわけしようと汚いアーキテクチャ

たかが64KBの壁に悩まされるのは三流
8bit時代は64KBすら自由に扱えなかったわけだが

64Kbytesのメモリ空間に64Kbytes単位でしかアクセスできなくても誰も文句はいわんよ

半導体技術(CPUを作るロジックもメモリを作るDRAMも)の限界があるので、適当なところで
手を打つ必要があるのは明らか。この限界を超えてしまうと設計はしたけど生産できなかったり、
ほとんどの人は想定したメモリ量のはるか下で使ったりしちゃうから。
で、8086の時代内部演算16bitというのはOKだったけど、メモリアドレッシングが16bitでは
耐えられなかった。その前の世代が内部演算8bit・メモリアドレッシング16bitだったし。
ただし単純に24bitとかにアドレスを拡張してしまうと、アドレス計算を行う演算を特別に
用意しないといけなくなる。Intelの中の人はそれがきっと嫌だったんだと思う。
そこで16bit演算の枠組み内でメモリアドレッシングを拡張する仕組みを考える必要があって
「セグメントレジスタを4bitシフトして足す」というコンピュータアーキテクチャ史上初の
アイデアが投入された。仮想記憶をサポートしたOSがout of rangeだった当時を考えれば
それ程悪いアイデアではなかったのかもしれないけど、4bitシフトは少な過ぎた。
せめて8bitシフトしていれば…

問題は64KBの壁があることより、セグメントレジスタを使ってもアクセスできる範囲が
1MBしかなかったことでは。

そうだね。
4ビットシフトなんてセコいこと言わずに、8ビットシフトしても良かったね。
セグメントの区切りが16バイト毎が256バイト毎かで、そう変らないものね。

でも、1MB以上のメモリがあるなら、32ビットでアドレッシングしたない。

× 32ビットでアドレッシングしたない。
○ 32ビットでアドレッシングしたいな。

8086は8800の遅れで急遽間に合わせで作られたCPUなんよ
結局1チップにまとめられなかったAPXや1年遅れで出てきた68000
みればわかるとおり、8086のときには既に16bitをこえるアドレッシングや
仮想記憶は眼中に入ってた
8086はあくまで8800が出るまでの繋ぎで8bitの8080との互換性を最大限に
考慮して作られたCPUでセグメント、直交性のない命令体系もここからきている
アーキテクチャの汚さは互換のためだからしょうがないとはいえるが

むしゃくしゃしてやった
64KBを超えるメモリさえアクセスできれば何でもよかった
まさかこんなに長く使われるアーキテクチャになるとは思わなかった
今は反省している

>>493
8800って何？
i860、i960、iAPX432以外にまだIntelはCPUを開発していたのですか？
(88000はMotorolaだし)

つーか80386以降はほとんど別物だろ。
以前の互換性ももちろん残してはいるが。むしろ残したのが成功の原因。

>>486
>一度Protect modeになると命令でReal modeに戻れないのは『脳障害』級のアーキテクチャバグだと思う。
それ、必ず言われることだけど、なぜわざわざRealModeに戻る必要がある？といいたい。
まさに互換のためなんだけどね。でも互換ならRealModeからProtectModeに移る必要はない。
結局、そのためだけに80386なんて仮想86モードなんて小汚いモード追加されちゃうわけで、
僕からいわせてもらうと「狂ったメモリ管理しか思いつかなかったIBMの尻拭い」させられた格好。

ソフト開発の手間を指摘しているけど、早期にProtectModeのプログラミングに慣れていれば、
自己書き換えなどのような乱暴なソフトなんて早期に駆逐されただろうし、いまさら保護ビット
なんて追加しなくてもメモリ保護はできたろうし、セグメント管理による仮想空間に世間が
慣れていれば、80386時代にはとっくに16Tのメモリ空間が手に入っていた。
PentiumProの36ﾋﾞｯﾄ物理アドレスも有効活用されてたろうに。

80286のProtectModeを最大限に発揮するはずだったOS/2が遅れたのが敗因だとはおもう。
実際、FarやNearポインタで苦しんだのって、MS-DOS2.x以降、1983年よりあとだよね。
MS-DOS2.11ならすでに1984年だ。

8080の互換（もどき）CPUとして1978年につくられた8086、
それを1984年にもなって時代は1MBドコロじゃなくなっていたにもかかわらず、
過去の互換性を堅持したがったIBMが、腐った互換パソコンなんて出したのが、
未だ互換に苦しんでる元凶におもえる。

1985年にはPMMUと4GBのセグメントをぶら下げて80386も登場してるわけで、
（でも、1992年のWindows3.1までは、それは日の目をみられなかった）
時代背景的にはIntelの歩んだ道はまぁ、それほど酷くないかな、とおもうわけ。

うへ、長すぎた、ごめん。

そうなんだよね。
保護したいからプロテクトモードなのに、リアルモードに戻れちゃったら
やりたい放題されて保護の意味が無い訳で…。

また8086が登場した当時は確かに1MBytesあれば十分に思えた。
9801初代が、128kBytesで出てきたのは有名な話だし、
9801VM世代でも384kBytesしか標準実装して無かった。

1984年のIBM PC-AT(80286)で512kBytesだったのだから、
640kBytes実装されるまでには286世代への移行は可能だったと思うけど…。

>>497
＞でも互換ならRealModeからProtectModeに移る必要はない。
これ理由がわかりません。
MS-DOS用に書かれたReal mode向けプログラムをどうやって80286のProtect modeで動かすのですか？
Real mode向けプログラムは「アドレス計算時はセグメントレジスタの内容が4bitシフトされて
足される」というのを前提に書かれているのがほとんどだったと思います。

＞「狂ったメモリ管理しか思いつかなかったIBMの尻拭い」
IBM-PCのメモリ管理がまずいのは、MS-DOSを作ったMicrosoftではなく、IBMの責任なのですか？
(「MicrosoftではなくSeatle Computer Productsだ」という話は置いといて)

>>499
＞保護したいからプロテクトモードなのに、リアルモードに戻れちゃったら
＞やりたい放題されて保護の意味が無い訳で…。
80286では既に特権mode(RING)がサポートされていたので，Protect mode→Real modeへ
移行する命令はRING=0でだけ実行できるようにすれば保護が破られるような問題は
発生しないし、80386はそうなっています。
80286に移行命令を付けない理由にはならないでしょう。

>>500
>MS-DOS用に書かれたReal mode向けプログラムをどうやって80286のProtect modeで動かすのですか？
80286も80386も、電源投入時はRealModeですから、ProtectModeに移らなければいいだけです。

>IBM-PCのメモリ管理がまずいのは、MS-DOSを作ったMicrosoftではなく、IBMの責任なのですか？
8088時代、1MBのメモリ空間をIBMは640kBのメモリエリアと384kBのシステムエリアにわけました。
で、空間をぱんぱんに使い切ったとき、16MBの物理メモリをもつ80286を前にとあるBadScientist。。
じゃない、エンジニアが気がついたのです。

「Baseレジスタを1MBぎりぎり最後にしてやれば、1MBをこえて60kBが余計にアクセスできるぞ！」

さらに気がつきました。

「一度ProtectModeにはいって1+α部分を、別のメモリにマップしてやれば、
任意の16MBのエリアから60kBを切り出してこれるぞ!?」

これがEMMでありHIMEMの仕組みです。
これがやりたいために、ProtectModeに移ってからRealModeに移る、という
無茶な運用設計をする羽目になり「なんで稼動状態で移動できないんだ！」
とわけわからん文句を言うはめになったわけです。

>>499
初代IBM ThePC なんて 64kBでしたもんね＞メインメモリ

あと、80386も同様にProtectModeからRealModeへの移行は出来ないはずです。
>>500さんがおっしゃってるのは仮想86モードとProtectModeの切り替えであり、
仮想86モードはProtectModeで設定された保護化にあって、メモリ保護違反等は
トラップされてProtectModeに引き戻されます。

RealModeは、メモリ保護などの保護機能は一切ありません。

>>495
8800=APX

ええい、APX432と書かんか!

iAPX86つーのがあるんだよ。中身はみんなのよく知ってるものだけど。

>>479
しかし中途半端に積む例外コンテクストを見るにつけ、
設計ミスを仕様と強弁しているだけなんじゃないかという気もする。

>>474
うん。あんまり好きじゃない。
頑張ったとは思うんだが。

>>493
セグメントは物理アドレス空間の拡張(と将来的な保護機構)のため、
直交性のない命令セットはコード密度をあげるためだよ。

直交性のない命令だと余分な命令増えてコードサイズは肥大するし遅くなるしでいいことないんだが

>>507
それはキミが3流だからだ。

三流といえばなんでも解決かw
オマエは8086で実際にプログラム組んだことが一度でもあるのか?

DSPのコードを書くときに、命令に直交性がないよウァァァンと泣きを入れるのかねキミは。

予想通りさわったことすらなしか

レジスタが少ないものコードデンシティをあげるためなんだよね！

アセンブラでごりごり書くことはあんまりなかったな。
いいコンパイラあったし。

86で深く考えずにコードを書くと直交性のなさに腹が立つかもしれんが、
コツがあるんだよ。

>>512
プロセスコンテクストの軽量化

アセンブラで書いてないのにコツがわかるのか
本当にさわったことないのがバレバレ
ためしにそのコツとやらを語ってみろ

結局これから先、インテルは軸足を IA-64 からIA-32にバックするの？
いつまでx86を引きずる事になるの？

少なくともPCに関してはIA64は完全にあきらめたっぽいが
AMD64でレジスタも増えたし(まだ足りないが)このままX86は残り続けるだろうな

>>515
レジスタの役割が決っているのでそれに反するような使い方をしなけりゃいいんだよ。
PL/Mコンパイラの出力が参考になる。

68厨のコードなんて見てるとなあ、なんでもかんでもレジスタに載せようとしたり、
ループの外でガリガリに最適化しても無駄だっつの。

( ﾟдﾟ)ﾎﾟｶｰﾝ

>>501
＞ProtectModeに移らなければいいだけです。
当時MS-DOSの1MB/640KBの壁を破るためのExpanded Memoryのようなバンク切り替え式
メモリがほぼ一般化していました。アプリケーションソフトウェアの互換性を保って
80286の大容量メモリを利用するには、over 1MBのメモリをEMSとしてアプリに見せる
必要があったので、「ずっとReadl modeのままで行け」というのは現実的な解では
ないと思います。

＞8088時代、1MBのメモリ空間をIBMは640kBのメモリエリアと384kBのシステムエリアにわけました。
8086の1MBメモリからまったくメモリの拡張の余地がなかったハードウェアだったのが
問題のようです。これはIBMの問題というよりは8086の問題で、それを前提に多くの
アプリが開発されてしまい、80286が出てきても、もう対応しようが無かった、という
話ではないですか？

＞「一度ProtectModeにはいって1+α部分を、別のメモリにマップしてやれば、
＞任意の16MBのエリアから60kBを切り出してこれるぞ!?」
上にも書きましたが、EMSというバンクメモリの仕掛けは8086時代からあって、対応した
アプリもそれなりにあったと思います。それの実現方法として、80286のProtect modeを
使うのは、それ程トリッキーなアイデアではないでしょう。
HIMEMの最後60KBのおまけは、トリッキーなアイデアだと言うのには同感です。

>>502
＞あと、80386も同様にProtectModeからRealModeへの移行は出来ないはずです。
80386のアーキテクチャマニュアルはさすがにもう無いのですが、最新のPentium4の
IA-32 Intel Architecture Software Developer's Manual Volume 3: System Programming Guide
ftp://download.intel.com/design/Pentium4/manuals/25366814.pdf
の2-7ページのFigure2-2を見ればわかるように、Protect modeからReal modeへは
PE=0で移行できるようになっています。このPE(Protection Enable)はCR0のbit0にあります．
ここのところの仕様は80386から変わっていないと思います。

また、以下の記事はEMS等の話も含めて、このあたりの経緯が詳しく書いてあります。
http://www.atmarkit.co.jp/fwin2k/special/win9xorwin2k/column_winhistory.html
＞80386では、以上の2つのモードや16bitプロテクト モード、およびリアル モードを
＞混在させて、自由に切り替えて使用することができ（80286と違って、リアル モードとの
＞切り替えは自由にできる）、

>>507
＞直交性のない命令だと余分な命令増えてコードサイズは肥大するし遅くなるしでいいことないんだが
命令フェッチ用の必要メモリ帯域はデータ用に比べれば少ないし、キャッシュは分離されて
いるので、コードサイズの肥大化は、最近のCPUではほとんど問題にはならないと思います。
それに命令数は増えても命令長自体は短くなっているので、影響はそんなに無いのでは。
まさか「アセンブリ言語で書いたプログラムの行数が増えるのが問題」とか言ってないですよね。

直行性が無くても必要ならレジスタ間MOVE命令を出せばいいし、最近のCPUは多少レジスタ間
MOVE命令が増えたところでほとんど実行速度に影響ないでしょう(スーパスカラの空きスロットで
実行される)。それにコンパイラがうまいレジスタ割付をすれば、意外とレジスタ間MOVEも
減らせるような気がします。

>>513 >>515
最近のCPUを使うのにアセンブラ言語を前提してはまずいかと。
マルチメディア系処理のタイトループでも無い限りは、コンパイラのコード生成品質が重要だと
思います。

>>518
＞レジスタの役割が決っているのでそれに反するような使い方をしなけりゃいいんだよ。
それだとコンパイラのコード生成アルゴリズムに勝てないと思います。
それで最新のiccとかのコードにでも勝てそうですか？

>>522
8086の話だぞ
最近のCPUで問題なのはレジスタの少なさによる煩雑なスタック操作だな
AMDがレジスタ増やしたが32個になってればよかったんだがなあ

>>520
>「ずっとReadl modeのままで行け」というのは現実的な解ではないと思います。
いえ、単に「高速な8088」として使いたいのであれば、という意味です。
バンクメモリの機構に関しては80286でもほぼ同様の仕組みで互換は保てたはずで、
しかしながらソフトウェアでの解決をIBMは選択しました。
結果として、ソフトウェアからハードウェアリセットを行う、という無茶なﾊｰﾄﾞｳｪｱの
追加が余儀なくされます。

1MBというメモリ空間の狭さは8086/8088の制限ですが、80286が発表され
二年も経ってから出された IBM PC/ATで「わざわざ」1MBの制限をIBMは
選択したのです。EMSはそのまま使えたにもかかわらず、です。

さらにいうと、EMS対応のアプリは多数ありましたが、80286で追加された
EMMを用いる場合は、ソフトウェア側で若干の手直しが必要でした。HIMEMに
至ってはまったくの新規であり、過去の互換性は皆無です。

まぁ、当時の「パソコン」事情からするとそういうトリッキーな処理も
「アリ」だったとは思いますが、未だ引きずってる悪しき文化の原点は
この辺にあるんじゃないかと、私は思ってます。

あと、80386の件は、私の勘違いかもしれません。詳しい説明ありがとう。

特権レベル0からリアルモードに戻れたとして、
リアルモードで動くプロセスは他の(プロテクトモードの)プロセスの
メモリを触り放題、I/Oポート叩き放題なわけで、
プロテクトモードの意義が事実上無くなる。

>>514
なんでレジスタをアキュムレータ一本にしなかったんだろうね？
そうすればコンテキストスイッチすごく速いはずなのに

フラグレジスタもいらないね。PCとSPぐらいはほしいかな？

>>520
>501で言いたかったのは(realmodeで動く必要のある)DOSと過去のソフト資産
を捨てちまえば常にprotectmodeで動けるよーってことだと思うけどね。

1MB以上メモリを使いたければprotectmodeで動くOSとソフトを走らせればいい。
そゆこと。

センスアンプについて誰か情報を持っていませんか？

センスアンプはDRAMの技術・・・。

CPUのキャッシュと言えばSRAMだというのは過去の話なんだよね。
hpのmx2のL4キャッシュはDRAMなんだよね。

>>522

>命令フェッチ用の必要メモリ帯域はデータ用に比べれば少ないし

そんなバカな？と思ったが、キャッシュ前提の話ね。

>キャッシュは分離されて
>いるので、コードサイズの肥大化は、最近のCPUではほとんど問題にはならないと思います。

えっとね、コードサイズが大きくなるとキャッシュのヒット率は下がるのよ。
だから命令セット考える時は結構気になるよ。

>>526
　ネタ？。
　レジスタ少ないと、猛烈にメモリアクセスせにゃならんと思うんだが・・・。退避する量が
減っても、1タスク内でのメモリ転送量が爆発的に増えるだろ、と。最終的に、大量の
キャッシュメモリで回避できないこともないだろうけどね。

　アーキテクチャ上の汎用レジスタは32本位、で、レジスタバンクが各特権モードにつき
2〜3段位、ってのが一番無難なんじゃないかと思うけど。いや、へたれ日曜プログラマの
俺からしたらレジスタなんて8本もありゃ足りそうだけどね・・・。

　正直、高級言語のコンパイラのほうがよっぽどきちんと資源を使ってくれるよ・・・。

質問。スレ違いかもしれないけど。
規模にも依りますが、CPUに最低限必要な機能は？

加減算と条件分岐か？

>>532

チューリングマシンとかでぐぐってみたら？

計算万能性か
XORあれば十分じゃね?

>>532
必須なのは次の3点
フェッチ、デコード、エクスキュート

世の中のプログラムをすべて理論的に作れるという意味で必要な命令は、
ロード、ストア、加算、AND、OR、NOTくらいか

あとフラグ、フラグに応じたジャンプ

このスレ楽しいな。
けなしあいにならない議論が素敵だ。
6502vsSC/MPを思い出してしまった（ｗ

>>532
アキュムレータ(Acc) １個
命令１　Memory ← Acc - Memory
命令２　if(Acc < 0) then branch to Memory
だけで全てのことはできるような話を昔聞いたことがあったような気がする。

>>524
> 80286が発表され
> 二年も経ってから出された IBM PC/ATで「わざわざ」1MBの制限をIBMは
> 選択したのです。

コストと供給量考えたら、8088は1981年当時、
まさにそれしかありえない選択肢だったと思うが。

>>539
6502は抜群に速かった。
アップルとアタリはいつもベンチマーク最速。98さえ圧倒してた。
BASICが軽量だったこともあるが。
厨房の時、マイコン仲間で一番出来るヤシが
「6502は本当に組みにくい。Aレジスタ１本だけではきつい」と言っておった。
漏れはアドレッシングの考えは苦手で、
Z80に比べればスカスカの6502の命令表見ても理解できなかった。

>>541
>コストと供給量考えたら、8088は1981年当時、
>まさにそれしかありえない選択肢だったと思うが。

1981年のThePC発表当時は8086/8088しかなかったわけで1MBっていうのは
選択じゃなくて必然。

>>524の話は1984年、ThePC,PC/XTと互換を残しつつ、
大幅な拡張且つまったく新しい機能を携えて登場したPC/ATの話。

その一年後の1895年。80386が登場する（80286は1982年）。
まぁ、21世紀にもなってえらく目の肥えた僕等が、今の知識を元に20年も前の
技術を批判してもしょうがないんだけどね。

そういえば、80386がでてしばらく後、IntelのセカンドソーサだったAMDは
Intel80286の12MHzを大幅に上回る16MHz・20MHzの80286を押し出し
「80386なんかいらない」キャンペーンを展開してたのを思い出した。
ちょとわらた。

NECのV33も、16ビットで使うなら80386はいらない、と言ってたような。

しかし、V33はエグイCPUだったよ。
486同様に主要な命令をワイヤードロジックで実行するんだけど、キャッシュを積んでない!

キャッシュがないので、メモリアクセスをノーウェイトにしないと、本来の性能が出ない。
ところが、メモリアクセスが速すぎて、ノーウェイトにするには高速SRAMが必要という。

メインメモリを全部高速SRAMにする豪勢なマシンなんて、そうそう作れるわけもなく、
結局メモリウェイトによってV33は本来の性能を発揮することなく、ちょっと速いV30で終わってしまった。

>>531
512→514→526という流れを見れば、ネタ...というか皮肉以外の解釈はできないと思うが。
こーなんか417ってびみょーに変な人なんだよなぁ。
>506とかポカーンって感じだし

いや、皮肉にもなってないし。

有難うございます。勉強になります。

419って偏っているなぁ…主張は理解できるが古臭い組み込み屋の視点を前面に出しすぎじゃねーの。

>>548

どーかな。
旧RISC勢のコード効率の悪さがARMのThumbやSH等を読んだのだから
一概にどうこう言う事は出来ないと思うけど。

68kは16bitCPUで32bitCPUをエミュレーションしてるようなちょっと極端な
CISCだと思うし、複雑なアドレッシングモード等、アセンブラでは結局
使いこなせなかった人も多いのでは？？
レジスタが汎用だと言っても、その場その場で場当たり的に用途を決めてたら
混乱するのは当然で、r0〜1はテンポラリに使うとか自分なりに定石？を
持ってないとアセンブラではデバッグ等困難になってくる訳で…。

色々使って来たけど68kは楽だったよ。

アーケードゲームメーカーやWSがこぞって68K採用してる事実が
なによりも68Kの使いやすさを物語ってると思うが
セグメントは論外にしても86の汎用性のないレジスタとレジスタの少なさに
なかされたプログラマは多かったんじゃないかな

>>548

古臭い組み込み屋はZ80命でしょう。

>>551

WSがこぞってってのはど〜だろう？？
SUN1が68kってのは有名だけど、当時はNSやZ8000を採用した所もある。
UNIX系OSを移植するなら絶対的なメモリ空間の広さやCコンパイラの出来が
問題なのだから、当時の8086が力不足なのは当たり前だと思うのだがどうか？

>>552
Z80は好きだよ。
さすがに命令コード表は忘れてしまったけど。

>>551,553
ゲーム屋の事情は知らんが、WSメーカーは他に選択肢なかったしなあ。

ハイエンド応用には68kのほうが8086より向いているのは否定しないよ。
8086がハイエンドに向いていない→クソ、という評価に抵抗しているだけ。

オマエが68Kをクソといってるだけでダレも86をクソなんていってない
自分の過去ログ読み返してみろ

>>549
シンボルをレジスタに割り振る議事命令とかあったよ＜68kアセンブラ
まぁそんなのなくてもどのレジスタを何に使ってるかコメントに書いておけば大丈夫。

アドレッシングモードは豊富だったけど、直行性のある命令セットのおかげ
で複雑と感じたことはなかったな。

それよりもaレジスタとdレジスタに分かれているほうが煩雑だった。
この辺は直行性にかけるとも言う。
aレジスタは余ってたのに、dレジスタは足りないってことがあって少々
もったいなかった。

419は
「8086がクソ」という評価に抵抗しているのか「8086がハイエンドに向いていない」という
評価に抵抗しているのかはっきりさせろよ。

昔はアセンブラ言語でプログラムを書くケースも結構多かったし、コンパイラの
コード生成技術も未熟だったので、直交性とか重要だったけど、今や直交性なんて
無くたってコンパイラはちゃんとコード生成できるからな。

だいたいPentium Proあたりで、x86は名実ともにRISCを追い抜いたのかな？
これはPentium Proの設計の良さ(実行ステージはRISCと同じ)やIntelのプロセス
技術が当然効いているだろうけど、x86の非直交命令セットでもうまくコード生成が
できるようになった、というコンパイラ技術の進歩もあるような気がする。

>>558
「直交性がない」ってのは「方言がある」程度の意味でいいと思う。
それが酷くなければ「慣れちまえば関係ない」となる。でも、エンジニアを
育てるとか再利用とか考えるとクソと評価されても仕方がないな。

> x86の非直交命令セットでもうまくコード生成ができるようになった、という
> コンパイラ技術の進歩もあるような気がする。

これは古典的な技術で十分。

正直言ってレジスタが少ない&直交性がないってのはアセンブラレベルで
デバッグをする身にとっては「クソ」と言いたい。条件がちょっと変わるだけ
で同じようなロジックのアセンブラコードがコロコロ変わる。

誰もツッコミ入れないの？

>>542
>その一年後の1895年。80386が登場する（80286は1982年）。

(´-`).｡oO(1895年？)

>>560
このｽﾚではそんなわかりきったTYPOに突っ込みいれたり
自分の意見も添えられずにただ煽ったりするような奴は
子供しかいないから、一々反応してると恥ずかしい思い
するんで流すのがいいんだよ ^^

>558
PentiumPro の時代はまだ Alpha などと比べたらカスだった。
PIII vs. Athlon で 1GHz 競争とか言っていた辺りで整数系で互角くらいになったはず。

FP系は結局今は Itanium2 or Power が最強だから抜いたとは言えないだろ。
(性能を値段で割るってのは、なしね)

80186ってどこ行ったの？

なんか昔のPC板みたいな流れだな。

>>563
　8086と大差ない。人によっては8086のバグフィックス版、って言う人もいる。
かまってみたいならワンダースワンがお勧めさ。正確にはV30MZだけどね。

>>563
ちょっと前の一般向けルーターにも入ってたよ。

まぁ、CPUコアとして見ればそうだろうけどね。
周辺を内蔵してるのがイイ！訳だが、PCとの互換性なんてはなから考えてない
漢の設計(V50/V40もそうだが)が嫌われてPCでの採用例が無いってのが
不人気の理由だろうか？

Netgenesis DualあたりでAMD製？を見たりとか、最近でも高速化した互換品が
意外と使われている(x86のライセンス関係の事情もあるだろうけど)かも。

ttp://bb.watch.impress.co.jp/column/review/2003/09/10/

とかね〜。

80186系、PCでの採用例がないわけじゃないんだよね、それでも…。
国内でもFM16とか…コンパックもあった気が…HP-100LXもそうだね。

V30が186+αじゃなかった？

>569
V30は周辺なし。V50が周辺あり。という意味では8086/80186の関係に近いかと思う。

Intergraph社製のCLIPPERプロセッサを搭載したワークステーションが
あったが、オプションのDOS互換ボードに80186が載っていると
マニュアルに書いてあった。

>>567
まあ組込み用途向けだからな。
命令追加したのも、コードサイズを抑えるためだろう。

しかし、8080→8085みたいな流れだな。

手元に何かのボードからはずした80186が数個あるが、
そんなに多くのボードをばらした記憶も無いので
結構使われていたんじゃないかな？

アセンブラ使うと186命令は重宝した。多ビットシフトとか定数乗算とか。
186命令を使っていたせいでJ3100で動かなかったソフトがあった。

V50といえばNECのPC98系で
採用されてた記憶が……と、ぐぐってみたら
PC9801シリーズとは微妙に違う
HANDY98だったか。

98完全互換で無かった所為か全然売れてなかった希ガス
生まれるには早過ぎたポータブルか。

186命令懐かしいな…
PC98のソフトで186命令を使用しているのでV30以上でないと動かないってあったよね。

V30は186命令取り込んでいて、故にPC-98系では186を使った機種がなく、
故に>>567のような感想（採用例なし）になったりする訳ですね。
漏れも186と言えば16βくらいしか思い浮かばず、なんでかなーと
一瞬思ったわけですが。

PUSHA と POPA でちょっと感動した経験有り

68kのmovepみたいなもん？
あれはホントに感動だった。

>>579
関数の入り口で、

PUSH AX
PUSH BX
　　…

って書くところで

PUSHA

でレジスタ全待避してくれる。待避してくれなくてもいいレジスタまで
待避するから今は使わないだろうね・・・
っていうか、32bitで使えるかどうか知らない PTL

>>579
movemでは？
これを対スタックに限定した物ですな。

>>580
PUSHADという同機能の命令がありやんす。

１命令で退避しようとｎ命令使って退避しようと、Pentium4だと複数のμOPに分解されて
トレースキャッシュに格納されるでしょうから、実行時間は全然変わらないのでしょうね。
x86は【互換性命】 だから、こんな命令が多いのでしょうね。

まぁコード効率は上がるし＜582
もともとのPUSHAだって何サイクルもかかるから、実行時間が変わらなくても
べつにかまわんともいう。

>>582
>>582
トレースキャッシュに格納される命令は数μOPからなる簡単な命令だけで、
複雑な命令はトレースキャッシュには格納されずマイクロコードROMから
チンタラとμOPが発行されます。

http://www.intel.co.jp/jp/developer/technology/itj/2001/q12001/articles/p05_microarchitecture.htm
> 複雑な命令が現れると、トレース・キャッシュからマイクロコード ROM に処理が移り、
> 演算の実行に必要な μop はマイクロコード ROM が発行します。
> マイクロコード ROM による μop の発行が完了すると、プロセッサのフロント・エンドは
> 再びトレース・キャッシュから μop のフェッチを行います。

http://www.intel.co.jp/jp/developer/technology/itj/2002/volume06issue01/art01_hyper/p05_front_end.htm
> 複雑な命令が現れると、トレース・キャッシュはマイクロコード ROM に対してマイクロコード命令ポインタを送ります。
> するとマイクロコード ROM コントローラが必要なμop をフェッチして、再び制御をトレース・キャッシュに返します。

x87はいつ滅ぶんだろうなぁ・・・

486以降はPUSHAみたいな多機能命令は使わない方が速くなると聞いた事がある。
GCCでは386最適化を指定するとコードがコンパクトになる。

Pentium4最適化を指定するとPentiumPro向けと違ってrep movsとか使うよう
になっているみたいなんで、Pentium4以降は傾向が違って来てるかも。

x86命令をμOPにデコードするからなぁ。ICCが吐くコードとGCCが吐くコードの違いはそのあたりのチューニングでしょ？

>585
x86-64はx87非推奨

>586
最近のCPUはいくつかのストリング命令を特殊なモードで実行するらしいね

x87は時代遅れとかいってても実はｷﾁｶﾞｲなデコーダの所為で
SSE2 Scalarとほとんど実行速度は変わらないという事実。
まあレジスタが倍増した分の効果はあります。
アセンブリも人間が読めるようになったし。

意味もなくスタックアーキテクチャになってるのは罪だと思う

当時使えるトランジスタ数で安くすませるためにスタックアーキテクチャが採用されたそうです。

次に作る時はスタックは無くして欲しい。

>>592
その次が、IA-64のはずだったが・・・。

IA-64はスタックではないし、レジスタは128本。
単に128本と言うと大いに誤解があるけど・・・。

x64のFP計算は確かSSE推奨だよね。

>359
>アイピーフレックスのヤツかい？
>FPGA使いから見ると、ツールまだちと高いような。
>ASIC屋さんはどう見ているのかな？

最初は脅威に思ったが、まだまだ消費電力やチップサイズを考えると
ASICからとってかわる事は無いんじゃないかなと思う。
棲み分けが出来てASICは生き残るんじゃないかな。
または、ASICの中で柔軟性を持たせるところだけを
採用する事があるかも。

>593
IA-64のレジスタは基本的にスタックとしても使う（スタックじゃないものもあるけど）
スタックオーバーフローをOSが処理できるのでx87の時代より洗練されてる

>>593
しかし、そのIA-64は既存のx86との互換(ry

>359
>アイピーフレックスのヤツかい？
>FPGA使いから見ると、ツールまだちと高いような。
>ASIC屋さんはどう見ているのかな？

ツールが高いかは置いといて、
RTLを介さずにC言語から直接にコンフィグデータが作れるのと、
（動的な再配置）
ツール自体にかなりのノウハウがあるのではと考えられる。

>>590
使える命令フィールドがなかったらしい。
コード密度のためだね！

　スタックに積むのって、FPU積んでないCPUもあったからだと聞いてるけど。
FPU積んでないのは未実装命令例外かなんかでFPUをエミュレーション
してたんでしょ？。そうなるとスタック、というかメモリに積むしか方法が無い。
当時としては当然の方法だったと思われ。

>600は何か勘違いしてる希ガス

　？？、ってそうか。スタックを使用するアーキテクチャって事か。スマ・・・。

　その辺についてはあまりわからない。でも、みんなそうだった訳で、当時は
それが一番現実的だったんじゃないかな？とは思う。
プロセッサとメモリの動作速度の差が今ほど無かった頃の話だし。

　いまはメモリにアクセスするハメになったら負け、って感じだから、スタック
なんて言語道断、VLIWって形でCISC的高密度(?)命令を取り込む方向に
トレンドが移ってるのかな。まぁ今のアーキテクチャではレジスタをスタックに
退避なんてしてたら何クロックかかるのやら、って話もあるな。

　　って、あんま書くとボロが出そうだ。勘違い、話の腰折スマソ。

>>602
ここで言うスタックとはメモリスタックの事ではない。
レジスタの指定方法がスタック方式になっているということ。
http://www.nk.rim.or.jp/~jun/lxasm/asm11.html

携帯端末でデファクトになっている、ARMコアって
何がそんなに良いのかな？

>>604
ttp://www.atmarkit.co.jp/fpc/rensai/zunouhoudan015/whats_arm_01.html

>>604

最大のメリットは基本的にはIPでの提供だったと言う事。
携帯電話屋が自社の設計に取り込む為には必要な特徴だった。
当初ヨーロッパでちょうど良い処理能力を持ち、尚且つ入手性が良く
低消費電力なCPUはARMしか無かった…という事情も大きいらしい。

そして、IPでの提供だったという点が多くのベンダからの製品提供を呼び
それがコストダウンに繋がり、安価かつ多様な半導体製品が採用例を
増やし…以下ループ。

時代遅れになったら直ぐに製造を中止して実用的で格安な１Ｇ以上程度のＣＰＵを大量に作らないメーカーが最大の悪だとユタ州率大のマイケル教授は語った。

>>605の記事を書いた人
Massa POP Izumida氏の紹介が面白いぞ。
> 日本では数少ないx86プロセッサのアーキテクト。
> 某米国半導体メーカーで8bitと16bitの、
> 日本のベンチャー企業でx86互換プロセッサの設計に従事する。
> その後、出版社の半導体事業部を経て、
> 現在は某半導体メーカーでRISCプロセッサを中心とした開発を行っている。

Zilog→VMテクノロジー→ASCII→?
というバレバレの経歴。

>>608

最後が？じゃ「バレバレ」とは言えないべ。

>>603

　おーThx。知ったかぶりして書いて恥じ書いちゃった。x86命令ってあんま知らない
んだよね。昔x86アセンブラの解説書をちょと読んだだけです。

　なるほど、こんな面倒な構造をしてたのか・・・。こうしてみると、なるべくして
なったとはいえ、x86は命令アーキテクチャを変えたほうが将来の為になる
様な・・・。

>>610
既にSSE2命令が定義されています。
AMD64やEM64Tなど64bit環境では、x87ではなく、SSE2の使用が推奨されており、
スタックアーキテクチャとはお別れの方向の予定。

>>600
MC68000 でも、例外で飛ばしてエミュレーションしてたよ?だから別の理由だ
と思う。Inside Intel に、x87 のスタック方式は後悔してる、みたいな設計
者の話がのってたような気がするが、別の本かも。
昔はコンパイラの最適化技術がスタック用のが進んでいた、という話も聞いた。

ワロタ。
もっさりとしたCPUはどこのメーカー製ですか？
http://labs.nttrd.com/cgi-bin/index.cgi?m=q&q=%A4%E2%A4%C3%A4%B5%A4%EA%A4%C8%A4%B7%A4%BFCPU%A4%CF%A4%C9%A4%B3%A4%CE%A5%E1%A1%BC%A5%AB%A1%BC%C0%BD%A4%C7%A4%B9%A4%AB%A1%A9

もうハンドアセンブルは無理ですかね･･･

>>610
まてよ、スタックアーキテクチャなのは x87 命令であって、
x86 の問題じゃない．．．

こゆのは無粋なツッコミとして処理されるのかな

x87も広義のx86に含まれるということで。

んじゃ、ついでに SSE2 も広義の x86 に含めてｸﾚ

>>617
おｋ
でも「標準」の浮動小数点演算命令はx87命令のままだけどな。
AMD64ではSSEが標準といっていいだろうけど。

x87がスタック式なのは、コードサイズ（＝メインメモリ使用量）をケチるためと予想してみる

スタック式によって回路規模を小さくできた
と何かで読んだ。

80287持ってた。
浮動小数点演算使った月の満ち欠けの計算を
486SX/33と80286/12+80287で動かしたら、
後者の方が断然速くてびっくりした。

>621
たしか486SXって浮動小数点演算ユニットが殺してあるんじゃなかったっけ？

そして、i487を買わせて2重に儲けるという仕組み。
しかも、ODPが出て悔しい思いをさせるという、憎さ。

>>622
487を差すと、486SXは殺されて代わりに487がCPUとして動き出すという仕組み
でしたね。集積技術がこの頃はかなり上がって、FPUを内蔵してしまった方が
速度が上がったからでしょう。私は初めから486DXだった年代ですけど、すぐに
速度に不満が出て486DX2を差しました。

これはFSB : コアクロック=1 : 2 という可愛いものでしたが、今では 1 : 10 とか
平気でやってますよね。その代わりL2キャッシュを大容量化してできるだけ
レイテンシを隠蔽してますが。Dual Channelメモリにしたり、コアから見たメモリ
バンド幅の復権に現在は力が入れられているようです。

幅よりレイテンシが大きいな

所詮最後はバンド幅

486のキャッシュは(一部を除いて)ライトスルーだから、
クロックの倍率を上げても性能が伸びないんだよね。

同じFSBで、2倍、3倍、4倍、6倍を試したけど、3倍以上は体感速度が変らなかった。

486 に FSB/BSB があるのか。

まあ、K8 の HTL が FSB とか呼ばれるような時代だしな

BX時代まではベースクロック＝FSB＝メモリクロックと勘違いしてたヤツも珍しくなかったしね。

815の頃からメモリクロックは非同期も当たり前になったが
今でもベースクロック＝FSBと考えてるやつは珍しくない。

そういうヤツはFSBという言葉の意味とか、あまり深く考えないタイプなんだろうなと思う。

BX か、よい響きだ。

モーリス・ウィルクス賞のCall for Nominationがきたが
欲しい人いる？

>>629
おまいもあまり考えていないように「見える」が。

ど素人でごめんなさい。今勉強中の身です。
気になったことがあるので教えて下さい！
CPUアーキテクチャが異なると同じMacintoshでも互いのプログラムは本来動きませんよね？
でも、Apple社は1994年にCISCからRISCに変更してこの２つの異なるアーキテクチャマシンを同時に販売していたように思います。
Apple社はどのようにしてこの問題に対処したのですか？
教えて下さい！お願いします！

>>629
EDO DRAMまでは普通に非同期だった
SDRAMになってから、ようやくFSB＝メモリクロックとなったわけだが(シンクロナスだからな)
そのときは既にCPUクロック≠FSBだった。あと長い間FSB＝メモリクロックだったのは
Intel系のチップセットで、VIAなんかはPC133が出る頃にはFSB≠メモリクロック
だった気がする。

>>633
68kからPowerPCだっけ？OSがエミュレートしていたと思ったが？
どっちにしてもx86では無いですな…MACはさっぱりワカラン

エミュだとは聞いたが・・・
結果動かないのも出てきて、
古くからのマックファンが離脱する理由の１つとかも聞いた。
本当のところはしらんが。

>>633
680x0からPowerPCへの移行はエミュレーションで行った。
しかしエミュレーションの出来はそんなによくなかった。
Appleは性能向上のためには、互換性を大きく犠牲にするメーカー。
それでもMacを支持し続けるユーザーは、よほど好きなのか、単なる馬鹿なのか。

>>637
単なるバカだと思う。
持っているだけでうっとりしているような。

>>637
性能向上以外でも機能追加のたびに互換性がなくなっていたりもするし
あの会社には互換性を維持する考えが、これっぽちもないんだろうね

>>639
それはItaniumのことか？

　MACユーザーではないが、ある程度は仕方が無いんじゃないかと思う。


　68k系MACからPowerMACへはエミュレーション。ただ、エミュの出来が悪いと
いうか、エミュムログラムがPPC???（最初に出た奴。なんだったか忘れた）の
キャッシュ容量に徹底的に最適化されていたから、その後出た
603（キャッシュが半分）搭載のMACではぜんぜん性能が出なかったらしい。
で、キャッシュ倍増のPPC603eとか言うのが出たって話。（識者詳細PLZ）


　どこかでダイエットしなくてはならないわけで、そのサイクルの問題だと
思う。MACの場合宗教的、選民的思想を持っているユーザーも少なくない、
つまり「MACでは」許される行為だと思う。

>>640
速度はともあれ、Itaniumは互換性を維持してたよ。
ソフトウェアによるエミュレーションではなく、
ハードウェアによるエミュレーションなのだから。

命令セットを変えちゃった、という点では互換性は維持してないけど、それはx64でも同じこと。

Itaniumで、MS-DOSが動いた時には、その無意味な努力に感動しちゃったよ。
もう、MS-DOSなんて動かなくてもいいのに・・・。

>>642
そこまでされると、逆になあ。
一度ぶっこわして０から新しいアーキテクチャにしてくれと言いたくなる

>>637
Sunも68k(〜Sun3)→SPARC(Sun4〜)と「互換性を大きく犠牲」にしたわけだが。
Sunユーザもアホですか？宗教的選民的思想の持ち主ですか？

>>644
それでもサンはすばらしい！
とか言っちゃう香具師はアホじゃないの？

>>644
知らんかったのか？ Sunもたいがい互換性無視な会社だぜ
CPU変更以外にもSunOS 1.x→Solaris 2.xへの強引な移行
Javaのバージョンアップ時の非互換なんてのは結構酷い

winユーザーだからよくワカランがwinはバイナリ配布が当たり前だけど
Sun とかそこら辺はソース配布もしていて互換を重視するぐらいだったら
パフォーマンスを重視して再コンパイルした方が良いって感じだったんじゃないの？

unix WS だってバイナリ互換は重要ですよ。
特に商用ソフトなんかが絡むと基本的にバイナリだし。
OS も商用のやつはソース配布じゃないでしょ。

まあ windows よりも "なんとか乗りきる" ユーザーが多いのは事実だが。

>>628
だね。

FSB:バックサイドバス＝二次キャッシュ専用のローカルバスに対比する、
　フロントサイドバス。
チップセット経由で二次キャッシュアクセスするという486では、
バックサイドバスなど実在しないからFSBという呼び方は不的確。

まあ、HTとメモリバスの二つしか持たないアスロン64でも、やはり
FSBという呼び方そのものが現実離れか。

フロントサイドバスは、CPUとチップセットの間のデータ転送だったが
（二次キャッシュ内蔵タイプのCPUでは）...

バックサイドバスを持たなかったPPC604は、それゆえに、
本来の性能と搭載機（Mac）の性能がかけ離れて不幸だった。
アポーが、CPUボード側に二次キャッシュを積んでやってたら、
G3＞604なんて性能にならなかったろうに。
（PPCはスレ違いだけど。スマン。）

>>633
>>635 の言うとおり、
MacOSの内部に、68kエミュレータを積んでたわけ。
いちおう、68kエミュ自体は、PPCの二次キャッシュに収まってしまう程度のサイズだったが、
どうしても速度低下は避けられなかったため、
エミュレーションが必要な動作に限っては、
「68kと同等の速度を発揮するためには、２〜３倍のクロックのPPCが必須」
だった。つまり、PPCの高速性を活かすには、PPCネイティブのアプリが不可欠だった。

当初は、MacOS本体ですら、内部の大半が68kコードで書かれていたようで、
OS本体ですらエミュ上で動作していた。

完全にPPCネイティブになったのは、MacOSXが最初。
もっとも、最高クロックの68kに比べて3倍以上のクロックを持つPPCが
わりと早くに普及したため、
「PPCより、古い68kの方が速い」という逆転現象はすぐに（数年で）解消した。

互換性問題は、わりと多発してはいる。
MacOS7世代になるときにも、互換性問題はあったし。
ま、Winでも、ノートンやら、MacDrive（マイナーなアプリだが）やら、
一部の特殊なアプリに限っては互換性問題がよく起きたものだったが。

Winにおける16ビットコード残留問題と、
Macにおける、68kコード残留問題は、
質的な差はあんまりないと思う。
どっちも解決に要した時間が長すぎることも含めて。

>>641
最初のPPCは601。
マイクロアーキテクチャの世代が486に近い(?)
命令／データ混在の32kbの1次キャッシュを持ち、バックサイドバスはない。
コアクロックと外部クロックの比は2〜3倍程度。

次の603は、キャッシュ容量が小さいことや
消費電力低減機構を持つこと以外は、601と大差がない。
1次キャッシュが、命令・データそれぞれに8kbずつとなったこと、
実行ユニットのうち、整数演算部分とメモリ制御部分が
分離されたことぐらいの違い。かな。

が、データキャッシュとして使えるサイズが、601と比べて格段に小さくなったのが弱点か。

なお、601や603搭載のMacは、大多数が2次キャッシュを持たなかった。
特に、603搭載型では、2次キャッシュをオプションとしてすら用意しない機種が主流で、
あまりにも冷遇されすぎていた。

いちおう、Pentiumなみの世代と思うんだけどなあ。

604：命令実行の並列度では、PentiumProよりは
アスロンに近いと思う。
ただ、内部構成が複雑すぎてクロック向上に手間取ったか。
68040と同様の苦労に陥ったかも？
初期モデルでは、命令・データとも16kbずつだったが、
68kエミュの動作速度を考えたか、すぐに32kbずつに拡張された。

はじめてバックサイドバスを持ったPPC G3が出るまで、
アポーはCPUボードに2次キャッシュを載せず、
チップセット経由(?)での2次キャッシュにこだわり続けた。
MacのCPUバスが最大でも50MHzにとどまっていたうえ、
メインメモリがFP-DRAM止まりだったため、
メモリアクセスの遅さゆえ、CPU性能が遊び続けていた。
603＋バックサイドバスにすぎなかったG3で、
命令の並列実行度が非常に高いはずの604を大きく上回る性能が出た原因は、
アポーの設計の稚拙さにすべての原因があった。

しかし、この状況を見た設計者が、
604ベースのG3プロセッサを撤回してしまったため、
並列実効性能の高いタイプのPPCは大きく先送りされることとなった。

>>642
いっそ、「互換性はCMSを使って維持」にとどめたってヨサゲ。
（インテル製品ではないけど＞CMS）
互換性維持のための労力が過剰だったから普及が遅れてるんでは？

>>653
まぁ、互換性がある商品を出しつづけてるから売れてるPentium系がある訳で。
実際の所、過剰なまでの互換性維持にこだわってるのはMSだろう…
ttp://www.radiumsoftware.com/0406.html#040624

>>654
これは知らんかった…。ま、こんなことをしているから重く大きくなるわけだが。

>653
いまはIA32-LEをつかってソフトウエアでエミュレーション
する方向に向かってるよ

>>654
互換性は大切でしょう。
IA-64がコケたのは、リリースが遅れることにより、
MercedのIA-32の実行速度が同時期のPentium!!!に並べなかったこと。

広義の互換性には、ユーザが何のデメリットもなく移行できること、というのも含まれると思う。

>>646
>知らんかったのか？ Sunもたいがい互換性無視な会社だぜ
んなことはどうでもよくて、聞きたいのはこっち。
＞ Sunユーザもアホですか？宗教的選民的思想の持ち主ですか？

>641でいうところの「(宗教的選民的思想の持ち主であるところの)MACでは許された行為」
はその遥か前にSunがやっていたことなのだがねぇ。
Sunのユーザも同じように「宗教的選民的思想の持ち主」であったか聞いてみたいわけよ？

>CPU変更以外にもSunOS 1.x→Solaris 2.xへの強引な移行
強引ってほどじゃないでそ。Solarisが2.5.1か2.6ぐらいになるまでは
平気でSunOS4.xつかっている連中は山のようにいたし、OSも出荷されていた。
Solaris2.xへの移行ガイドもまめに作っていたし、ツールも用意していた。

おまけにSolaris2.xでもSunOS4.xバイナリはふつーに動くしな。
＃おかげでうちのサイトではSolaris9でSunOS4.0.3時代にコンパイルした
＃NEmacsやらkterm 3.xやらがそのまま動いてたりする(w

まぁさすがに68kバイナリはSPARCでは動かないわけだが。

ＩSAの互換性とAPIの互換性をごっちゃにしちゃいかんだろう。

Win32APIが糞な事とプログラマが馬鹿な事がIA-64への移行の
障害になっていると考えられなくもないんだけどね。

Win16→Win32で苦労したはずなのにその経験が無駄になって
いるとも言えるよなぁ…

>>659
では具体例をあげてみてください。

>>660
タダで安易に有用なデータが得られると思うなヴォケ。
自分でぐぐれ。このクレクレ厨が。

>>656
しかし初めからソフトでx86互換にする予定じゃなかったからIA32-ELはOS付属にするしかない罠
でアポーと違ってIA-64CPUはIA32-ELがないOSでもとりあえずx86動くように
もうほとんど使わないx86ハード切れない悪寒
盲腸としてこれからもかなり残るっぽい
互換性より性能とったはずのIA-64に早くもお荷物がｗ

>>657
いっそのことMercedキャンセルしてMcKinley（←スペルあってる？）勝負の方が
「IA-64は遅い」「期待外れ」とかの悪いイメージつかなかったような

>>661
いや、なんか出任せっぽいと思って

今更ながら >>654 のリンク先を読んだ。simcityのバグを回避するコードを埋め込んでまで
互換性を重視したというのはビックリした。

>>662
いっそBIOSに潜り込ませてしまったら？＞IA32-EL
んで、必要ならOS側で、より良いエミュに置き換えて使う。

Mercedは本当に短命だったね。

当初の量産出荷の予定が1999年だったのに、
1999年にはサンプルしか出ず、
ようやく発表されたのが2001年の5月末。

そして、McKinleyが2002年4月末に発表され、7月上旬には量産出荷開始。
同月下旬にはMerced搭載機がどこかで廃棄処分になり、
ジャンク屋の店頭に並んだのを2ちゃんねらーが捕獲。

Mercedを発表してから11ヶ月でMcKinleyを発表だもんな。
しかも、クロックが速いとかバスが速いというだけでなく、演算ユニット数が違う。
もちろん、コンパイラの最適化コードも違う。
McKinley以降は演算ユニット数など内部構造には手をつけてないから、
なおさらMercedはプロトタイプ臭いよね。

Itanium、Itanium2はVLIWだと言われている。Intelもそう言っている。
しかし、とうとう鯖メーカーはItaniumを使うのをやめだしたようだ。

ttp://www.geocities.co.jp/SiliconValley-Cupertino/6209/wadai04/20040925.htm

そんなにx86-64にこだわるんですかぁ？って感じ。

>>650
> Winにおける16ビットコード残留問題と、
> Macにおける、68kコード残留問題は、
> 質的な差はあんまりないと思う。
> どっちも解決に要した時間が長すぎることも含めて。

そうかな?
それに、Win3.1 -> Win95 ではメモリー管理やプロセス管理が大幅に改善された。
Mac では 68k -> PPC では基本的に CPU が変わっただけだし。
Win における 16bit コードは一応ネイティブだしね。
当時 Office アプリのベンチで Mac と Win95 では数倍速度差があった。
MS Office はおろか、Loutus、クラリスのも含めて。

>>668
ちょっと文意が不明。
Itanium、Itanium2 は VLIW なのはまちがいないよ。

VLIWとはいってもItaniumは変わり種。
もしかしたらVLIWの定義からはずれるかも。

>>669
> >>650
> > Winにおける16ビットコード残留問題と、
> > Macにおける、68kコード残留問題は、
> > 質的な差はあんまりないと思う。
> > どっちも解決に要した時間が長すぎることも含めて。

WinNT は Win95 より前に発売されていたね。

>>671
VLIW の定義とは?
一つの WORD に 沢山の命令を並べるって点で VLIW してるんじゃ?
バンドルって概念を使ったら VLIW じゃなくなるとでも?

>>667
それ俺だ。

むしゃくしゃして買った。
64ビットなら何でもよかった
今は後悔している

初代Itaniumがヤバい代物だとは承知してたけど、
どれくらいヤバいのか経験してみたかったんだ。
もう飽きたので暖房として使ってます。はい。

EPICは純粋なVLIWとはかなり違うかと。。
VLIWは、超長命令語（IA-64でいうバンドル）内に格納できる命令の種類(FP Int etc.)と位置が固定されいまつ。
EPICは、バンドル内に多種の命令の組み合わせが存在できまつ。といっても完全に自由ではないけど。
それから、EPICは複数のバンドルをスーパースカラ的に実行できる拡張性ももっていまつ。

うわっ、IPFの話が続いてたんでItaniumスレと間違えますた（ ノ∀ノ）

>>668
>Itanium、Itanium2はVLIWだと言われている。Intelもそう言っている。
VLIWだろ。それにだ、仮にVLIWじゃないとしても、

>しかし、とうとう鯖メーカーはItaniumを使うのをやめだしたようだ。
の理由にはならないだろ？
鯖メーカがどのCPUを使うか判断する基準が
VLIWか否かだとでも云いたいのか・・・

>>675
それを言うなら「純粋なVLIW」なんて存在しないといえるかも。
適当に空きスロットを詰めてやる機構が無いとコード効率悪くてしょうがないからなぁ＜VLIW
バスやキャッシュも無駄に食いつぶされちゃうしね。

いまどきのVLIW(…といってもEPICとFRVしかしらんが)ではごくごく当たり前の機構だよ＜空きスロットを詰める

>>668
そうそう。
x86-64 = AMD64 ≠ EPIC な。

>679
>668 がゆんゆんしてると思ったらそんな勘違いをしていたのか!?

>>668
お前にこのスレは早すぎたようだ。
1年ROMってろ。

>>658
おっと失礼。方向の違うレス返してたんだな

で、俺の認識でしかないけど、好んでSun使ってマンセーしてる奴はやっぱ
どこかおかしいと思う。とくにマクネリが好きなんていったら相当やばいだろう。
ただパソコンとちがってサーバ/WS系だから、好きで使ってるわけではない、
他に選択肢がなかったという理由でSunユーザになってる奴のほうが大多数だろう。
なのでバカばっかりではないと思われる。

>>677
>>しかし、とうとう鯖メーカーはItaniumを使うのをやめだしたようだ。
>の理由にはならないだろ？

別に理由にはしてません。しかしは、独立語のつもりで使いました。前の文に
係っているわけではない。

>>681
お前に命令される筋合いはない。

>>682
>で、俺の認識でしかないけど、好んでSun使ってマンセーしてる奴はやっぱ
>どこかおかしいと思う。とくにマクネリが好きなんていったら相当やばいだろう。
あっち方面のマンセーは会社でなくて人につくから。

>ただパソコンとちがってサーバ/WS系だから、好きで使ってるわけではない、
>他に選択肢がなかったという理由でSunユーザになってる奴のほうが大多数だろう。
>なのでバカばっかりではないと思われる。
そういう環境でもCPU変更というアーキテクチャ変更は可能なのだから、
CPU変更という大規模なアーキテクチャ変更が可能かどうかは信者イパーイかどうかと関係ない。
Macが特別なんてことはまったくない(＝>641の否定)

ということでオーケー？

>683たん
x86-64 ≠ Itanium
ってのは理解してくれたかな？

>>685
当然理解してます。というかItanium鯖も触ってます。
Itaniumは内部にx86エミュレーション機能を内蔵してますが(80386以降の
仮想86モードのような感じ)、P4になってからのいくつかの重要な命令を
サポートしてないのと、エミュレーション速度も遅いのとで、ネイティブでしか
使われてないようです。

VLIWという事でコンパイラも複雑に高価になりがちだし、Itanium(2)も発熱量
がすごく大きく単価も高いのでなかなか拡がらなかったようですね。

その点x86-64はレジスタが大幅に増えたものの基本的な命令セットはx86と
よく似ており、PUSH/POP命令をREXプリフィックスに置き換えた以外はその
まま使えるので(とは言うもののレジスタが増えたのでメモリ-レジスタ間のmove
はかなり減ると思う)コンパイラ作成者にとっても楽なんでしょう。Athlon64なら
単価も大幅に安いし。

>>684
当時のSUNの場合はリコンパイルすればOK、全く問題なしって文化だからな
コンパイルもできないような奴がSUNを使ってるわけがない時代だったし

なのでSUNがそういう状況だったからという理由で、
Appleの場合もそうではないとはいえないと思うぞ

>>687
あー、要するに信者多いとか関係ないぢゃん。っていいたいだけ。
Macの話をすると必ずMacは特別って言いたがる奴が出てくるんで。
それってどうなのよと。

どうも件の人そういう過去に行われたCPU変更例を知らないようだし。
WS界ではあの時期に大体のマシンが68k→RISCっていう変化を経験しているんだけどね。

>>686
てーことは>668は全部の行がそれぞれまったく関係ないってことなのか？
そりゃいくらなんでも支離滅裂だろう。

やっぱり>681だな。

>>689
だから貴様のようなどこの馬の骨とも知れない香具師に命令される筋合い(ry

IA-64の性能がブッチギリに良ければ、色々我慢して使うんだけどねぇ。

恐れながら私も>>668の文意が未だに読みとれないのですが…（ ノ∀ノ）
できれば、もう一度わかりやすく書き直して欲しいでつ。
それから、IntelがIA-64がVLIWって公言してたことありましたっけ？

Itanium、Itanium2はVLIWだと言われている。Intelもそう言っている。
しかし、とうとう携帯に移植されたようだ。

http://www.itmedia.co.jp/mobile/articles/0409/24/news093.html

>>692
Intelのホームページを隅から隅まで探したまえ。もちろん本家の英語の方な。

http://www.intel.com/intelpress/chapter-scientific.pdf
ちょっと検索してみましたけど、EPICはRISCとVLIWのおいしいところをくっつけた
新しいアーキテクチャ、というのがIntelの主張みたいですが…。

ちなみに、私もItaniumはVLIWの延長上にある技術に基づいたアーキではあるが、
VLIWプロセッサではないと思っていまつ。
EPICと古典的VLIWには>>675にも書いた通り、大きな違いがありまつ。

>>695
誰も"古典的"VLIWとは言ってない。細かく突っ込みすぎでしつこいよ。

はいはい

痛ニウムのは、コンパイラの支援があって初めて
性能が出るものだっけ。
そういう意味でただのVLIWとは違うと。

>698
VLIWってコンパイラでの最適化を前提としたアーキテクチャだＹＯ

>>699
結局、痛ニウムとただのVLIWは同じってことか？

>700
普通のVLIWは、演算器とかの構成が変わるとバイナリの互換性が
無くなって、コンパイルしなおさなきゃいけないけど、Itaniumはバンドル
っていう概念を導入して世代間の互換性を維持できるようにした
改良型VLIW。

>>701
ﾌｰﾝ、んじゃ基本的なところは同じなのね
事前に最適化できるところはコンパイラがオペランドレベルで
埋め込んでしまえるとかってのを見たｷｵｰｸがあるような気がするが、俺の妄想か

> 事前に最適化できるところはコンパイラがオペランドレベルで
> 埋め込んでしまえるとかってのを見たｷｵｰｸがあるような気がするが、俺の妄想か

これと VLIW かどうかとどう関係するの?

VLIWかどうかじゃなくて、板にウムの特徴として
コンパイラと連携してそんな感じというのってこと

Itanium→Itanium2で演算ユニットの数が変わったけど、今後どうなるのかな。
いまのところ、マルチスレッド化で性能を稼ぐようだから、しばらくは変らない気がする。

+lgnGf9nが香ばしいな。
>>686
>Itaniumは内部にx86エミュレーション機能を内蔵してます。

エミュレーションじゃない。
偉そうな態度をとる前に用語は正しく使え。

>>706
そんな事どうでもいいじゃん。別に論文出そうとしているわけじゃないし。
所詮2chなんだし。君に用語は正しく使えなんて言われる筋合いはないよ。

>>706
つーか、はっきり言わせてもらうと君の態度の方がよっぽど偉そうだよ。
自分の納得しない意見は片っ端から排除するって雰囲気が伝わってくる。

> というかItanium鯖も触ってます。
というのが香ばしいんだよね。
触ってるから、なんだというの。
鼻にかけることではないよ。

CPUの中身なんて全く興味のないDB屋だってItanium2サーバいじってるよ。
エロゲー趣味の人だって、Itanium2ワークステーションいじってるよ。

>>709
香ばしいと受け取るのはそちらの勝手だが、それをネタに俺を誹謗中傷するのが
そもそも間違っている。削除依頼出そうか？

(´-`).｡ｏＯ(どこをどう読めば>>709が誹謗中傷に見えるのだろう?)

ま、削除依頼を出すならご自由にどうぞ。

(´-`).｡ｏＯ(どこをどう読めば>>709が誹謗中傷ではなく見えるのだろう?)

EPICとVLIWの違いについては
ttp://www.cs.clemson.edu/~mark/464/acmse_epic.pdf

>>710 >>712
だせぇよ。あんた。

Itaniumﾃﾞ鯖ﾔｲﾃ(ﾟдﾟ)ｳﾏｰ

>bTnFiFy5
大変恐縮ながら、もうレスを少し控えて頂ければ幸いです。

それはそうと、トランスメタはどうよ？
最近は結構搭載ラップトップも増えてきて、
私の周りでも使っている人が多いのだが。

>>bTnFiFy5
> 所詮2chなんだし。君に用語は正しく使えなんて言われる筋合いはないよ。

間違った情報を垂れ流して開き直るとは…厨房。もっと謙虚になれ。

藻前らどうでもいいから少しは便所行って頭冷やせ。腹は冷やすな。

>>718
録音、503クラスかもしれんから少しぐらい遊ばせてくれよ。

無知なやつに限ってプライド高いんだよな
プライドだけは高いから間違いを認められない

>>686
>PUSH/POP命令をREXプリフィックスに置き換えた
INC/DEC(0x4a-0x4f)の間違いだろ

今時、コンパイラの最適化前提で当然だと思う。

だいたい、VLIW て一度に沢山命令をﾌｪｯﾁして、実行して速度を上げようって
んだから、できるだけ上手いことバンドルに命令を詰め込まないと話になるわ
けない。

ｽｶｽｶで性能がでないとかそういう話でないの?

痛ニウムはますます遠い存在に
http://www.excite.co.jp/News/computers/20040927142303/JAPAN-158078-1_story.html

不思議なのがAH,ALはあるのに16ビット、32ビットだと上位と下位がないこと。
余ってる部分もったいないんだけどなんでこうなの？

>>724
Googleでパーシャルレジスタストールで検索してみな

>>725
それはP6以降の問題であって386開発時の32bit拡張とは関係ないと思われ。
単純に互換性をなくしてまで上位・下位で分けて半分の長さのレジスタを使う
メリットがないからでしょう。

例としては、
既存の32bit OSで64bitレジスタの上位半分の退避領域なんて存在しない。
32bitアプリケーションで16bitレジスタが倍の数使えたってうれしくない。
って感じですね。

>>726
P6ほど大きいペナルティではないが、
386でもパーシャルレジスタストールは起こるんだけど。
要はパーシャルレジスタアクセスに対応すると
処理が複雑になってしまう。

>>727
x86に触れたのはP5以降だから386で発生するとは知らんかったなぁ。
どっかにソースない？

> 要はパーシャルレジスタアクセスに対応すると
> 処理が複雑になってしまう。

複雑というより面倒な事はしたくないから待つってのが正しい解釈だと
思われる。

複数のレジスタとして使いたいわけじゃないんだけど、
上位16ビット分と下位16ビット分が別々なところにあって、
それをくっつけたいときに、シフトしてORするのが面倒だなぁ、と。

mov AL, [foo]
mov AH, [bar]
で済まさせてほしい。

って、いまさらアセンブラで書かないか。

>>729
コンパイラの中の小人さん? いつもお世話になってます

68kもワード以下のサイズはパーシャルライトだっけ。

>>729
DEC AlphaのようにBYTEもWORDもなかったことにすればいいのよ、ｵﾎﾎ

>>732
復活したけどな

>>725
テンポラリレジスタが使われてたんですね。たしかに
mov AH, AL
なんてのはどうやってるのかと不思議に思ったこともありましたが
そういうことだったのか。

ただ、それほど多くない回数のループを多重で作るときにレジスタ
足りなくて歯がゆいことってないですか

｜　　　△　　 ｜
｜　 〔(ﾟεﾟ)〕　　|　←>>709
(⌒⌒⌒⌒⌒⌒⌒)
｜⌒⌒⌒　＜⌒ヽ o ｡
｜　　　　　 ＜_　　ヽ｡
｜　　　　　　o とノ　ﾉつ
｜　　　　　　 ｡　| 〜つ

>>686が何も言えなくなってAA荒らしですかwww

>>734
あと１つ欲しいかなと思うことはあるが、あんまり気にしたことはない。

IA64 ならﾙｰﾌﾟ回し放題。ﾔｯﾎｰ!

何も言えなくて、夏

みんな意外とアセンブラ使ってプログラム書いてんだね
このスレの特殊性かもしれないけど　びっくり

>>740
コンパイラの出力とにらめっこはするが、直接アセンブラで書くことはあんまりないよ。

たまにインラインアセンブラ使うくらい。

>>740
まあ、なんだ、
アセンブラでどう表現されるかを意識してコードを書くと速かった時代があった（過去形）
i++より++iのほうがｲｲ!とかな。
今そんなことしても、100の労力で、0.00001の利益、100000の非保守性が手に入るだけ。
そういうわけで、現在進行形で書いてるやつはそうはいない

ただC++のテンプレートを駆使した場合とかコンパイラの出力を確認したくなる時もある
デバッグビルドすると全然インライン展開してくんなくてうぎゃーみたいな

キャリーフラグを使うと手っ取り早いこともちょくちょくある

インラインアセンブラを使うと最適化が阻害される場合があるので、
基本的には使わないな。
組み込みコントローラのしょぼいメーカー製コンパイラってそんなもん。
>>742
ところが組み込み現場だとそうも行かなくてなぁ(苦笑
ある程度コンパイラのコード出力の癖を知った上で書かなくてはならないことも
まだまだ多いよ。

コンパイラの出力コードをチェックしてない馬鹿がテンプレート使いまくって、
異様にオブジェクトサイズが大きくなって性能が低下したことがあったよ。

そいつは、関数の中でテンプレート使って一時的なクラスを作りまくるの。
文法的には合ってるけど、
各関数・スコープ毎に別個のオブジェクトが生成されてて無駄無駄無駄。

テンプレートをその場限りで使って良いのは、非常に軽い奴だけだって。

ごめん。スレの趣旨無視して、愚痴ってしまった。

CPU温度を最大限大きくするCコードってどんなコードでしょうか。
Pentium4プレスコットの評価をしていまして、
同じCPU100%でもコードによりCPU温度に差が出てきます。
そこでCPU温度を可能な限り上昇させるコードってどうなるのでしょうか。

>>748
FPUぶんまわし。
今だとSSE?

>>748
Cでやるのは難しい。
依存が無い演算を小さいループでメモリアクセスしないでひたすら
やらせるのがいいんだけど、最適化で処理をあぼーんされてしまうし
最適化しないと変数を毎回スタックにアクセスしに行くコードになって
しまう。

アセンブラで書け。

Cで十分。
演算結果を捨てないで次の演算で使うコードにすれば
コードが消されることなんか無いし、その状態でも
相互に依存関係の無い演算なんかいくらでも混ぜられるし。
スタックだって、L1にヒットしてればメモリアクセスのような
長い待ち時間は発生しないよ？
ツッコミどころはこんだけ？

そもそも演算性能が必要な処理は現在では Cで書くのが
事実上の標準なわけだから必要な物は Cで実現できるようになっている

良スレ！情報工の学生には参考になる内容だ・・・
まだ前半しか読んでないけどOTL

>>751
そう思うなら実際にそういうコードを書いてみてVTuneでも使ってみれば？
お前さんの考えがいかに甘いかわかるから。

どうでもいいが、キャッシュにアクセスしない方が本当に熱くなるのか？
RAMやCAMは電力食うぞ。

しかし温度を上げるだけなら、PWMレジスタを書き換えれば(ry

FP演算と整数演算を別スレッドで同時実行して、キャッシュを最大限使いつつもメモリアクセスは最小限、というコードが良いんだろう。たぶんね。

FPよりもSSE

>>748
Prescottの32bitだよね。SSE2/3を使って乗算器と加算器を
使い潰したいのでしたら、

double a[4], b[4], c[LEN];
for(i=0;i<LEN;i++) for(k=0;j<4;j++) a[k] += b[k] * c[i];

なんてどうでしょう？
必要なメモリバンドはっと、、、
1 loopに4 cycle、3.2GHｚのﾌﾟだと6.4GB/s　・・・＿|￣|○

a, bの長さを4から8にするとメモリバンドは半分ですんで
Loadユニットに負荷かかると思います。L1零点死おっきな
ﾌﾟでまともに回るかな、、、

誰かiccのコード晒してくれると嬉しいっす

>>758
変数修正＆ループ回数1024にしたやつ。
メモリアクセス大杉

LOOP:
movapd xmm0, xmm2
movddup xmm3, QWORD PTR [esp+eax*8]
mulpd xmm0, xmm3
mulpd xmm3, xmm
addpd xmm0, XMMWORD PTR [esp+8736]
addpd xmm3, XMMWORD PTR [esp+8752]
movapd XMMWORD PTR [esp+8736], xmm0
movapd XMMWORD PTR [esp+8752], xmm3
add eax, 1
cmp eax, 1024
jl LOOP

いまさらな感があるけどさ、
alphaAXPって、32bitか64bit境界のメモリアクセスじゃないと、性能が落ちるって言うけど
なんで？
例外に、ALIGNというのがあって、境界整列アクセスじゃ無いとこれが発生するかららしいけど、
別に、レジスタにメモリから、値を持ってくるだけなら、どのアドレスからはじめても
変わらなさそうだれけど。最適なアクセスを実現するのに、データアドレスが関係してくるのか
いまいち分からん。

アラインされて無いアドレスのデータは一回のメモリアクセスでアクセスできないから遅くなる
これはほぼすべてのプロセッサに当てはまる

>>760
Alphaのようなモダーンなプロセッサよりx86を引き合いにしたほうがいいと思うが。
＃そもそもアライメント不整合なアクセスはできんし。

アライメントを跨ぐアクセスをおこなうとメモリアクセスが2回発生するから遅い。
当然1回より2回の方が時間かかるよな。

課題：どうしてアクセスが2回発生するか考えて見ましょう。

>>761-762
レスありがとう。
自分が考えたのは、メモリからレジスタにデータを取って来るときの、アドレス指定が
例えば、32ビットの場合、4の倍数でしか指定できないように、回路が組まれている。
だから、境界をまたぐ時（アドレス2から5を読む時）は、アドレス０から４バイトを読んで、
上２バイトを生かし（このときトラップ発生）、次にアドレス4から4バイトを読んで、下2バイトを生かし、
で、最終的に、アドレス2から5までの4バイトのデータを得る。だから2回ということかな？
化石のようなVAXから持ってきたプログラムなんだから、CPUの性能差を考えれば、
alphaで最適処理でなくても、十分VAXより早いよと思ってはいるのだが、説明しろ。
という人が居るので、あれこれ調べてます。
#alphaももうミイラ化しているという話もあるけど。

>>759
あり、summationレジスタ内でとってくれない....OTL
俺の脳内コンパイラはこんなの吐いてたのね。

xorps xmm0. xmm0 #a[0] = a[1] = 0;
xorps xmm1, xmm1 # a[2] = a[3] = 0;
movapd xmm2, b[0]
movapd xmm3, b[2]
for(k=0;k<LEN;k++){
movddup xmm4, c[k]
movapd xmm5, xmm4
mulpd xmm4, xmm2
addpd xmm0, xmm4
mulpd xmm5, xmm3
addpd xmm1, xmm5
}
movapd a[0], xmm0
movapd a[1], xmm1

ループ内改良？
movapd xmm5, xmm3
{
movddup xmm4, c[k]
mulpd xmm5, xmm4
addpd xmm1, xmm5
mulpd xmm4, xmm2
addpd xmm0 xmm4
movapd xmm5, xmm3
}

なんつーか、最近のレスを読むとやっぱりCPUのアーキテクチャと
ソフトのトレンドは切り離せないって感じか
プログラミングのトレンドによって良いアーキテクチャってのは変わってくる？

変わらん。ここの住人が特殊なだけ

>>764
最適化レベル下げてある。
上げるとメモリアクセス減るけどunloop & �巴*cがb�把になる。
長いので貼れん。

>>765
何がプログラミングのトレンドで何が良いアーキテクチャだと思っているの？

ソフトとハードのトレンドは密接に関連してるよ。
CPUアーキテクチャは微妙だと思うけど。

>>763
一度のメモリアクセスで読めるのは、
アドレスバスが同一のメモリ領域だけ。
(バースト転送を使えば、その4倍ぐらい)

アラインメントがそろっていない＝アドレスバスの内容が違う複数アドレスにまたがったデータ。

原理的にどのようなアーキテクチャでも、
そういうメモリエリアを一度にまとめては読めない。

ただし、アーキテクチャによって、
4の倍数だったり8の倍数だったり2の倍数だったりすることはあるはず。

なお、pentium以後のCPUが一度に読めるメモリは8バイト。
8の倍数境界を越えなければ、
実は密かに1度のメモリアクセスでデータを読めたりする。(ハズ）

>>767
んー、例えばJAVAとか
JAVAのバイトコードが直接実行できるハードってあるじゃん
ARMのJazelleとか
んでJAVAの仮想マシンってスタックベースだし、命令に直交性ないし可変長だし
507辺りや590辺りで叩かれてるような仕様な訳で
ttp://www.netgene.co.jp/java/docs/javaPressVol15.html

ソフトとハードはちょっと流れが違うなーと思ってさ