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

前スレ
http://pc5.2ch.net/test/read.cgi/jisaku/1082357989/

2

前スレ >>1 より

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

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

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

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

ぺ４様

　　　　　　　　　　　　,.-t､,／ ＿￣~~`'ｰ- ､,　　(__
　　　　　　　　　　　　f　　,l. ￣r＜￣ ＞- ､　 ` く　 l,__
　　　　　　　　　　,.〜',／　`ｰ'‐'^ヽ,__j,.ィ_　nヽ　　＼　,.ﾞヽ
　　　　　　　　　/　／ ／　　　　　,.　　　 `y'　＼　　 ',　　）
　　　　　　　 　 ヽ//'／／ ／' ／ ,.　　 ﾉ　L._　 ヽ　　ト､ ,)
.　　　　　　　　　// / 'ﾑ ノ ／ ／'彡ｲｲ| ｲ　ﾉ fヽﾞ!　　|　'ー,
　　　　　　　　　l/l l　　〃 /／'　彡〃 |川.|.了ヽ__!|ヾ　|. ／{!
.　　　　　　　　　|从　//-く ム-彡'"二ﾞ!从ﾚ'　i |`ｰ`)ｰﾚ'　 _j　ポンポコ
　　　　　　r､r､　 |l V/' lr'｡!　　　　 'スヽ',从　,!└-- ｧ,r=,ｺﾞ 　　　　　ポーン♪
　　　　　ヾヽヽ＼.　nl　､lﾟｿ　　　　 /ｰ'｡ﾐY/ /　　ｱ / |_,ﾉ　　　　。 　　　　　　　　 　 　 |ヽ
　　　　　 ヾヽヽヽ'､{. ',　　 .:　　　　ゞﾆﾝ^'j. / ／/ノ,! ﾊ　　　ｰ┼‐　 ＿＿＿　ヽ　　　 ._|　）
　　　　　　 ＼＼^　`!ヾ､.　ヽ‐1 　 　 　 /./ノ　 /　l. ﾊ L,　　ﾉ | ヽ　　　　　　　_,ノ 　 （_|
　　　　　　　 ヽ　ヽ　　 }.ヽ,　!ﾉ　　　　　|/　　 ./　l　|-! | )
　　　　　　　 /.）　 　 ノ､ヽiゝ､､､--‐='７ ノ　 ,ﾉ"7-v'--'く
　　　　　　､'ｰ===i. /.　 ｽ､ ( f　 ﾊ.　 /　/ ／　/　　 ）　　＼
　　　　　 ／ヾ;､,_ゞ=＝ｲ ﾐ 〈{ 7ｲ. | ./　 ／ ）　l　r‐'"　　　　 ヽ
.　　　　 /　　 `ー'　 |〈　＼ | |. |　|. |　/,ノ　〉 |　_j　　　　　　　レ┐
　　　　/　　　　　　,ｲ,〈 ミ､ ﾞK､j ,. l | ／ノ　 Ｖメ、　　　　　　ノ-　,ゝ
　　　 /　　　　　／）>L>､　｛､7ﾞ,､j y'　　/　く.(　)ヽ,　　　　「　　_ﾉ､_
　 　 （　　　　　　ノ　／＼ヽ〈ヽ,).l　}　　 ／/ノ　　 ヽ　＿∧,r‐'　　　`ヽ、

結局>>1じゃx86をマンセーしてるだけなのがイタいんすけど。。。

上の>>1じゃなくて>>3すか。。。

マックおた、きもいよ。

フリップフラップ直さなかったのか。
しかし今日のMAXオタ必死だな。

なんかここだけ板で浮いてるな
エロくない私にはさっぱり内容がわかんね・・・

>>前スレ911
32bit固定命令長プロセッサでは大抵32レジスタ3オペランド(5bitx3=15bit)
16bit固定命令長プロセッサでは大抵16レジスタ2オペランド(4bitx2=8bit)
どちらも命令長の約半分がオペランドを指定するフィールドで占められているが
その辺何か意味があるのかもしれない。

遅いとバカにされるけどSPARCが大好きです♪

前スレ前半はSPARC信者が多かった。
が、後半からは何故かx86マンセー野郎が増加して、
さらにMACオタが乱入。

そして、レジスタ数とレジスタ待避のトレードオフという素人には
無謀すぎる話題に突入。

で、MACオタはx86 ISAのスケーラビリティの悪さについては
どうおもってるわけよ？

>>14
ISA的にわ、ついこないだまで64-bitアドレスをサポートしていなかったという以外、別に問題
無いと思うす。ただ、実装自体わ携帯電話に入るような小さなチップも無く、サーバー用の
ハイエンドチップも無いというのが事実す。

前スレの後半見てて思ったけど、
レジスタがありすぎるとコンパイルに時間かかりそう．．

＃最近、Power5に興味もってきたりして．．(^^;

>>11

>16bit固定命令長プロセッサでは大抵16レジスタ2オペランド(4bitx2=8bit)

そうか？　ARMやMIPSの16bitISAでは8レジスタ3オペランド(3bitx3=9bit)だぞ。

まぁ、いずれにせよレジスタ指定に割り当てられるビット数はその程度が
妥当だろうね。もっとも、思い切ってイミディエイトやディスプレイスメントの
ビット数を削ってしまえば多レジスタISAというのも可能ではある。
例えば128本3オペランド(7bitx3=21bit)なんていうCPUも過去にはあった。
まぁ、自分で命令ビットパターンを考えてみるのもなかなか面白いものではあるよ。

>>16
>レジスタがありすぎるとコンパイルに時間かかりそう．．
すべてのコンパイラに該当するものではありませんが
GCCでは擬似レジスタが無限にあるものと想定して
コード生成をした後現実のレジスタ，メモリ参照に
変換するという手法をとっていたようなので
レジスタ数が多いことはコンパイラに対して
デメリットにはならないのでは。

>>17
>例えば128本3オペランド(7bitx3=21bit)なんていうCPUも過去にはあった。
Itaniumって既に過去のものなのか......orz

>>17
そういえばそうですね。
こちらは32bitMCUの類のネイティブな命令セットをを想定していました＜16x2
使い勝手としては16x2のほうが8x3よりよいかと思います。
＃8x3のISAはどちらも32bit長命令セットの縮小命令セットであるのは注目すべきでしょう。

>>18

Itaniumって32bit命令長だったんだぁ。
# VLIWは全く頭になかったよ。

>>19

確かに8x3は32bitの縮小ですね。
実はMIPS16の命令セットを決めた人間に話を聞いたことがある。
色々と理屈は言っていたが、結局は勘で決めているとしか見えなかったよ。

>>20
Itaniumの命令長は41bit長×3＋付加情報5bit=128bitです。

>>17が過去に32bit命令長で128レジスタのCPUがあったという
ことでしたらこちらの早とちりです。

>>21

ご丁寧にすいません。
17で「32bit命令長」って明記しなかった私が悪うございました。
Itaniumのスロットが41bitというのは確認してたのですが、
20ではちょっと遊んでボケてみました。申し訳ないです。
ちなみに、17で書いたのはAm29000のことです。

Am29000はオペコード、オペランド3つそれぞれ8bitです。
レジスタは192個まで実装されてたんだったかな。

>>23

ガーン、完全に記憶違いでした。ありがとうございます。
少し休養します。

877 名前：名無しさん必死だな[] 投稿日：04/11/27 12:50:53 ID:nmcyavCi
日本は猿マネでここまで来たんだよ。結局はアメリカ西洋が無いと
何も出来ないのはペリーが来た頃からわかってただろ。

加工は得意だが発想が無いんだよ。今じゃ製造関係の信用すら無くなった。
今までやってきた事も結局はまねごとじゃん。
コンピューターって物を開発した訳でも無く、コンピューターって物を
遊びに使ったって事で当たっただけであってさ

あっちの評価が上がったのは軍事関係にコンピューターを使ってるから
技術が上がればもの凄い物は作れるんだよ。日本はそれを加工しただけ

インテルのCPUの産みの親は、日本人ですが、何か。

インテルの起源は韓国にあり。。。プギャーっと

中森章は半可通なので判っていないのはいいとして
http://www.cqpub.co.jp/intrface/toku/2003/200311/toku2.htm
嶋正利まで
「ただ，IBM の失敗は自分の成功に価値を見いださなかったことである．」
なんてことを言っているので失望した。
http://www.ieice.org/jpn/books/kaishikiji/199910/19991001.html

実際はIBMはRISC技術を極めて重要視していたわけだが。
http://www.cs.clemson.edu/~mark/architects.html

IBMみたいな超大企業の場合、重要視といっても、本当に重要視されていたのか
わからない見たいな部分があって…。いかんせん重役の数が多すぎて…(笑)

かなり早い時期に手を出していたのは確かだけど結局日の目は見なかったわけで。
持ってるリソースが大きいので片手までやった仕事でもたいした仕事だったというだけの話だと思うね。

>>30
中森章登場

>>28
おせっかいかもしれんが

http://www.cqpub.co.jp/interface/toku/2003/200311/toku2.htm
中森の記事は↑こっちだな。interfaceのeが抜けてる。

この記事は以前本で読んだが、
「紙面が尽きた」とか言ってSHシリーズの文章がなかったのが、
個人的には腑に落ちなかった。

今でこそARMがRISCマイコンの最大勢力かもしれんが、
数年前なら「世界でいちばん売れている32ビットマイコン」とも言われていたらしいSHシリーズ。
何か書けることもあっただろうに…

誰かSHシリーズについて熱い想いを語ってくれる人ｷﾎﾞﾝﾇ

>>32
きちんと評価したわけではないが、あんまり好きではない。

>>32

HOTCHIPSか何かで日立が発表したとき、パターソンが
「そいつの何処がRISCな訳？」と突っ込んだってな逸話は有名だな。
確かに純粋RISCの立場からすれば、16bitに圧縮されたコードセットは
邪道でRISCとは言い切れないだろうよ。
だが、その後SparkやMIPSが追従した訳で、受け入れられた訳だが。

そしてセガと共に滅んだ…じゃなくて、結局、現ルネサスもそうだが
SHとH8の棲み分けでかなり悩んでるんだろうな。
さっさとH8を縮小してSHに一本化してた方が良かったと思うんだがねぇ…。

>>32
中森たんはNの人間だから。
Hのプロセッサの話はあまり詳しくないからできなかったというところでないかな。
VR4131の手抜きスーパースカラとか、V850の怪しい話とかは書けるみたいだけど。

>>34
パターソンってそんなドキュンだったんだ。なるほど。
工学にろくな教授がいないことをまたしても証明してしまったな。

パーシャルレジスタストールってメモリアクセスでも起こるんだな
北森だと３０クロックぐらいカラ回り
AthlonXpだと全然平気なのに

>>37
なんでそんなかかるんだろうね。
AMDにがっつり特許おさえられてるとか？

>>34
そんな事言ってたんだ。

漏れはSHシリーズは使ったことないんだが、
定数のロードは確かにアレだとｵﾓﾀ。
て優香、無理して命令コードを16ビット長にしなくても良かったんじゃないのかなあ。

ルネサスの場合、
旧日立のプロセッサだけでなく、旧三菱のプロセッサもあるから、
ホント大変だろうね。

>>35
>>28>>32の中森の文章では、国産のプロセッサは軒並み割愛されてるんだよね。
富士通がSPARCと絡んでるとかは除いて。

御前、それでも日本人かー！！ってｵﾓﾀﾖw

>>39
32bit長命令だとメモリを16bitバスにぶら下げた場合、
フェッチの時間が倍になって、とっても悲しいからのう…

かといって32bitバスにすると基板でかくなってお金がかかるので、
これまた困る。

まああの時代では16bit長つーのがそれなりに最適な選択だったと思うですよ。
問題は互換性のためにそれをひきずりまくった事ではないかと。

>>40
命令キャッシュなかったの？

まあコード密度は高かった(MIPS比1.5倍くらい)

ISAはSH5になってかなりマトモというか普通になった。

>>36
SYMBOLだのレジスタウィンドウだのロクな発明してないしな。

マトモなのはRAIDくらいなもんか？

SHはコード密度優先でキャッシュも少ない量しか搭載してない…。
っていうかダイサイズや消費電力を減らすためにそうなってる訳だが。
逆にキャッシュの効きは良いんだから、沢山積めば良いのにとも思う訳だが、
絶対性能を求めるようなもんでも無かった訳で…。

まぁそういうプロセッサだからMIPSや(Thumb無し)ARMとは趣が違う…。

>>34
H8は小ロットとアマチュアの強い味方です。やめないで。

Cellは4.6GHzで動作 - ISSCC2005の開催概要が明らかに
http://pcweb.mycom.co.jp/news/2004/11/29/011.html

>>44
はげどう。ただ個々のチップのライフサイクルは短いような
気がする。もうちょっとラインナップを整理してほしい。

>>44

ただ単に、フラッシュ内蔵したH8ピンコンパチで焼き方も
一緒で安価なSHが出てくりゃ良いだけの事だ罠。

フラッシュ内蔵したH8ピンコンパチで焼き方も
一緒で安価なItaniumが出てきたらどうしますか。

>>47
コードデンシティが低いし、自分でバンドルをつめるのも面倒だから嫌。

>>48
そしてIA64-16が

あはは

ほんとにオープンアーキ化しちゃうのね
http://power.org/

自分らの実装能力に絶対の自信があるっていう意味だろうなあ

「遅延スロット」ってRISC系CPUで主に実装されているんですか？

遅延かーサターンのPAR弄ってたときに勉強したな。
RISCアーキ出る前には既にあった。
目新しい技術ではないです。

えーと、コンパイラにコード吐かせると遅延有効活用できないときはNOP入れられるんだっけ？
ｳﾛｵﾎﾞｴﾝｶﾞｰ

ウホッ、久しぶりのカキコw
みんなどうしたのかと思ったyo!
て優香、みんなもっと書き込みщ(ﾟДﾟщ)ｶﾓｫｫｫﾝ!!!

…っていうくらいなら自分で書き込めよ、ってｵﾓﾀ('A`)

「遅延スロット」っていうのは、
RISCというよりパイプライン構造のプロセッサに関係のある概念だな。
まあ通常、RISCプロセッサ＝パイプライン構造なんで、
RISCに関する書籍とかを読んでれば自然と出てくる言葉だけどね。

>>52
実装というか副作用というか
分岐ステージ分割して高速化狙いしたCPUだと
分岐条件成立がわかるまでに分岐命令直後の命令が（分岐するから本当なら後の命令なんか実行する必要がない場合でも）パイプラインを抜けちゃう（＝実行完了）

何も考えないでインラインアセンブラ組むと誤動作の原因になる
分岐命令直後にNOP詰めとけば間違いないけどそれじゃ性能上がらないんで問題ない命令を何とか詰め込む
まぁコンパイラの方がうまかったりするけどｗ

盲腸だな。

RISCは CPUとコンパイラがピッタリ協調して 初めて意味がある。
なのに、バイナリコンパチとか言い出した時から、RISCはRISCでなくなったね。

CPUのOOOって凄いね。

PalominoコアのAthlonを相手に、コードの最適化やってるんだけど、
手で命令の順序を入れ換えてあげても、処理速度が変らない。
つまり、すでにCPUのOOOが適切に入れ換えてくれてた、ということ。

まぁ、漏れの技術力がないだけなのかもしれないけどね・・・・

>>58
Intel系でやってみそ
実行ユニットもデコーダも中途半端だからNOPはさんだ方が速くなったりするぞ
NetBurstになるとストールしまくるのでフラグを使った小細工は禁止

>>58
AMDからﾀﾞｳｿできる CodeAnalyst は、使ってみた?

>>59
Pentium4で走らせてみたらびっくりしましたよ。

Athlonで、
A1→A2→A3→B1→B2→B3
というような処理(それぞれ前段の処理結果を使うので並列に処理できない)を、
命令単位で細かくやったりせず、C言語で数行ごとに切替えるだけで、
A1→B1→A2→B2→A3→B3
のように並べ替えたら、処理時間が62%に縮まりました。
ところがPentium4では、116%に延びてしまいました。

MMXを使った部分では同じコードの調整で、
Athlonで88%に縮まったのに対して、Pentium4では72%にまで縮まりました。

インテルのCPUは、ちゃんとスケジューリングしてあげないといけないんですね。
Pentium4はまだいいほうで、Itaniumに至ってはコンパイラの性能差出過ぎですよ。

>>60
使ってないです。
インテルのVTuneに相当するものがあるのですか。しかもフリーですか。素晴らしすぎる。
ありがとうございます。試してみます。

いまはVC++用のプロファイラを使って当たりを付けて、処理時間を測りながら試行錯誤してます。
インテルとAMDのドキュメントに書かれている、パフォーマンス上の注意点の多さと、
自分で書くよりも、コンパイラに任せたほうが結果が良かったりして、凹んでいたところです。

ItaniumはVLIWなのでコンパイラで性能差が出まくるのはしゃーない

Itanium2に最適化してると、ただでさえ遅いItaniumは、さらに若干遅くなるんだよね。
そういう宿命なんだけど、なんだかさみしくなる。

HPはItanium共同開発から撤退らしいし…。

Longhornが予定通り出れば.netが普及するからチャンスがあるが、
このままだと消えてゆく運命かもな・・・Itanium/2

.netとItaniumとどういう関係が？

全面的に.net化すると、OS以外はCPUアーキテクチャから独立するから。

>>66
おまい、自分の興味ある記事しか見ないタイプだろ。

>>61
何を作ってるかはあえて聞かないが
手でスケジューリングは、涅槃が待っているのでがんがれ。

>>60
CodeAnalystを試してみました。

速く走るコードはパイプラインが整然と流れていて美しかったです。
もうこれ以上速くはならないよ、ということを突きつけられたのでもあるのだけど。

少し遅いコードでも、ストールしまくってるわけではなく、手でスケジューリングする余地はないように見えました。

インテルもこういうツールをフリーで出してくれればいいのに。
NetBurstのパイプラインストールが激しいのを見てみたいです。

>>68
そうでもない。
レス返さなかったのは、スレ違いだと思ったから。
# OSやJava,Ruby,.netの話しても詰まんないでしょ。

>>60>>70
私も早速DLして試してみました。CodeAnalyst。
所々パイプラインが切れているのは、Br mispredictやBank Conflictです。
L1データキャッシュはセット・アソシエイティブ数が少ないので、L2からの再ロードが
ここで起きているようです。L2でもバンクがぶつかった場合はメモリからロードするので、
相当ストールがかかっていますが、これは極たまにです。

Br mispredictは初回のCALLや、条件分岐で起きていますが、後の方に行くと
学習してしまい、CALLされてもパイプラインが途切れていません。

それにしてもAthlonのパイプラインは優秀です。クロック数が低くても速度が速い理由
が一目瞭然です。

しかし、x86 FPUを使ったら赤枠にピンクのストールだらけ！さすがに厳しいか・・・・
x86 FPUはRISC FPUに比べて性能が悪い傾向がありますが、これはXMMでも
使えば少しは改善されるのでしょうか。

>>70
＞NetBurstのパイプラインストールが激しいのを見てみたいです。
ﾌﾟのストールを想像するとﾊｧﾊｧ
それにしてもなんでこんなCPUが開発できたんだろ

http://pc.watch.impress.co.jp/docs/2004/1221/kaigai143.htm

本文二行目・・・

ん？PenMの開発ネームは何だって？ｗ

ドタンだと問題でも？

http://www.merriam-webster.com/cgi-bin/dictionary?book=Dictionary&va=Dothan&x=27&y=19

thの音に対する日本語表記はしょうがねぇじゃん。
ドタンでもドサンでもお好きなように。

土炭

弩ﾀﾝ・・・

土産？（違

いまさらぶり返すようなネタか？＞Dothan

ドウサンだと思ってた。つかアーキの話か？これ。

まあいいや。

それはともかくインテルのPARROTってどうよ。
俺はもうイリノイの連中のタワ言を信じるのはやめるべきだと思うのだが。

PARROTは後藤たんの記事を読んだだけだけど、
現在の技術の流れからいっても
まあ妥当なテクノロジだと思ったよ。
記事を読んだら0.1秒でtransmetaの朴李だと分かったけどw

て優香、イリノイってなんか悪い噂があるの？

AMDをﾊﾟｸったあとはﾄﾗﾝｽﾒﾀでつか。
Intelもﾌﾟﾗｲﾄﾞってもんが無くなってきたなぁ。ﾌﾞﾗﾝﾄﾞは技術に裏付けされたﾌﾟﾗｲﾄﾞと努力から
生まれるもんだと思うが・・・('A`)

プライドがあったらﾌﾟなんて出てこんだろ
31段スーパーストールアーキテクチャ

CodeAnalystを使ってみたいから、AMDベースのマシン組みたくなってきた。

ホットスポットに最適化したアーキテクチャは、うまくいけば
たしかに性能はいいのだが、外乱(割り込みとか)に弱いのよ。

論文でやってるような性能評価はアプリケーションレベルの
シミュレーションなので、外乱が一切ない状況なので、
実際は論文のようにうまくいかないことは、すでにPentium4と
Itaniumで懲りたんじゃないのかと小一時間。。

>>86
パクリメーカはAMDだろ。
編厨にはIntelの技術は何でもパクリにみえるんだね。
編厨の脳みそのエラッタ誰か改善してくれ。

PARROTはTransmetaのアーキに似てはいるが、
技術的トレンドから言って、Transmetaと似たようなものになってしまった
と見るのだ妥当だと思われ。
これはP6とNexGen開発時期が重なっていて同じようなアーキに
落ち着いた状況と似ている。

それからイリノイじゃなくてイスラエルチームの技術なんだけどね。
ちゃんと論文見て確認してくれ。

実はこの手の動的コード最適化技術は、盛んに研究されていて
特にいちはやく目をつけていたのはTransmetaではなく、実はIBM(1997)。
ttp://www.research.ibm.com/vliw/isca31/Daisy%20-%20Dynamic%20Compilation%20For%20100%20percent%20Architectural%20Compatibility.pdf

マイクロアーキの開発にはそのときどきのトレンドってものがあって、
動的コード最適化やトレースキャッシュ系の技術は最近さかんに研究されている
分野のひとつで、IntelのPARROTもそのトレンドにのったもの。

すぐに"パクリ"という表現で片付ける香具師はまったくこの分野のトレンド
がわかってないと思う。

だからPARROTはイリノイのrePlayその他が元になってるんだってば。
http://www.cs.ucsd.edu/users/calder/classes/spring04/240B/papers/PARROT-ISCA04.pdf
ほれ。

>>90
IntelとAMDはアーキテクチャ分野で技術提携してますが
拡張アーキテクチャの相互利用、相互開発でしょ。

故・ノイマン博士＞＞＞＞越えられない壁＞＞＞＞CPUベンダ

これ定説。

>>89にも書いたが、
インテルはprecise interruptをどうやって実装するつもりなんだ。
特許ネタだから出てこんのか。

>>96
DaisyやらCrusoeやらが採用している方法では
問題があるんですか？

>>91
まぁ最適化がおまけだとするとｗｗｗ
エミュレータをソフト〜ハードのどこに実装するかではあるよね

ソフトだけ：
OS組み込みで完全にソフトでやるのが
PPCで68kコードのMacOSとか
Itaniumでx86実行するIA-32EL(Itanium自体にx86ハードエミュもあるけど早くも互換性のためだけ？）

ソフト＋ちょっとハード：
OSからもBIOSからもただのx86互換チップにしか見えない(Transmeta以外はVLIWコードを直接走らせることはできない）
けれどCMS=ソフトでx86エミュレート（？）してるｸﾙｰｿｰ・ｴﾌｨｼｵﾝ

ハード（＋ほんの少しソフト？）
PARROT？　ﾘｺﾝﾌｨｷﾞｭｱﾗﾌﾞﾙが最近の流行だから
ある意味でソフト的な要素ってことになるのかな？

>>95
故・ノイマン博士　ってフォン・ノイマンのこと？
EDSACの論理担当をやってただけなのに
（すでにノイマンは高名な数学者だったのでプロジェクトの箔付けの意味で開発してた大学の意向？）実装担当者が考えたプログラム内蔵方式（いわゆるノイマン式）を
自分の名前で研究発表しちゃったもんだから実装担当者は怒ってプロジェクトやめちゃったらしいよ

エビのうんこたれ

>>99
そんなのどこでも聞く話じゃないか(涙

>>93
その論文の具体的にどこがイリノイのが元になってるのか？
無理に自分の意見押し通そうとするなよ。

>>102
2ページ目のおわりのほうに
Our results complement and strengthen the rePlay study
showing the significant contribution of dynamic optimizations
to IA-32 based processors.
(略)
とあるだろうが。

英語読めないんなら言ってくれ。翻訳してやるから。

>>103
結構だが、それで>>84がイリノイ大学の論文は信用できないって言う理由は何故
なんだろうか？

プロセッサの性能向上には
1.性能が出ない場合をなんとかカバーする
2.もともと性能が出ているところをさらに速くする
と二通りの方向性があって、victim cacheなんかは1なんだけど、
イリノイ大の研究はほとんどが2なのよ。

rePLayとかPARROTみたいなトレースの最適化が有効になるためには
そもそもトレースキャッシュのヒット率が高くないといけないわけだが、
論文でやってるようなアプリケーションレベルの性能評価環境に比べて、
実機は割り込みやらコンテクストスイッチやらがあるので
同じ容量でもヒット率は(俺感覚では、かなり)下がる→
思ったほど性能が出ない、という破目になる。

もっとも実環境での性能評価は大学レベルでは極めて難しいので仕方がない
のではあるのだが、それはいいとして、
どうもネタが最大限有効になるようなパラメータチューニングやってるっぽい。

というわけで、論文にでている性能評価を鵜呑みにするのは危険じゃねーの。

その「俺感覚」について詳しく。
割り込みの影響なんて、たいして効かないと思ってた。

>>106

105ではないけれど、論文発表だと大抵のキャッシュヒット率は90%台にのせてるのだな。
で、例えキャッシュを倍にしても、少なくとも数字の上では数パーセントもヒット率は
変化しないんだ、これが。

ところが、実際にキャッシュが増大されたCPUを使ってみると…
体感出来るぐらいには変化しちゃうんだなぁ…(^^;;;

90%台のHit率が数%変わったら大違いだと思うよ。
Miss率で考えたら分かる。

Rotenbergの論文
http://www.tinker.ncsu.edu/ericro/UW/papers/TC_micro29.pdf
の最後のほうにも出ているが、トレースキャッシュは一般的にヒット率が低い。
理由は、本文2.2に出ているが
Specifically, a trace cache hit requires that
(1) the fetch address match the tag and
(2) the branch predictions match the branch flags.
ついでに、トレースキャッシュは同じアドレスの命令を複数ラインに
コピーするため、実効的な容量はさらに減る。

ところで、割り込みが起きると普通のキャッシュと同様に有効なキャッシュ
ラインが追い出されるが、実は分岐予測テーブルのほうも分岐履歴が乱され、
予測率が低下する。
トレースキャッシュの場合は、2があるので普通のキャッシュに比べさらに
不利になるわけ。

キャッシュって何msecも保持し続けないと効果が薄いなんてことはないと思う。

毎秒1万回、コンテキストスイッチする場合でも、
1GHzのCPUなら0.1msecに100kクロックもある。

それにコンテキストスイッチしなくても、
同一コンテキストでキャッシュから追い出したりすることもある。

パーシャル・パイプラインストールって何？おしえてprz

>>111
まじめに作るのめんどくせーし、誰も使ってなさそうだから適当に作っちゃえ、
ってこと。細かいことを飛ばすとそういうことだ。

>>112
細かいこともよろしく（うまくググれないんで）

>>113
パーシャル・ストール
パーシャル・レジスタ・ストール
パーシャル・フラグ・ストール
パーシャル・メモリ・ストール

ググれたけど。要するにレジスタをつなげた時のために、まじめに(ry

>>114Thanks

どうも「パーシャル・パイプラインストール」では中心をついてなかったようです(´･ω･｀)ｼｮﾎﾞｰﾝ
パイプライン全体っていうよりも主に演算ユニット関係みたいですし

バイトコード直接実行型JAVAチップとか（FPUだけど）x87とか
昔一時スタック構造レジスタ・アーキテクチャがなんで流行したの？
今からするとわざわざ（偽）依存性作ってるだけにしか思えないんだけど
メリットくわしく教えてprz

>>116

スタックマシンに関してはちょっと調べれば一杯出てくると思うけど…。
っていうか逆ポーランド記法との相性が良くてコンパイラの設計がしやすいって
のが古典スタックマシンでの最大のメリットだったような…。
スタック操作は基本操作の一つな訳で、関数コールなんかでも頻繁に登場したり
する訳だから、ネイティブで操作できるってのは大きなメリットになりうる。
forthなんて専門に扱える言語もある訳だし。後でデメリットも判明した訳だが。

で、x87やJAVAはその手の流行からは後の話で、そういう都合では無いだろう。

x87は命令コードの節約とか色々な都合からそうなってるんだと思うね。
JAVAバイトコードに関しては当初から色々と言われているけど。
なんかの学会でパターソンだかが「なんで今更スタックマシン？x86ネイティブ
コードの方が良い。なんたって十分普及してる〜」と突っ込んだらしいぞ(笑)
正直JAVAは設計者の趣味でそうなってるんだと思う訳だが(^^;

>>117THX
なるほろ

Javaのバイトコードがスタックマシンになっている理由は
・コード密度
・検証のしやすさ
・スタックマシンのほうが性能のよいインタプリタが実装可能
ってところ。

年寄りはひっこめってカンジ>パターソン

ハードで実装するときは高速化が難しいんだけどね＜スタックマシン

時代が違うからね。CPUにパイプラインもスーパースケーラも実装されてなく、
メモリアクセスがノーウェイトだった頃は十分に存在意義があったと思う。

そういやJAVAは、最初はアプレットで売り出したんだよな。
コード密度は重要な気がする。

Sunの奴らはFORTH大好きだからスタックマシンになったんじゃないのか…

トロンチップをスタックマシンにしたかったが産業界から猛反発を食った坂村さん

それはともかく、今日日ヘネパタは教科書としては二流だな。
読まなくていいよあんなの。

じゃあパタヘネは？

パタヘネは学部向けとしてはわりといい本だと思う。

http://www.amazon.com/exec/obidos/tg/detail/-/0072829680/qid=1105116635/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/002-7592221-6291209?v=glance&s=books&n=507846
http://www.amazon.com/exec/obidos/tg/detail/-/0818684003/qid=1105116664/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/002-7592221-6291209?v=glance&s=books&n=507846
この2冊が今のベストだと思う。

英語の勉強のために、表紙に白地にそろばんが書かれている本を古本で買いました。
再生紙に、しょぼい装丁、いまどきMIPS R2000/3000かよ、でも500円なら英語の勉強には安いな、と。

読んでみてビックリ。
こりゃ面白い。
結局、英語の勉強にはなりませんでしたが・・・。

http://computer-refuge.org/bitsavers/cdc/DesignOfAComputer_CDC6600.pdf

あとはまあ、これでも読んどけ
http://www.amazon.co.jp/exec/obidos/ASIN/4331506231/qid%3D1105178689/250-6820354-3087400

これはどうよ。
http://www.amazon.com/exec/obidos/tg/detail/-/0201105578/qid=1105182149/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/002-7592221-6291209?v=glance&s=books&n=507846
俺んとこにはまだきてないが、Blaauwはわりと神。

漏れが読んだのはパタヘネの1st editionだったのかな・・・

amazonにある、2nd editionや3rd editionとも表紙が違うから。

age

ヘネパタ

Googleで「ヘネパタ」を検索したら、Amazon.co.jpがトップに出るね。

.neのCLIもスタックマシンなんだよね
この手のはスタックマシンのが良いんだろう

>>136

PASCAL世代(アメリカでは一時期、教育にPASCALが使われていた)は
スタックマシンに愛着があるんだろ…。
コード密度って意味だけなら、CISCの権化である所のx86は高い訳だし〜。

コンパイラ作るのらくだからねぇ＜スタックマシン
でもハードウェア実装の方を高速化するのはかなりきつい。

まぁ中間コードならありだとは思う。
.netとかはそういう感じだろう。javaもそんなところ。

ム板の興味深いスレ紹介しておきますね。

x86命令の所要クロック計測スレ
http://pc5.2ch.net/test/read.cgi/tech/1103609337/l50

前にも書いたことがあるが、
スタックマシンはコードの検証がコードサイズnにたいしてO(n)。
レジスタマシンだと全パスをたどって検証しないといけない。

ここは自作板で最もコアなスレだと思う

このスレ読む前にまずヘネパタ

Cellが来た。
ttp://pcweb.mycom.co.jp/articles/2005/02/08/isscc1

立ち上がれ
Z戦士達

CellのSPEおもろいね
Itaに対抗できる

前スレみて感動しました。
そろそろ、うんこねたで「良くわかるマルチスレッド」とか
お願いします。

待ち行列理論の説明は、普通は銀行の窓口でやるんだけどな・・・

TLBフラッシュのロスを減らすために、一つのCPUに同一プロセスのスレッドを
なるべく張付けておきたい、こういうのも待ち行列理論であっさり解決するの？

富士通研究所、4つの「FR-V」プロセッサーコアを1チップに集積した
デジタル民生機器向けCPUを発表
――世界初の8way VLIW CPUによるクアッドコアCPU

ttp://ascii24.com/news/i/tech/article/2005/02/07/654086-000.html

超亀レス
ttp://pc5.2ch.net/test/read.cgi/jisaku/1082357989/236（前スレ）
＞236 名前：Socket774[sage] 投稿日：04/05/14 04:17 ID:o8pcTKwR
＞x86の有利な点を無理に言えと言われれば、レジスタが少ないので
＞コンテクストスイッチが少し速くなる可能性がある事かいな。
＞
＞x86-64なんかでは、増えたレジスタをスイッチの度に全部待避する
＞んだろうか？

↓
（時間的には前だけど236は多分見てない）
http://pcweb.mycom.co.jp/articles/2004/03/10/64bitwindows/002.html
＞DivX Video Compressionのスコアが64-Bit Editionで半減するのは興味深い。
＞DivX Codecはマルチスレッドを利用しているため、シングルCPUではコンテキスト切り替え(スレッド切り換え)のオーバーヘッドが表面化している可能性がある。
＞64ビットCPUはレジスタサイズが大きい上に、レジスタ数も増えており、32ビットWindowsよりもコンテキストの切り替えに時間がかかるためだ。

x86-64程度でこんなことになるんなら外から見えるレジスタ増やすのもメリット・デメリットあるね
クライアントとは比較にならないマルチスレッドに違いないItaniumはどうしてるんだろう？

>>150
「レジスタ・スタック」について調べてみるといいですよ。

Itanium以外にも多くのレジスタを持つCPUはあって、
SPARCのレジスタ・ウィンドウがとても有名です。

ちなみに、
DivXのスコアが半減する理由が、レジスタ数増加による云々は、なんか違う気がします。

64ビット版のWindows(しかも当時のベータ)で、
32ビットのDivXを走らせた場合の話なのですから。

うんこねたで「良くわかる***」を書いた方は、
もうこのスレみてないのかな…

パタヘネ2使って教えてるんだけど、3章と5章でつまづくやつがいっぱい。
メモリとレジスタの関係とか、アセンブリ言語の文法的なこととか、
なんであのデータパスで命令が動くのかとか、ごちゃごちゃになる人種が多いのよ。
どうにかわかってもらえるような、
うまいモデルとか、ビジュアルなシミュレータとかない？
spimはいまいち。

Alpha21364最強

>>153
そんなんで つまずく学生には単位やらなくていいよ。

俺が学生の頃は、これ読んでおいてください。
とてもよい教科書なので、読めばわかります。
授業は読んでいることを前提に、話をします。

っていう先生だったよ。
んで、授業では本に書かれていない難しいことや新しいことが中心。
でも、試験の内容は本に書いてあることだけという、優しい先生だった。

このスレはやけに詳しそうな発言をするやつが多いが、
会話になってないし、最新のトピックに弱い気が。
みんなホントは制御用のマイコンとかしかさわってないだろ？

本当に語れるような人は、2chやってないと思う。
だってさ、誰が話についていけると思う?

>>157
書き込まないだけだと思われ

最新のトピックを判りやすく噛み砕いてトイレモデルで説明するには
校正の時間がたりない。ってゆーか最新の研究なんておっかけるだけで
精一杯ですよ…。>>155のｾﾝｾｲはとてもｽﾊﾞﾗｼｲ人だとおも。

>>155はその業界にいる現役のライターとみた。

MIPSだぞ！

東芝、64bit MIPSアーキテクチャマイコン
http://pc.watch.impress.co.jp/docs/2005/0307/toshiba.htm

デジタル情報機器向けMIPSアーキテクチャ64ビットRISCマイコンの発売について
http://www.toshiba.co.jp/about/press/2005_03/pr_j0701.htm

ふと思ったんですけど、CMSの対応があればIA64→VILW変換して、
IA64のCPUとして使うことも技術的には可能だったりします？ トランスメタのCPUって

>>162
けっこーいろんな部分が、x86 対応のために作られてる感じ。
バイトコード程度だったらまだしも、他アーキテクチャを
うまく真似れるよーな構造じゃないと見受けた。

Crusoe Exposed というドキュメントを読んだことある?



ていうか、痛ニウムの Bundle が、IA64 に最適化されてるよーな希ガス

>>163
流石に汎用とは行きませんか。
そのドキュメントは読んだこと無いです。他の技術系ドキュメントも・・

CMSをバイパスして、ネイティブコードで走るLinuxって、どうして誰も作らないのかな。

BIOSやCMSが隠蔽してるけど、メインメモリのCMS領域をCPUからではなく、
PCIバスなどから書き換えれば、CMSを乗っ取れるような希ガス。

・・・労力の割に、得るものが少ないからか。

>>165
Crusoeはメモリコントローラ内蔵だから、PCIバスからのアクセスをできないようにもできるだろう。
その程度の保護はしていると思われ。

>>164
Crusoe Exposed: Reverse Engineering the Transmeta TM5xxx Architecture
http://www.realworldtech.com/page.cfm?ArticleID=RWT010204000000
http://www.realworldtech.com/page.cfm?ArticleID=RWT012704012616

>>165>>167
挙げたドキュメント読んでわかると思うけど、
PCIバス側から抜いた、と書いてある。
TM5x00 では可能、ということだね。
ｲﾋでできるのかどーかはまだ知らない。

>>168
その文書読んで理解できなかったんなら絶望的すけど、Clusoeわ命令MMUを持たないので、コードモーフィング
ソフトウェア「しか」動かないようになっているす。

MMUないのか。

じゃぁコンパイラがネイティブ命令を吐き出しても、
実行する前に動的に手直ししなきゃいけないのか。

>>170
ttp://pc.watch.impress.co.jp/docs/article/20001226/kaigai01.htm

仮想化技術の
↓これってなんて読むの？
xen

ゼン

最新のCPUアーキテクチャを勉強するにはなんの本を読めばよいですか？

.　　　　　　　　　 ＼　　　　　　　　　　　　　　　 ／
.　　　　　　　　　　　＼　　　　　　　　　　　　 ／
.　　　　　　　　　　　　 ＼　　　　　　　　　 ／
.　　　　　　　　　　　　　　＼ ∧∧∧∧／
.　　　　　　　　　　　　 　　＜　　　 俺　＞
.　　　　　　　　　　　　 　　＜　予　し　 ＞
.　　　　　　　　　　　　 　　＜　　　 か　 ＞
.　─────────＜　.感　い　 ＞──────────
.　　　　　　　　　　　　　 　＜　　　 な　 ＞
.　　　　　　　　　　　　　　 ＜　!!!!　い　 ＞
.　　　　　　　　　　　　　　　／∨∨∨∨＼
.　　　　　　　　　　　　　 ／　　　　　　　　　＼
.　　　　　　　　　　　　／　　　　　　　　　　　　＼
.　　　　　　　　　　 ／　　　　　(-＿-)　　　　　　 ＼
.　　　　　　　　　／　　　　　　 (∩∩)　　　　　　　　＼

なんか日付のファーマットが変わってるよ！

ファーマット？

毛皮でしょう

>>174
とりあえず、これ全部嫁
http://www.amazon.com/exec/obidos/tg/detail/-/1558605967/
http://www.amazon.com/exec/obidos/tg/detail/-/1558606041/
http://www.amazon.com/exec/obidos/tg/detail/-/1558603433/
http://www.amazon.com/exec/obidos/tg/detail/-/0131420445/
http://www.amazon.com/exec/obidos/tg/detail/-/1558608745/

>>179
うわ、めちゃくちゃいいなこれ

Computer Organization and Design: The Hardware/Software Interface, Third Edition
http://www.amazon.com/exec/obidos/tg/detail/-/1558606041/

(´-`).。oO(こういう本が日本で出ないのはなぜだろう．．)

>>180
釣りですか?

ちなみに、類似本が出ないのは、ヘネパタ・パタヘネの2冊があるのに、
同じような内容の教科書を書く無駄をする教授がいないためだと思われ。

何冊もCPUのアーキテクチャの教科書を書いた教授でさえ、
ヘネパタ・パタヘネを教科書に指定しているくらいだからさ。

#漏れが学生の頃は、日本語訳なんてなかったから、原著でした。
輸入で一冊8千円くらいしたよorz

>>181
このスレがあまりに閑散としてるから釣ってみた。

>>182
アーキテクチャの技術ってさ「なまもの」みたいなものじゃん？賞味期限みたいな奴？
だからさ、最新のCPUアーキテクチャが載ってる書籍がバンバン出る米国はいいなって思っただけ。
それだけが言いたかったのさ。

まぁ、それに対する返事はきまって「原書読め」って言われるんだけど．．

ま、パタヘネ3だって、MIPS対抗馬としてPowerPCやめてIA-32しかなくなった。

>>184
えっ？ パタヘネ３って以下のアーキテクチャを解説してるんでしょ？
+ Intel IA-32
+ Power PC 604
+ Googles PC cluster
+ Pentium P4
+ SPEC CPU2000 benchmark suite for processors
+ SPEC Web99 benchmark for web servers
+ EEMBC benchmark for embedded systems
+ AMD Opteron memory hierarchy
+ AMD vs. 1A-64

あと、ハードウェアで、
+Using logic design conventions
+Designing with hardware description languages
+Advanced pipelining
+Designing with FPGAs
+HDL simulators and tutorials
+Xilinx CAD tools

ソフトウェアで、
+How compilers Work
+How to optimize compilers
+How to implement object oriented languages
+MIPS simulator and tutorial
+History sections on programming languages, compilers, operating systems and databases

ってに関する事が書かれてるらしい。

＃ついでに言うと1A-64でなくてIA-64だと2ch経由でつっこんどく

>>183
PCIバスの技術書もアメリカ発のしかなくて、
落胆した人もいたらしいとか聞いたことがある。
本があってその出来がどうのこうの以前に、
日本からこういった本が出ないあたり、
この分野でアメリカを追い抜けないのは当然な感じがする。

>>186
んなことはないよ、PCIバスの解説書は、CQ出版とかから出てるよ。
規格によっては、JISで制定するという名目で、日本語訳が行われていたり・・・

でも昨今の、国が無駄な支出してるとか叩かれているので、
そういう日本語化しましょうプロジェクトは縮小の方向かもね。

>>187
>んなことはないよ、PCIバスの解説書は、CQ出版とかから出てるよ。
PCI-Expressの解説書も出てたっけ？
日本語での文書があったら読みたいんだけど。

>でも昨今の、国が無駄な支出してるとか叩かれているので、
>そういう日本語化しましょうプロジェクトは縮小の方向かもね。
(　･∀･) ﾍｪｰ 　ｿﾝﾅ　ﾌﾟﾛｼﾞｪｸﾄ　ｱﾙﾅﾝﾃ　ｼﾗﾅｶｯﾀﾖ

そこで、出版社の出番ですよ。どこか出して♥

>>188
PCI-Expressはクローズドな規格だから・・・。

インテルにあったPCIの規格書のページもなくなって、PCI-Express用になっちゃっててorzですよ。

日本規格協会(?)から入手できるいろいろな規格書の翻訳版。
いまも意味不明の翻訳、レイアウトもぼろぼろ、値段は英文の
2倍以上ですか?

>>189
とりあえず書籍は出てるみたいだからなんとかなる。(と値段を考慮せずに言ってみるテスト)
http://www.amazon.com/exec/obidos/tg/detail/-/0321156307/
http://www.amazon.com/exec/obidos/tg/detail/-/0971786194/
http://www.amazon.com/exec/obidos/tg/detail/-/0970284691/
http://www.amazon.com/exec/obidos/tg/detail/-/0976086514/

>>190
>日本規格協会(?)から入手できるいろいろな規格書の翻訳版。
>いまも意味不明の翻訳、レイアウトもぼろぼろ、値段は英文の
>2倍以上ですか?
ﾜﾛﾀ

誰かこんなアプリ作って！
$ cat 英語文書 | jptranslate > 日本語文書

>>190
笑うということは、いまだにそうだ！と思っていいのかな、日本規格協会…

>>191だった…orz

ま実際読む側にとってみれば、笑うところというか、苦笑いするところ

原文を想像しながら読むこともあり。
で、結局、原文で確認することもあり。

【結論】
最初から原文を読んでいれば原文と翻訳文の間に
コンテキストスイッチが発生しない分、パフォーマンスが上がる。

なるほど

>>196
でも、実行可能状態になれるかどうかは脳内コンパイラの出来しだいだなw

5/31の情処SIGARCの研究会で、究極のスーパースカラプロセッサアーキテクチャが発表されますよ。

至高のスーパースカラプロセッサアーキテクチャも発表されますか?

ページングよりも効率のいいメモリ管理方法を研究してる人っているの？
あっても誰も使わないだろうっていう話はさておいてさ。

どの効率にもよるかだが。
大容量二次記憶と併用するならば、TLBツリーによるページングはベター。

もちろんいちばんパフォーマンス的に効率のいいのは、仮想記憶に頼らず、
積めるだけメモリを積むことだってのは、わかるよね?

i386 のセグメントモデル、調べてみ? OS/2 は多用してるんじゃなかったかな。

このスレで話すからには、
仮想アドレスから実アドレスを生成する効率の話だよね?

>>203
それはMMUの事か？

>もちろんいちばんパフォーマンス的に効率のいいのは、仮想記憶に頼らず、
>積めるだけメモリを積むことだってのは、わかるよね?
二次記憶を使わないモデルでも、
仮想記憶を用いて実ページを共有するのは効果的ですよ。

CPUのアーキテクチャのスレで、OSの仮想記憶の実装について語りますか・・・。

使われ方を理解しないでどうするのさ？

CPUが例外を出した後の処理なんてOSの仕事だからどうでもいいよ。
どのページから捨てるかといった、そういった処理なんてCPUは関係ないから。

こいつはOSの動かないCPUを作りそうだな。

まるでMC68000のようですね

鶏が先か卵が先かっていう話。

>>205のような話が、CPUのアーキテクチャと関係があるとでも?

あるに決まってるじゃん。

なにも仮想記憶だけがCPUアーキテクチャの重要な機能というわけでも無いだろ。

>>203-204
そういうことです

(・∀・) RISC!

TLBトラバースをMMUで行わないアーキテクチャ、あったよね?
R3kとかだっけ?

80286に実装されたセグメンテーションによるメモリ保護機能は、
CPUアーキテクチャの重要な機能です。
外部PMMUからのバスエラーによる例外処理より遥かに効率的でした。

他のプロセッサは集積度の問題でワンチップにならなかっただけでは？

ページマップ方式とセグメント方式ではあきらかに仮想記憶の実現方法
（というかメモリの管理方法）が異なり、むしろこれはCPUアーキテクチャに
よってOSの実装が決まるパターンです。OSだけじゃなくてアプリケーション
にも影響を与えますね。C言語系とは相性悪いはず。

ごめん、「だから、チップ実装の問題だけじゃないはずですよ」
と続きます^^;

>>220
だとすると
＞外部PMMUからのバスエラーによる例外処理より遥かに効率的でした。
これは余計な気がします。
必ずページマップ方式では外部からのバスエラーで例外処理をしないといけないわけではないでしょう？

通常のレジスタを持つFPUは、外部から命令を横取りして動作するx87より効率がよい。
といっているようなものです。

ねじれているというかはぐらかされているというか問題はそこじゃないだろというかなんというか。

あー、ごめんなさい、確かにそのくだりは余計ですね。
言いたかったのは、ソフトウェアのトレンドによってCPUアーキテクチャも
大きく影響をうけるんで、「CPUは関係ない」なんてこたぁないって事です。

あのさ今ふと思ったんだけどさ、
Amazonとかのレビュー評価とかあるじゃん？
あれさ、結構たくさんの人が５や４とか付けてる書籍がたまにあるけどさ、
それってレビュアー自身から見た相対評価なんだよね。絶対評価じゃなくて。
そうなるとさ、そのレビュアーのレベルが低くってむちゃくちゃ褒めてたりしてた場合に
中級者や上級者がそれ見て買った場合、地雷を踏むことにならないか？

結局、買う前に内容を調べられたらいいなと思う今日この頃。

amazonのレビューなんか全部提灯と思え

P4がしょぼいのはさておき、
なんでこんなにSunFire 6800は効率が落ちないの？
おしえてエロイ人！
ttp://compression.ca/pbzip2/

>>224
むしろ、誰もレビューしてない時がとってもリスキーという罠。

>>226
なんだよおい、SunFireだけCPU数が無茶苦茶多いじゃねーか。

Athlon MP-2600+　　　=　2
Oteron 240　　　　　　 =　2
Pentium4 3.06 Xeon　 =　2
Itanium2 900　　　　　 =　2
SunFire 6800　　　　　 =　24

SPARCヽ(´ー｀)ノﾊﾞﾝｻﾞｰｲ

>>228
>226
＞なんでこんなにSunFire 6800は効率が落ちないの？
＞SunFire 6800は効率が落ちないの？
＞効率が落ちないの？

>>226
bzip2 が並列向きなアルゴリズムというのは知ってたが
実装を見つけることができなかった。あとで会社でさっそく試してみるよ thx.

>>226
良く並列チューニングされてるアルゴリズムなんだなぁ。
というわけで、質問まちがっとるで？

×なんでこんなにSunFire 6800は効率が落ちないの？
○なんでこんなにP4 Xeonは効率が悪すぎるの？

さておいちゃダメだぞ、これ重要(笑）
SharedBusの弱みでちゃって帯域たりてないんだろうなぁ…。

2プロセッサのグラフで最も効率が良かったItanium2 900MHzも共有バスですよ。

初代Itaniumで、FSB帯域が大ネックになった反省からか、
Itanium2ではバス幅とクロックが引き上げられたからね。

初代ItaniumはDDRのPC2100のメモリが出まわるよりも昔、
PC66の0.5GB/secの頃に設計されたものだから、
あれでも十分にFSBが広かったのだけど、まぁそれはいいや。

Xeonの場合、Pentium4と共通設計なので、バス幅を変えられない。
そういう縛りがある場合、共有バスよりも一対一接続がいいよね。

1) SunFireの方が高いから。
2) SunFireは1CPUが遅いから。

全てのメモリが全てのCPUから透過的に扱えるけど尋常じゃないバス帯域を要求されるのと、
NearLocationとFarLocationで速度変わっちゃうけどCPU増えれば総大域が増えるのと、
システム全体として扱いやすいのはどっちなんでしょうね。

ManyCore/MultiCPUなSMPへと今は向かってるんで、後者が有利な気もしますが、
効率的に使おうと思うとOSのメモリ管理機構のチューニング抜きじゃ
お話できないわけで…。

Opteronはcc-NUMA。

扱い易いのはSMP。ただし大規模なものが作れるかが問題。

DECのAlphaが常に先端した技術を開発していたのに無くなっちゃうとはなぁ．．
まぁ結局、元Alphaの開発者達はIntelやAMDに四散して、
その後に出たPen4のSMTやOpteronのHyperTransportとかにその技術が引き継がれたわけだが。
ていうか、買収した会社がその恩恵得ていないという罠。w

>>238
K7ことAthlonも元Digitalのｴﾝｼﾞﾆﾔが深く影響してるよな。

>>239
そう考えるとDECのアーキテクチャ研究開発部門って凄かったんだな。

Alphaはすごかったなあ・・・
IntelのPIIとならべてNT4.0上でベンチマーク競争させたときに、
ぶっちぎりの性能たたき出してた・・・
あと、ギネスブックにも載ってたはず。
世界最高速の単体CPUとして。
初期の受注生産で研究者向けのAlphaAXP150が100万だったかな？
とにかくすごいCPUだった。

>>241
値段がすごいな。

>>242
値段かよ！

>>243
受注生産でぶっちぎりの速さで１００万円だったらすごい値段の安さだと思うが？

http://en.wikipedia.org/wiki/DEC_Alpha
http://ja.wikipedia.org/wiki/DEC_Alpha

当時の DEC Alpha processor は史上最強だったというお話。

まぁ今の状態でたとえていえば、10GHzのプロセッサを出しているような状態だからなぁ。
電力消費は1kWって感じだが。

つうか、技術的にも当時の流行の先を行ってた感じだな。
Alpha AXP is cool !!

しかし自分でソフトを書かない人々や、書いてもそれを他人に売る人々は、
CPUの速さよりも、バイナリ互換のほうが重要だと考えたわけで・・・。

x86がデファクトになった時点で、つまらなくなったよね。
しかも今は並列化すりゃいいじゃん、という時代の流れ。

27年間通用するアーキテクチャを謳ったAlphaも半分に満たない12年で息切れ…。
悲しいものですなあ。

>しかも今は並列化すりゃいいじゃん、という時代の流れ。
これ以上CPUのクロックアップ難しいから並列化しようそうしようってのは
15年前もおんなじこと唱えてたわけで。その度にBreakThroughがあったわけだけど。
当時25MHz駆動（選別品で33MHz、後にNECから33MHz品出荷）だったR3000のロジックを
ECLで組みなおして「うりゃぁ、66MHzの超々高速CPUだぜ！」って鳴り物入りでだした
R6000が民生品の安CPUなPentiumにあっさり抜かれたりね。

21064って確か3.3V駆動で48Wとか食ってさ、ぉぃぉぃCMOSで10A以上流すのかよ
馬鹿じゃねーの？とか笑ってた当時パソコンがこんななるとは想像だに…。

ギネスの名目は、世界で初めての単体CPUでCray1の性能をだしたプロセッサ、
だったはず。時系列問題なので記録の更新不可能。

初代Pentiumも凄かったな。なんたって5V単一電源なんだから。

初代Alphaってクロック当りの性能がそれほどでも無いような気がしたが。
Pentium4みたいなもんか。

>>250
今見るとヒートシンクがpoorで笑える…出してみようと思ったらヒートシンクは
捨てちまってた。orz

>>251
初代もその次の世代もそんな感じだった気がする。
「止まっている時間の方が長い」なんて言われてた。
Pentium4も今10GHzオーバーの石があればねぇ。

>>252
21064で同クロックのPentiumの半分。21164で同クロックのPentiumIIの半分といったところかな。
しかしクロックは3倍だったわけで。それはそれで圧倒的。

効率が悪くてもいいからクロック上がるようにして、
ガンガン回せば問題なしというポリシーに関しては、
Alphaに比べれば、Pentium4なんて、かわいいな。

21264で化けたけどね。

>>254
RISC対CISC論争全盛の頃か？

>>255
そうそう。
クロック上げるのが難しくなってきて方針転換したね。

そして、クロックだけではインテルに追い抜かれるという・・・。

サムソンがAlpha/strongARMで学んだから云々というけれど。
結局連中が学んだのは「人海戦術で回路最適化」だけだったりする。

alphaも人海戦術で手でちまちまと最適化したんだよね。

>>245のリンクに書いてある。

人海戦術なのは高速LSIではどこもいっしょじゃないの？
IntelやAMDが人海戦術でなかったら、そっちの方が驚き。

インテルは、演算器のところには人つぎ込んでるらしいね

他は合成・自動配置なの？それとも比較的人が少ないだけ？

知らんがな

演算器というかクリティカルパスつぶしだな。

とはいえ21264のクリティカルパスはALUだったらしいけどな。

今のsynopsysの解析ツールはかなり優秀だけどな。
インテルのALUは無茶やってるみたいだから人海戦術と内製ツールだろうけど。

具体的なところは想像するしか無いわけだね？

あまりこのスレで話題にならないが、
PowerPCの潜在能力はどうよ？
http://www-6.ibm.com/jp/servers/aix/developer/tech/power4/

あと、こことか
http://www-128.ibm.com/developerworks/library/l-powarch/
http://www-106.ibm.com/developerworks/linux/library/l-powhist/
http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/C114EA830D8B17E487256EAD00493C17/$file/PowerPC_970FX_64bit_Introduction_Apr_12_04.pdf
http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/A1387A29AC1C2AE087256C5200611780/$file/PPC970_MPF2002.pdf

>>268
>あまりこのスレで話題にならないが、
>PowerPCの潜在能力はどうよ？

もっと詳しく。
あなたの言葉で。

>>270
PowerPC 970MPとかの概要見てて、直感的に感じる何かがあるのだ．．．
それに、デュアルコア(マルチコア)なPowerPC 970MPが欲しいなと。
けど、手に入れるにはMAC買うしか無いのかのぅ。　普通に自作できればいいのぅ。

スラドにもそんな話があった。
PowerPC 970MPの概要
http://slashdot.jp/article.pl?sid=04/07/30/0830228

>>271
IBMの鯖とワークステーションでPOWERプロセッサ搭載のがあるみたいだから、
それも検討してみては？

たけーよ

>>271
個人が970MPを所有するにはMAC買うしか選択肢が無い。

>>271

一番安い物なら箱2だ。
無論ゲームしかできんがｗ

>>275
970MPは無い
ゲーム機に乗せれる消費電力じゃないからな

>>275
ゲーム機はちょっと違うだろ。

　

POWER POWER
上昇します

おまいら何故PowerPCの話題だと引くんだよ。w
PowerPCもRISCアーキテクチャです。

SPARCもRISCアーキテクチャです。

>>281

ネタが尽きて人が離れていった後で、
PowerPCの話題を出してスレ再生しようとしても、

もはや読む人が減りきった状態をいかんともできず。

たぶんPowerPCだから引いたって理由じゃない。

まえみたくトイレネタ(?)かなんかでのわかりやすい講座
やってほしいよ。

前スレが神スレすぎたからな。
市販の技術書レベルの話題になってたし。
面白いCPUとか出たらまた盛り上がるだろう。

PowerPCはRISCが流行った後で出てきたんじゃなかったっけ？
RISCの近視眼的要素を排除していたような気がしたが…

RISCの近視眼的要素って何
遅延分岐とか?

Power系統って後発だっけ？
もう記憶が曖昧・・・
Alphaはあまりに衝撃だったから良く覚えてるけど。
実物もCPUのパッケージにヒートシンク固定用のボルト生えていたり。
初期のPowerPCはまだ試作品的なレベルの、
完成度が低いものだったような・・・
Appleが調子こいて宣伝しまくったのは頭に焼き付いてる。

POWERがあってのPowerPCだから、後発といえば後発だがｗ

>>289
POWER自体もRISC界ではやや後発なほうだったかと

>>288

うん、appleのpowerPC初期の売り方はむちゃくちゃだったなあ。

・二次キャッシュがオプション
・廉価モデルは、オプションですら二次キャッシュを増設できず（＝なし）
なんて、RISCの使い方を理解できていない愚行を繰り返した。

メモリバスがむちゃくちゃ遅いのに、
二次キャッシュをメモリバスの速度に合わせたり、とか。

そういった、アップル特有のマイナス要素が
CPUの性能を無駄におとしめないようにしただけの、
内部的には603と大差がなかったG3で「劇的に高速化」

ここまで来てやっと、アップルの設計のafoさがばれたのか、
マシな設計のハードが出始めるようになった。

ああ、604は、不幸なCPUだったんだなあ...
604＋バックサイドキャッシュのCPUが出てたら、
きっと、G3以上の速さだったろうにね。（G4とは方向が全然違うけど。）

PPCの初期は不遇だね
無駄dualのBeBoxとか

>>292
>無駄dualのBeBoxとか

あれはひどい代物だったね。というかなんで603で作ったのかと。
キャッシュスヌープできないからキャッシュ殺してます。てへ。とかひどすぎ。

>>284
自分で本読めよ。

トイレネタで素人向けに説明してらんないくらい
もっと面白いことがたくさんあるぞ。

>>294
自分で本読んでるよ。
ただ真面目な記述の本だけじゃなく、たまには面白おかしく
ためになるものを…って思ったんだけど。

ttp://soundblaster.com/products/x-fi/technology/
CREATIVEの新しいオーディオプロセッサがVLIWだそうな。

>>295
ごめん。

本物の解説書を読んでると、
面白すぎて、
トイレの話を考えるもしないのは、漏れだけ?

>>296
"Thread Interleaved Multiple Data (TIMD)"だそうでつ
（左の"Cutting Edge Architecutual Design"のサブメニューから）



漏れ違いがいまいちよくわからないんだが
まぁどっちかって言うとDSPっぽいってことなんだろう・・・!?
（つーか今気づいたけどそこの小見出しが"DSP"だｗｗｗｗｗ）

一瞬、TIのOEM?とか思ってしまった訳だが。

>>295
こんなのどうだ。
http://www.uplo.net/www/vip5701.zip

CPUアーキテクチャについて語れ！
↓さあ語れ！

RISC
CISC

そしてそのハイブリッドに、
どちらとも言えないモノまで・・・

もはや区分けの概念が通用しないねえ

正直、値段がそこそこ安くて、高性能で、ソフトが豊富なら、RISCだろうがCISCだろうが
どうでもいいよもう。

どうでもいいなら、こんな過疎スレくるなよｗ

日本メーカーの富士通ががんばってるのにSPARC関係は無視ですか？

富士通、2GHzを超えるSPARC64 Vを搭載したSolarisサーバー
http://enterprise.watch.impress.co.jp/cda/hardware/2005/05/17/5266.html

SPARCはSunのおかげで"遅い"ってイメージがついてしまったからなぁ
そういうおいらはSPARC応援してるよ、うちに何台かあるし…

>>306
そうか？
研究室にいた頃同一プログラムを動かしてmicroSPARC 80MHz=Pentium 120MHzで
案外早いと思ったが

>>307
その辺の年代は、Sunって実はCPUの設計へたくそじゃないと
噂が出始めたころでしょ…
問題はその後だぁ！！

>>307
馬鹿みたいに浮動小数点演算のトロくさいIntel x86と比較されてもなぁ。
研究室ってことは浮動小数点演算の必要なプログラムを走らせていたんでしょ？

馬鹿みたいに浮動小数点演算のトロくさいIntel x86と比較できてしまうSPARC。
Intだと486で十分。
PC UNIXが流行るわけだよな。

Ultra/1(UltraSPARC 137MHzくらい?)よりも、
Pentium90MHzの自作PCのほうが速かった希ガス。

SS/5や20は486マシンで対抗できた。

>>309
いや単純なパターンマッチングのプログラムだから殆ど整数演算だけ

>>311
比較を行ったのはSun SS5(microSPARC)とEPSON Direct AT-6500だが

IOMMUが必要かどうかの件について

>>312
>いや単純なパターンマッチングのプログラムだから殆ど整数演算だけ
大量のデータを扱うなら、バスの太さに助けられた可能性はあるな。
その当時ならだいぶ差があった。

>>314
仮想化ではあったほうが便利

age

CELLって8個(PS3では7)のサブコアそれぞれに256kbのメモリがあって
メインメモリ間とはDMAで転送するってことになってるらしいけど
単に256kbx8=2Mのキャッシュ載せてメモリは共通にした方が
使い勝手もいいしパフォーマンスもさほど落ちないような気がするんだけど
そこらへんどうなの？

>>318
キャッシュx8のコヒーレンシーとってたら結構パフォーマンス落ちそう

あとソフトウェア・セル
（↑よくわかんないけどコード＆データひとまとめにしてネットワークで送るものらしい）の都合もあるんじゃない？

CISCからRISC命令へ変更するときの効率はIntelとAMDどちらがいいのかな？

ユニファイドキャッシュといえばCyrix

256KBのメモリをキャッシュではなくメインメモリとしてしまえば、キャッシュ機構が省けるよ。
タグメモリの容量だって馬鹿にならないしさ。

あーでも、むしろキャッシュを意識し制御するのが面倒だという理由のほうが大きいかもなぁ。

それだけならSH4みたいにアドレスの上位フラグいじってキャッシュをスルーする機能で十分なような。

PA-RISC, Crusoe。ばいば〜い！！

キャッシュだと、メモリからの読み込みのレイテンシが変動するじゃない。

>>320
変換効率が高いのはトランスメタでは？
...同時発行数が少ないので遅いけど。

>>321
ｲｿﾃﾙ486や、PowerPC601もだ。

保守

.NETが普及して全てのアプリがターゲットCPUに対してJITで高度に最適化されたとしたら
out of orderとかいらなくなったりするの？

>328
そりゃないんじゃね？

リンゴもIntelに屈したか。
PowerPCの今後はどうなるやら。

しばらくはゲーム機で食いつなげるんではないかと。
その先はどうなることやら。

CPUコードネーム一覧表はPCWatchにあったのですが、
CPUリングネーム一覧表がありません。
教えてください。

>>332
源氏名一覧表も必要だな

>>332
リングネームの前に入れるキャッチフレーズなら、いくつか思いつくんだけどな。
「口だけ番長」とか、「瞬間湯沸かし器」とか。

「眠ったままのスリーピングビューティ」とか「燃え尽き症候群」とか。

>>334
「ﾌﾟ」と「ロバ」だなｗ

えーと、すみません。質問です。
pentium系ＣＰＵの分岐予測にやさしいコードの研究をする事になったんですが、
pentium4の分岐予測のアルゴリズムをどなたか御存知ありませんか？
IIとIIIは資料を探し出せたのですが、4はさっぱり見つからんのです。

ftp://download.intel.co.jp/jp/developer/jpdoc/24896606_j.pdf

まあ、P6と似たようなもん。
ループのオーバーヘッドが０にできるなど、色々強化されてるが、
普通の動的分岐予測はパターンマッチングでやっている。

>>338
ありがとうございます。
Ｐ６とかの場合、ＢＴＢの各エントリにつき4bit16ヶのカウンタがあって
過去四回の履歴からカウンタを一つ選んで云々という構造だと思うのですが、
pentium4の場合も同じくカウンタは4bitなんでしょうか？

>>337
宿題は自分でやりませう。
そういうのを調べるのも研究のうちですよ。

分岐予測のヒット率を上げるよりも、
分岐のヒントを与えるアーキテクチャのCPUに、
いかにヒントを与えるかの研究のほうが・・・。

はーい。
ヒント辺りになるとますますサッパリだけど。

日本はもうまともなCPUは開発できないから学ぶだけ無駄
おとなしくPentium買っとけ。

>>342
コンパイラを作るための勉強だと思うけど。プロセッサを作るためではなくて。

ただ、そこまでやるなら自分で低級言語で書いて実験せねば。

80bitの精度を持つFPU（x87）と、64bitのSSE2では、
ハードウエアの負担はどのぐらい違うもの？

>>342
富士通のSPARC64 VはまともなCPUだと思うが・・・

まともなCPUだ！と言い切れｗ

VRもTXもそれなりに元気だけど、独自アーキはぱっとしないよね。
FRVとかどうなるのかねぇ。

SPARCっていつから富士通のものになったのさ。

太陽が沈みかけたからｗ

>>349
SPARCの命令セットや仕様わオープンす。
http://www.sparc.org/japanese/faq.html
　　------------------------
　　･ SPARCの命令セットはIEEE 標準1754-1994 として公開されている。

　　・ SPARCは，誰でもでもどのような会社でもライセンスを受けることが出来，自分自身に適したものを
　　　作れる柔軟性と自由度があ る。

　　・ SPARCアーキテクチャの決定権は，独立した非営利組織であ るSPARCインタナショナルが持って
　　　おり，誰でも会員になって仕様決定に参画できる。
　　------------------------

>>351
国際スパーク株式会社。ｗ
たのむから日本語のページは紹介しないでくれｗ

富士通、2GHzを超えるSPARC64 Vを搭載したSolarisサーバー
http://enterprise.watch.impress.co.jp/cda/hardware/2005/05/17/5266.html

IBM eServer p5 595 (1900 MHz, 1 CPU)
http://www.spec.org/osg/cpu2000/results/res2005q1/cpu2000-20050207-03774.html

Fujitsu Limited
PRIMEPOWER900 (2160MHz)
http://www.spec.org/cpu2000/results/res2005q2/cpu2000-20050419-04024.html

Itanium 2 is obsolete.
good bye, Itanium series.

LOL

lol

Intel迷走中

もう迷走はしてないでしょ
着地点（PenM系）はわかってるわけだし
着地するまで、どうごまかしてPen4系を売るかってだけ

LoL

↑って何？

Lack of Love

てゲームがあったな。

LoL

>>357
それに加えてPentium M系がEM64T対応ではないことをどうごまかして売るかってのもある
来年、Meromが出荷されたとたんEM64Tマンセーの宣伝しそうで怖い

MeromのEM64Tはまともな実装になってるのか？

Meromはコアが２個あるので64bit級！！！

>>364
S○GAのSSみたいだな。

コア二つなら2倍でしょ？
33bitじゃん

32bitCPUが何個集まろうと32bitだろうがばーか

>>367
>>364

Transmetaも
「32bitVLIW実行ユニットが4個あるから128bit」
なこと言ってなかった?

あれは命令幅のことだろ。

「製造プロセスルール」って言う場合、
「描画チャネル長」と「実効チャネル長」のどちらを言ってるのでしょうか？

ちゃんと決まってはいない。

○○ミクロンっていうのは、
その工場のデザインルールを識別するためのタイトルみたいなものだから。

A社の90nmのデザインルールと、
B社の90nmのデザインルールは、
まるで違っていると思ったほうがいい。
へたしたら、A社の90nmはB社の130nmに近かったり・・・。

>>372
thx。驚きました。
ってことは異なる企業が90nmプロセスルールと言ってても比べる事できないって事ですね。
でも推測くらいはできるのかな？？

貴重なスレだ
勉強になるので上げます

>>373
ttp://www.atmarkit.co.jp/fsys/keyword/015silicon_basic/015silicon_basic.html

普通はリソグラフィをいうから、比べられないってことにはならんと思うが。
比べたらいろいろ違うけどね。ウエハサイズ、素材、実効ゲート長、速度、
リーク、などなど・・・。

保守

VLIWについて、聞きたいです。

知ってる方　何かもってる情報・知識を話してください。

いくらなんでも漠然としすぎ

>>378
それを承知で言ってます。

VLIWについては教科書にも書かれているくらい歴史のある技術だから、
まずは学校の図書館にでも行ってみよう。

>>379
>>>378
>それを承知で言ってます。

http://www.google.com/search?hl=ja&lr=lang_ja&ie=UTF-8&oe=UTF-8&q=VLIW&num=50

>>380,381

寒っ。。
話題ねーから、話題ふってやったのに。

>>382
>378

>>383
>379

話の振り方が下手くそだったんで誰も食いつかなかっただけだろ。
次はがんばれ。面白いのを期待している。

前スレのトイレ解説だっけ?
そんな感じでVLIWについて書いてくれｗ

所詮　自作PC板って事だな。
一般的なアーキテクチャの話ができず、メーカー厨の煽りあいしか　できねーってことがよくわかったぜ。
糞だな

つまんないオチだな。

>>387
データフローマシンについて語ってください。

マルチメディア処理をなんとかしろ! といいたいよ。
ハードウェアエンコーダ・デコーダとの性能差がありすぎ。

GPUでやりましょうっていう話もあるけど、
普通のプログラムから気軽に使えないので嫌なんだよね。

>>382
宿題は自分でやろうな。

>>387
語りたいなら存分に語ればいいよ。
それを聞く香具師はいくらでもいる。
おまいのはメーカー厨の煽り以下だってこと分かってる？

糞スレええ　うぜええええええええ！！！！

ふきだまりだなああ
まともな奴でてこいよおおお

まぁ、夏休みも残りすくないしなぁ…。
お子様うざいなぁ…。

>>392
>385

ほんとに糞だなｗ
会話またとまっちゃったよｗ
自作スレじゃＬＶ低すぎて何も話できないから、終了だな。もう保守するなよ。

モンクあるやつは、スレタイにあるように何かアーキテクチャ語ってからモンク言えっ！！

>>395
オマエモナー

>>396
>モンクあるやつは、スレタイにあるように何かアーキテクチャ語ってからモンク言えっ！！

>>397
>397

>>395
じゃ、シストリックアレイについて語ってください。

400

>>396　>>398>>399
おまえら、頭低すぎ、釣られすぎww

んじゃ Merom か Yonah では？

>>401
この板に来るような奴がメル欄に気付かないわけないだろw
吊られてるって

あーあ、言っちゃった
お前の負け>>403

>>404
いいから、スタックマシンについて語れや。

push >>404

もう釣りごっこは要らね。
話題が無いなら無いで構わん。
良スレつぶすのは勿体ない。

Meromのパイプラインやけに短いけどあれで2GHz超えって
かなり頑張ってるんじゃあるまいか

2GHz超えのﾄﾞﾀｰﾝよりは長いだろw

>>408
14段がやけに短いって？
4段で2GHz超えしてるCPUもあるんですがｗ

14段深すぎだろｗｗｗｗｗｗ

>>410
ちなみにその4段のCPU名は？
x86系はデコーダ(及びアウトオブオーダ)が複雑な関係で段数が長くなることが宿命付けられてるけど

http://pcweb.mycom.co.jp/news/2002/10/28/16.html
http://web.archive.org/web/20041123080253/http://ne.nikkeibp.co.jp/NE/2002/021202/gp.html
halla ARM V5 samsung 1.2GHz

日経エレクトロニクスの記事は
> ARMのシフトと加算を同時に行う命令を、1クロックで実行する必要がある（ライセンスの関係でパイプラインを変更できない）
> ので演算ユニットが倍速で動いている。
という内容だった.。

演算ユニットは2GHzを超えているが,、CPUとしては1.2GHzだ。

#K8がfetchからL1キャッシュアクセスまでで12段なので、14段は特に短いとは思わない。

>>412
K8だって浅い訳じゃないだろ。
12段だってかなり深い。

Netburstのせいで、感覚が麻痺してきてるんじゃないのか？

ちなみにPentiumIIIが12段、Itanium2が8段。

Itanium2はOOOやらないので、他よりも段数少な目。
Itaniumでは10段だったのが、2段減ってクロックが若干上がった。
これはどう見るべきだろう。

IA64はまず実機が存在しないところから始まったので、Itaniumは出来るだけ
早期に実機環境を整備することを目的に工程最優先で開発したため、設計の
最適化は手付かずだったということだと思うけど。
実際Itanium2はItaniumの改良ではなく、平行して開発が進められたという話
だったはず。

Itaniumのスケジュールが遅れたから、
Itaniumの出荷前にItanium2の話が出てたような気がするし、
Itaniumの出荷からわずか1年後にItanium2が出荷されたよね。

Itaniumはサンプルが出てから出荷まで数年かかってて、
トラブルの対処に関係ないスタッフは次の仕事に取り掛かれたはず。

>Itaniumの出荷前にItanium2の話が出てたような気がするし、
>Itaniumの出荷からわずか1年後にItanium2が出荷されたよね。
これって常にIntelにある話で、且つIntelのCPUの値段を吊り上げてる原因の一つなんだよね

出荷前に、
ソケットが変わる
内部ユニットの構成が変わる
なんてアナウンスしたら、そりゃぁもう。

Windowsを動かすデモしてから、出荷まで何年かかったんだっけ?

学校の宿題なんですけど・・・

IBM System 360

特徴　　

Model 30 Processor cycle time 1.0 Relative speed 1
------------------------------------------------
Model 75 Processor cycle time 0.2 Relative speed 50

問題
　　　　Model75　のパフォーマンス(Relative speed )が　
　　　　Model 30の50倍であるのに対し、
　　　　Model75 の Processor cycle time は　たったの5倍である。
　　　　この矛盾をどう説明しますか？

　　という問題なんですけど。

この矛盾説明できますか？
　　

矛盾つーかパラメータが足りないだけじゃん



ｽｰﾊﾟｰｽｹｰﾗとかﾍﾞｸﾀﾗｲｽﾞとか

基礎中の基礎だな。CPI

>>420
360だぞ

>>419
そうしないと売れないから

>>419
宿題は自分でやれ。

どっちかのタイマが狂ってる。

>>419
宿題なら、「IBMの広報が一流だったから」と書いて提出汁。

自信が無かったら、
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS360B.html
このあたりの数字を適当にいじって提出汁。

ところで、サイクルタイムだが、
　　　model30 750ns
　　　model75 195ns
その差3.846倍。5倍ってどこから出た数字なのだろう。

Processor cycle timeだからクロックでない?

パタヘネ2上 出版社在庫切れ、重版予定なしだと
欲しいやつは今のうちに本屋の在庫買っとけよ

>>428
こういった本を打ち止めにするとはなあ。
出版社のやる気の無さが日本のCPU技術を衰退させていく。

第二版の翻訳本が絶版になるのは構わない。
第三版の翻訳本が出ればね。

CPU技術を担って行くような奴が翻訳本なんか必要とするわけがない。

だな。

原著で読めない大学生なんていないだろ。
俺が学生の頃は翻訳本なんてなかったけど、問題なかった。
シンドイのは英語を読むことではなく、洋書の値段が高く、入手しにくいことだった。

>>432
学生時代、関数群とかやったが、参考になる本がなくて
教授から渡された本は英語…('A`)…という事は確かにあった(藁

CPUサイクルタイムが5倍って遅くなってないか？

っていうネタは置いといて、
パタヘネ上下買うぐらいならヘネパタ買ったほうがいいんじゃないか？

>>1 質問だがこのスレはプロレス板と、
どういう関係があるのですか？ 全く関係ないと思いますが…

プロレス板？

>>435 質問だがこのレスはこのスレッド及び自作板と、
どういう関係があるのですか？ 全く関係ないと思いますが…

なんか、このコピペ流行ってるみたいだね
なにが面白いんだろ？

「ItaniumとXeonの価値を提案」−インテルが語るエンタープライズ戦略
http://enterprise.watch.impress.co.jp/cda/topic/2005/10/06/6292.html

ほす

ジーオンはなうなるかもしれないよ。
あんなぼったくりCPUなんていらないよ。

市場調査会社米Current Analysisが10月14日発表した統計によると、
米国のデスクトップPC向けプロセッサで9月にAMDが過半数のシェア
を確保し、Intelから首位を奪取した。

9月に米国で小売り販売されたデスクトップPC向けプロセッサのシェアは
AMDが52％となり、Intelの46％を上回った。
AMDはこれまでにも一時的にデスクトップ用プロセッサで
Intelをしのぐことはあったが、月間を通じてIntelの売り上げを上回ったのは
この9月が初めてだという。
http://www.itmedia.co.jp/news/articles/0510/15/news002.html

前スレ見たいなぁ。
誰かログうｐできませんか・・・

金払え or 検索しろ

検索してトイレの例え話を読んでから金払った。

すげぇ面白い。
89年頃に雑誌で研究中として紹介されてた技術が
民生品として出てきてるのか・・・。

これからレス見ながら検索等して個人的お楽しみとして勉強するわ。

Power.orgはちゃんと機能してるみたいだね

低消費電力型Powerチップ、米新興企業が開発へ
http://japan.cnet.com/news/ent/story/0,2000047623,20089470,00.htm

Itaniumのスレってなくなっちゃったの？

【IA-64】Itanium2専用スレ・その4【アイテニアム】
http://pc8.2ch.net/test/read.cgi/hard/1126713905/

ARM、ハイエンドプロセッサコアの技術内容を公表
ttp://pc.watch.impress.co.jp/docs/2005/1026/fpf02.htm

このスレもハードウエア板向けなんだけどね。

電電スレでは？

いや、電電板だった

旬の過ぎた平成電電のことか?

ほす

どうしてNECがx86互換CPUを作らなくなったのはアメリカ政府から圧力をかけられたからだよ。

どうして455が変なのは文法的におかしいからだよ。

どうしてNECがx86互換CPUを作らなくなったのはアメリカ政府から圧力をかけられたのはなぜ？

どうしてなのッ?
どうしてx86互換CPUを作らないの───ッ!?

NECエレクチオニクスに改名する。

>>457
イソテルのロビー活動

さぁCPUアーキテクチャについて語れ

atya-

アーキテクチャってなんですか？

agetoku

このスレはメンテナンスモードに移行しました
以後、保守書き込みを禁止します
速やかにDat落ちするようご協力願います

m9（^Д^）ﾌﾟｷﾞｬｰ

トイレネタ思いついたときに書き込めなくなるのは嫌だからAge

前スレから神的内容だからな
保存してある

MACヲタが出てくるスレは廃れる。

最近RISCのシンプルなコアを8個集積とかがはやってるが、こーゆーのも
命令セットだけはEfficeonみたいな可変長VLIWにしたほうが、メリットあ
るんじゃないかな。
１：可変スロット長の遅延ロードや遅延分岐とみなせる
２：データフォワード回路抜きで、直前の命令で使ったレジスタを使える
３：IPCの高いバージョンを出すときに、スーパースカラより有利

>>471
VLIWは今までの資産が使えん。コンパイラも難しい。

>２：データフォワード回路抜きで、直前の命令で使ったレジスタを使える
インターロックはするよ。

>３：IPCの高いバージョンを出すときに、スーパースカラより有利
issueが変わるとバイナリ互換性がなくなるって知ってる？
＃いやまぁ、8issueのマシンで4issueのバイナリは動くけど、
＃残りの4issueは"常に"遊ぶことになるからねぇ。それじゃ増やした意味はなし。

>472
１：資産はCELLの9個のSPEの方にも無い。最適化コンパイラはIA-64以外でもTIのDSPで実用化ずみ。
２：インターロックは費やすトランジスタが同等なら、RISC比で多少は減らせるはず。
　　節約に回すか、高性能を目指すかは目的次第。
３：最初からRISCの８命令相当の命令セットで最適化してコンパイルしておくので、
　　8命令相当のVLIW命令なら、8issue機なら１クロックで実行、４issue
　　なら２クロックで実行になる。３命令相当命令ならどっちも１クロックだが、
　　1issue機なら3クロックになる。

>>473
>１：資産はCELLの9個のSPEの方にも無い。最適化コンパイラはIA-64以外でもTIのDSPで実用化ずみ。
CELL限定の話をしていたのですか？知りませんでした。

ちなみにVLIWのマルチコアプロセッサというものもあるのはなんででしょうね。

>２：インターロックは費やすトランジスタが同等なら、RISC比で多少は減らせるはず。
>　　節約に回すか、高性能を目指すかは目的次第。
意味不明

>３：最初からRISCの８命令相当の命令セットで最適化してコンパイルしておくので、
>　　8命令相当のVLIW命令なら、8issue機なら１クロックで実行、４issue
>　　なら２クロックで実行になる。３命令相当命令ならどっちも１クロックだが、
>　　1issue機なら3クロックになる。

1.8issue用の命令を3回にばらして実行したも同じ結果になりません。
＃1VLIW命令を実行するたびにレジスタにライトバックするからね。
2.8issue用の命令列をいくつにばらせば2issue用になるのか、命令の
詰め具合によって違います(ばらさないですむかもしれないし8つにばらさないと
いけないかもしれません)。それを実行中に判定するというのは、パッキングを
動的にやりなおすのと等価です。
実行時にそんな重いことをしたらVLIWの意味がありません。
3.8issue用命令をアーキテクチャとして定義し、2命令同時発行マシンでもそれを
実行できるように作ったとしましょう。単純に8issue版の1/4の速度で動く8issue版の
1/4よりはるかに大きいコアが出来上がるでしょう。
ついでに将来16issueなプロセッサが出たときに破綻します。

質問だがPen4やらAth64の一次データキャッシュ、二次キャッシュは共に
256bit/cycleで、周波数=CPUの周波数でOK？
帯域は一次も二次も同じだけどヒット率とレイテンシで重視する方が違うから分けている、という認識でよいのだろうか？

>>475
違う。説明するよりググった方が早いかも。

>>476
いろいろ検索してみたけどキャッシュの容量ばかりで帯域とかなかなか見つからないorz

Pen4のL2が256bits/cycleで周波数がCPUと同じという記述は見つけました
L1については256bits/cycleらしいですが、初期のデータでロードレイテンシが2クロック時のです。
確かNorthwoodまでが2クロックでPrescottになって4クロックになったんで帯域が今のと合ってるのかは分かりませんでした。

Athlon64についてはL1データキャッシュがTwo 64-bit operations per cycle,らしいのですがPen4の半分の128bits/cycleということでしょうか？
L2帯域の記述は見つけられませんでした。

訂正、補足お願いします。

>Athlon64についてはL1データキャッシュがTwo 64-bit operations per cycle,らしいのですがPen4の半分の128bits/cycleということでしょうか？
>L2帯域の記述は見つけられませんでした。

うん、そうだよ。等速のL2がK7の64BitからK8で128Bitになった。

>>478
サンクス！！

Pen4とAth64でクロックも考慮するとキャッシュ帯域で3倍近い差があったのか・・・・
Ath64ってかなり効率のいいなぁ

米Sun、8コアの省電力最新SPARCプロセッサを発表
http://enterprise.watch.impress.co.jp/cda/foreign/2005/11/15/6605.html

Spring Processor Forum 2005レポート　〜Sun Niagaraともう1つのメニイコア
http://pc.watch.impress.co.jp/docs/2005/0531/spf07.htm

＞UltraSPARC T1は「Niagara」という開発コードネームで呼ばれてきたCPUで、
＞90ナノメートルプロセスで製造し、単一チップ上に8個のコアを持つ。
＞それぞれのコアは4つのスレッドを同時実行可能で、計32のスレッドを同時に実行できる。
＞4つのメモリコントローラをオンチップで搭載した。
＞動作周波数は 1.2GHzだがパフォーマンスは9.6GHzに匹敵するという。

Niagaraはメモリのレイテンシを隠蔽するからこそ、
メモリのレイテンシより帯域幅を優先するために、
Out of Orderのメモリアクセスとか、できるんだよね。

なんか>>480の下の記事、文章が変だなと思ったら、書いたのは大原かよ。

大原は知ったかぶりライターで、↓のスレで叩かれてるぞ。

知ったかぶり雑誌ライターの間違いを正すスレ
http://pc7.2ch.net/test/read.cgi/jisaku/1130742036/

Niagara売り込み用のキャッチーなフレーズではあるけど
Sunの中の人がこんなこと言う時代になったんだー

マイクロプロセッサに死が迫っている？
http://www.itmedia.co.jp/enterprise/articles/0511/16/news030.html

>>482
大原氏わ、しっかりした経歴のヒトす。
http://www.yusuke-ohara.com/profile.htm
しったかぶりとか叩いてるのわ、技術的内容よりAMDを褒めてるかどうかで記事の質を判断してるアム虫位す(笑)

経歴だけで知ったかぶりで無いと判断するのは、問題ありだろ。
「しっかりした」経歴の基準もわからんしな。
良ければ基準を明らかにしてけれ

>>483
いや。Sunはjavaの売り文句とかみてわかるように昔からそういう煽りをかます会社なんだってば。

大原がクロックスキューのことディレイって書いてたときは、ちょっとあきれた
ただ、たまにそういう間違いやらかすだけで、書いてることはわりとまともだと思う

>>484
>技術的内容よりAMDを褒めてるかどうかで記事の質を判断してる
>>487

禿同

PapadopoulosがNiagaraを持ち上げてるのか。
感慨深いものがあるな。

>>487
まともじゃないよ。

Niagara
　先は流れて
　　落ちるだけ

大原氏は自分で書いてる通り実験系で，ハード/ソフト共にきちんとした教育/勉強を
してないのが弱点．その代わり頭でっかちな机上の空論をかますことはない．

理論をしっかり学んでいないやつに未来はないよ。

素人の実験ほど、迷惑なものは無いな。

素人の実験で迷惑な例としてはさ
原子力発電所の近くの海岸でとった岩海苔にガイガーカウンターあてる実験
というのがあるんよ。

日本全国で取れる岩海苔に含まれる放射能の量の分布を知らないので、
原発のせいだと大騒ぎするわけだけど、海水を濃縮する海苔に放射能が
含まれているのは、原発ができる前からのことなわけで・・・。

プロになると確信犯で都合のよい結果が出るように実験設定をするようになるがなw
疎水性の毒物の土壌中濃度を測るときに、わざわざ土壌サンプルを深くまでとったりとかな
で、体積あたりの量は少なくなって環境基準クリア。
ターゲットになってる物質はごく表層にしかないんだから面積あたりで評価すべきなのに。

確信犯の意味間違ってない？

ﾊｲﾊｲﾜﾛｽﾜﾛｽ
小学校で国語でも教えたら？

ソースコード付きで実験をやってくれれば
こちらで判断できるから、その方がいいな。

アセンブリのコードが晒されてないベンチなんて
何が作用してるかわかったもんじゃない。

「バイナリが再現できない」
「ベンチ結果が再現できない」
騒ぎにハッテンする罠

SPARC以来のブレークスルー、エコ・チップ搭載「Sun Fire CoolThreadsサーバ」
http://www.itmedia.co.jp/enterprise/articles/0512/07/news049.html

WinChip C6コアを32個搭載したCPUｷﾎﾞﾝﾇ。

ﾊｲﾊｲﾜﾛｽﾜﾛｽの使い方間違ってない？

まぁなんだ、下がりすぎ。

952 ：Socket774：2005/12/27(火) 17:00:21 ID:de5D9DXp
議論に負けると、逆ギレですか、インテルの工作員さん？

969 ：Socket774：2005/12/27(火) 17:27:49 ID:nHaFDWcF
>968
ｽﾏﾝｗ IP２つで遊んでみたｗ
ID:nHaFDWcF
ID:de5D9DXp

猿のオナニーじゃあるまいし。 ずっと読んでりゃ流れは分かるんだから。
すごく読みにくい。スレ汚し。

979 ：Socket774：2005/12/27(火) 16:49:26 ID:nHaFDWcF
＞ID:de5D9DXp
工作員って言うか、俺とお前はペアだろ。俺が居てのお前、
お前が居ての俺だからな。俺はそう心得てる。

974 ：ゲイツ ◆G6Ju/wt08s ：2005/12/27(火) 17:32:30 ID:de5D9DXp
>>969
似非ジョブズ　ID:nHaFDWcF　君！
ジサクジエーン　ハケーン
オレと同じトリップ出して見せてくださいｗ

976 ：ジョブス ◆CSZ6G0yP9Q ：2005/12/27(火) 17:33:58 ID:nHaFDWcF
やだね。

978 ：ジョブス ◆CSZ6G0yP9Q ：2005/12/27(火) 17:35:55 ID:nHaFDWcF
Intelの暗躍とアム厨の死亡

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

インテル工作員墓穴を掘る、嘘つき。

RISCの方がいいのになぁ。
やっぱWindowsの力が強すぎなんだ。
Dvorak配列が一般化しなかったように良いものが残っていくとは限らないのか。

>良いものが残っていくとは限らないのか。

だから君も残っていられるんだし。

x86信者乙
というか、世界が広すぎて、井戸から出られないカエルか

無知な漏れに教えてください
CISCの代表がPentiumやAthlon
RISCがPowerPCやARM SH
であってます？

RISCもCISCもねぇよ

今のCISCはRISC的要素を採用してきているから大分変わっている。
Windowsのおかげでたっぷり開発費をかけられる分、
CISCは発熱等問題点も多いのにもかかわらず独占状態になっている。

>>509
>CISCの代表がPentiumやAthlon
内部でRISCに変換してるよ。

自称RISCもCISIC並にアドレッシングモードや命令が増えてるけどな

とりあえずMeromは期待大。
やっぱり省電力、低発熱じゃないとダメだわ。

>>513
しかしパイプラインたくさん使ってRISC的処理をするCISCに変更してるんじゃ効率悪い。

そこでトレースキャッシュですっぜダンナ！
分岐予測が外れると禿しくorz

ARMやPowerPCはRISCにしては複雑な方だね。特にARMはRISCとは思えないぐらい。
まだMIPSやSPARCの方がRISC的

今や、RISC、CISCの枠付け自体が意味をなさなくなってきてるのだよ。

まぁPowerPCもG5ではさらに内部RISC命令に分割して実行していたりするしね。

それでも歴史的には意味があるだろう。あるいはISA的に。

後藤さんのコラムに書いてあったけど
今まで高速化のCISC→RISC的なアプローチから
今度は効率化のRISC→CISC的なアプローチへ
先祖返りするかも？みたいな事が書かれていて面白かった。
μOPsフュージョンとか確かにそうだよな。
それとアシンメトリックなマルチコアを組み合わせるとどうなっていくんだろうね。

結局、CISC、RISCなんて線引きはRISC派のディベート戦術みたいなもので、
実際の設計としてはCISCとRISCの間にいくらでも解があるわけよ。

RISCと称する設計ですら今じゃ複雑な命令の実装にはマイクロコードを
使ってるわけでさ。最初にMIPSやSPARCをやり始めた連中がみたら（つか、
生きてるから見てるだろうが）怒るのか苦笑するのか見てみたいよ。

>>520
希望的妄想としてはエミュレーションマシンが来ないかと。
マイクロコードでアプリケーションに特化した命令を皆がガンガン書くと。

ARMがCISC化していってるのはプログラムサイズを抑えるためだし。
用途によって手段は変わっていくもんだねぇ

ゆり戻しなんて良くある話。

>>513 さん
　　-----------------------
　　自称RISCもCISIC並にアドレッシングモードや命令が増えてるけどな
　　-----------------------
アドレシングモードが増えてるって話わ初耳すけど。。。
>>519
　　-----------------------
　　まぁPowerPCもG5ではさらに内部RISC命令に分割して実行していたりするしね。
　　-----------------------
POWER4/PPC970でcrackingやmillicodingが行われている命令わ，非常に初期(603時代)
とかのマニュアルから「将来この命令わ実装が変わって高速で実行できない可能性が
ある」と予告されていたモノが多いす。
>>520
uOPs Fusionのような命令のペアリングとRISCわ概念的に随分違うモノす。つーか，
文系ライタの後藤氏に技術に関する定見わ無いってことを頭に置いておいた方が良いかと。。。

VLIWはどうよ。

>>525
コンパイラしだい。

っていうかWindowsがついた者勝ち
良さよりも優先されますから

>>527
腐れ縁だよな

IA-64はWindowsがついたのに負けましたよ。

そりゃあ、Windowsは他にもあるからなｗ
POWER版Windowsがまた復活しないかな…

Alpha版とAlphaAXPの復活キボン。

Mips版も忘れないでください…

でもWindowsCEじゃｿｺｿｺ

Windows無くてもいいです

MACヲタも文型ヲッチャー

>>532
もはやWindowsCEでもARMなマシンばかりですよ、一般に手に入るのは。
なんせPocketPCではARM以外はダメという縛りがあるから。

>>509
CISCの代表っつったら、VAX、HP3000、TRONプロセッサ、javaプロセッサ
なんかに決まってるだろ
IA-32なんて古典CISCから見たらシンプルな命令
x87のスタックは真のRISCらしけど

RISCといえば、i960とMC88000。

>>536
RISCとスタックマシンは違う。

>>538
真のCISCの間違い

CISCといったら68000だろ。

>>540
VAX!

6502

>>542
世界一普及した石かもしれん。

↑？
大量採用されたのってなんかあったっけ。
ファミコンはRICOH RP2A03、PCエンジンはハドソンHu6280だよな。

>>544
ファミコン6502じゃなかったっけ

ファミコンの石は6502改で、正式名称RP2A03で良いのか?

GameCubeのGekkoはPPC G3ベースのカスタムCPUで、FPUで32bit浮動小数×2のSIMDに対応、だったっけ。

製造元の名称ではPowerPC750CXベースと言われている

>>546
そうなんだろうけど、改も含めていいんだったら
4004とか8086とかあのあたりが一番、と言い張られるんだろうな。

>>549
4004がそんなに売れているとは...。
8086にしてもPCに(基本的に)一個づつでしかないしな。たいした数じゃない。

Intelなら8048〜51互換の方がよほど多く使われていると思うが。

>>550
改も含めて、と断っているんだからどういうネタか汲んではくれまいか……

>>551
改を含めてもそんなものだといっているのが理解できないのだろうか？

4004がセカンドソース(あったっけ？)を入れてもバカ売れとは思えないし。
組み込みで使われる数量と比べたらPCの販売数なんてたいしたことないし。
Intel製の8048-51がそんなに使われてるわけもないし(→当然コンパチ品を含めての話)。

>>549
改を含めてというネタなら8080のが6502より売れてるでしょ。
8085･Z80・64180およびそれらの組み込み用やASIC Cellまで入ってるし。
NTTのグレ電にもZ80コンパチ入ってたし。

でもそれらよりも携帯に使われてるCPUのが数はでてんじゃないかなぁ。
ARMは6502だって言われたら知らないｗ

>>552
いや、ネタだと言っているのでツッコむにしろ面白い方向に誘導して欲しいのだが。
累計総生産数のデータをこっちは持ってないので間違ってても全然不思議じゃないが。
>>553
ほう……Z80がそんなところで使われているとは。
メガドライバーやネオジオな人もさぞ喜んでいる事だろう。

>>554
>いや、ネタだと言っているのでツッコむにしろ面白い方向に誘導して欲しいのだが。

面白い面白くない以前の問題なんだが。
自分がどれだけ間抜けでデタラメなことを言ってるかわかってる？
己の無知さ加減を自覚してほしいね。

端的にいうと「バカは引っ込んでろ」だ。

>>555
デタラメなこといってる奴がいるならそれこそ面白くしようがあると思うが。

で、話を戻すとCISCの代表の話だっけ？
俺は勉強がてらこのスレ来てるだけだから５５５にCISCの代表を選んで欲しい。
こんな無駄レスでスレ消費しても仕方ないし、少なくとも俺より知識がありそうだし。

ちなみにだけど、
6502改のファミコン世界累計販売数が約6300万台、
Z80改（アドバンスはARM+Z80)のゲームボーイ世界累計販売数が約一億2千万台。
携帯電話は種類豊富で6億台突破

4004って古いマウスやキーボードのなかに使われたたんじゃないの?
半分想像だけど
携帯電話や携帯ゲーム機と、その他の組み込み
どちらが多いか気になるところ

>>556
CISCの代表と言うなら、S/370やVAXあたりの、
旧世代（マイクロプロセッサ以前）の代表的な香具師、
じゃないのかな。年寄りは引っ込んでろ！的な主張を
当時は感じた。それで行くと、RISCも年を取り、CISCも
若者ファッションを取り入れて若返った、ような気がする。

販売台数と命令セットの複雑さからいって、VAXで鉄板だろ
68000がシンプルに見えるくらい、複雑怪奇な命令体系だからな
マイクロプロセッサでCISCといえば68000だけど、これより複雑な命令のものは
いくつかあった
しかし、全て黒歴史の闇に葬りさられてる
ｉAPX432なんかが黒歴史CISCの代表だろうな

>>559
IA-32は複雑な可変長フォーマットと、レジスタの極端な少なさを除けば
遅くなるような命令体系じゃないからな
μops変換で十分対応できる

>>556
バカはバカだってことにも気がつかないし、バカだって言われてもわからんものなのか？
面白い面白くないって問題じゃないってことすらわかってないんだからなぁ

もう一度いうわ。
「バカは黙って引っ込んでろ」
二度と出てくるな。

>>561
おまえモナー。

どこがどうでたらめか、説明してみ？
どうせできないんだろ？ｗ

>>558
4004はふるーーーーい電卓用プロセッサ。

>4004って古いマウスやキーボードのなかに使われたたんじゃないの?
そんな新しいものには入っていない。

>半分想像だけど
君はでたらめの事を「想像」というのか？

>携帯電話や携帯ゲーム機と、その他の組み込み
>どちらが多いか気になるところ

そりゃその他の方が多いに決まっているだろう。

>>559
CISCなんてRISC陣営が「RISC以外のプロセッサ」につけた名前なんだから
代表とか何とかいうのはナンセンスだと思うけどね。

>>560
>IA-32は複雑な可変長フォーマットと、レジスタの極端な少なさを除けば
>遅くなるような命令体系じゃないからな

それ以外にISA的に遅くなる要因があるなら教えてくれ。

>>562
>550 >552 で説明済。

煽るならちゃんと読んでから煽れ。

改も含めてってこういうのも含めたらどうなっちゃうんだろう。
http://www.silabs.com/tgwWebApp/public/web_content/products/Microcontrollers/en/index.htm

ルネサス（三菱電機+日立）って半導体世界3位だけど、ここって組み込みプロセッサ専門だよね。
M16Cとかって個数ベースならIntel超えてることない？

過去の資産なしで考えるならPowerアーキテクチャが現状最強なのかな。
CellのSPEの命令セットや内部アーキテクチャ（演算ユニットのパイプライン構成とか）は
PPC970をかなり手本にしてるっぽいし。

>>565
8051と書いたときにはそういうのも念頭にあった。
ほかにもUSBカードリーダにコントローラに埋め込まれていたりもする＜8051互換

>553辺りは川鉄のバカみたいに速いZ80コアなんかも考えているのではないかと思った。

このクラスの石だと命令セットの拡張なんて無駄なことはしなかったりするね。
どうせ独自拡張なんかしても誰も使わないから。
＃64180なんかも結局拡張命令(掛け算とか)なんて使われてなかったようだし。

>>566
>CellのSPEの命令セットや内部アーキテクチャ（演算ユニットのパイプライン構成とか）は
>PPC970をかなり手本にしてるっぽいし。

そうか？
レジスタの本数も命令セットもぜんぜん違うようにしか見えんのだが。
＃ttp://pc.watch.impress.co.jp/docs/2005/0212/kaigai156.htm
＃を読むと内部アーキはPPCのVMX似だとはあるけど。
＃それをPPC970似というのはミスリードだと思うが。

>>568
いや、命令のフォーマットもかなり似てるよ。手元にSONYとIBMそれぞれから落とした資料あるけど。
まぁ、レジスタをあらわすビットは確かに2bit分多くなってるね。
直に叩けるメモリ空間がローカルストアの分しかないから、その分レジスタ増やせたんだと思う。
逆に言えばローカルストアの容量は結構ギリギリ。

あと、VMXとSPEのSIMD命令は、完全ではないけどほぼ１：１で対応してる。
ビット置換系の命令がややプアになってるけど。

似てるといっても6種類あるけどねｗ




ごめん、こりゃ別物に近いｗｗｗ
ニーモニックレベルでは近いんだけど。

>>561
だからさぁ、知識が足りなくて一度間違えたヤツと、
ユーモアを解さずセンスのないツッコみしか出来んヤツとどっちが馬鹿なのよ？
>>568-570
IBMが入ってるからPowerPC系だとばかり思ってた。魔改造ってこと？
どうでもいいけどEEの時も展開考えてるみたいなこと言ってたけど全然でしょ。
今回もよそに売る気は無いだろうね。

POWERの中なら、Freescaleのe600コアが最強だな、現状では。
e600は延命されてまだまだ新製品が出るらしいから、e700はずっと後か

>>571
>だからさぁ、知識が足りなくて一度間違えたヤツと、
>ユーモアを解さずセンスのないツッコみしか出来んヤツとどっちが馬鹿なのよ？

どの辺りがユーモアなのかさっぱりわからないんだけど。
自分の無知を「ユーモアだから」とかいってずーっとごまかし続ける奴が一番バカだと思うね。
自分の間違いを訂正してくれた人に向かってめちゃめちゃ失礼だと思う。

>>572
POWER ≠ PowerPC

何を持って「最強」といってるのかわからんけどFreescaleは組み込みにシフトしてるから
パワー的にはそこそこで踏みとどまってるね。
＃とはいっても1GHz台半ば3000MIPSレベルだからたいしたものだけど。

>>574
残念ながらPOWER = PowerPCす。
本家IBMですら、POWERアーキテクチャわPOWER2で滅亡してPOWER3以降わPPC ISAなんすよ(笑)
http://www.decisionjapan.co.jp/dj/unigram/442p1.html

正月で暇なら、IBM公式のPowerPCの歴史を読むのも一興かと思うす。
都合の悪いことは書いてないので、これが全てって訳じゃ無いすけど。。。

http://www-06.ibm.com/jp/servers/aix/developer/feature/power10/index.html

>>572
最近別の所からPWRficientというのも出てきたようだが
あれが予定通り８コアで成功すれば勝てる？　かも。
>>573
恩着せがましい。

AM２９００シリーズはどうなったの？
昔仕事で使い始める予定で勉強をしてたんだけど
客先がつぶれてそれきりんなった。

>>575
>残念ながらPOWER = PowerPCす。
>本家IBMですら、POWERアーキテクチャわPOWER2で滅亡してPOWER3以降わPPC ISAなんすよ(笑)

リンク先の記事を見てもそうは読めないが。

たしかにPOWER3はPOWER2/PowerPCどちらのアーキテクチャにも互換があるが、
同一なわけではない。

まぁ少なくともe600はPOWERじゃない。

>>578
>>>573
>恩着せがましい。

ハァ？誰に向かっていってるの？
なんか勘違いしてない？

>>580
　　-----------------
　　リンク先の記事を見てもそうは読めないが。
　　-----------------
読解力が無いか、POWER ISAが何なのか知らないかのどちらかすね(笑)
http://www-06.ibm.com/jp/servers/aix/developer/feature/power10/c01.html
　　=================
　　Power3はPowerPC 620のプロセッサコアとバスインタフェースを受け継ぎ、これに2つめのFPUとLSUを
　　追加し、また命令キューとリネームレジスタを増やした。サポートされるアーキテクチャーはPowerPCの
　　フル仕様である。POWER2からの発展として見ると、Power3はP2SCの持つ2重化されたパイプラインと、
　　PowerPCの持つ64ビットアドレスモードや多重プロセッシング機能を合わせもつ形となった。

　　これによってPOWERからPowerPCへの移行が完了し、2つの系統が一本化された。
　　=================
現在でわ"POWER"ってのわ命令セットの名称でわ無く、単なる商標なのでMotorolaのPowerPCわPOWER
でわ無いすけど、現行の全てのPOWERアーキテクチャを名乗るチップわPowerPCす。

>>579
プリンタ等組込分野で結構なシェアが合ったのに、x86寄生虫路線に集中することを決定したAMDが
顧客ごと切り捨てたす。
AMDを優良企業と持ち上げるアム虫の馬鹿っぷりを示す好例すね(笑)

まあ、PPEと共通なのは命令のフォーマットが op src1 src2 dest の順で32ビット固定長なことくらいですな
RISCだからレジスタ間オペレーションね。

4オペランドな命令ももちろんあるから、オペコード部が最短なんと4bit。
レジスタ部をあらわす部分が7bit×4の28bitですもん。
これ以上拡張しようがないでしょ、これ。

AltiVecの命令セットを改造したものが独立コアになってるって言ったら
大体近い気もする。実際に、サポートされる演算はかなり酷似してる。
Cの組み込み関数ベースでAltiVecのコード書いてた人なら簡単に移植できるハズ。

AltiVec(IBMでいうVMX)はもともとMotorola(今のFreescale)の独自拡張だからね
やたらリッチなVPERM命令まわりとか、暗号とかのアクセラレーションに使うつもりだったんじゃないかと。
俺はVMXさえなければG5は爆熱にならなかったんじゃないかと本気で思ってたりするわけだが。

>>571へのレスね。

>>559-560
マイクロプロセッサに限定しようよ。

話の途中で割り込んですいません。
名スレと評価の高い前スレってどこかに保管してませんか？。
当方、●無しなんで読みたくてもだめなんです。

>>581
やはりPOWER = PowerPCとは読めないなぁ。

>現行の全てのPOWERアーキテクチャを名乗るチップわPowerPCす。
だからといってPOWER = PowerPC とはならないわけだが。
POWER3はPowerPCとしての要件を満たすからといってPowerPCがPOWERになるわけではないでしょ？

まぁ、元レスの「POWERのなかでe600は」というのはナンセンスってのには
同意してもらえそうだからもういいけど。

>>583,584
そうなのか……それだけ違えば全然違うとも言えそうだ。
残ってるのは面影のみというか……
やっぱりAltivecみたいなのは熱だすか。PS3は爆熱になりそうだな。

名称に異常に拘るMACヲタ。付き合うだけ無駄だよ。

つうかさ、MACオタってなにがしたいの？
話が建設的な方向に全く向かわないんだがいい加減にしてくれ。
特定の企業が気に入らないってのはあんたの勝手だが
それをいちいち表に出して、他人を不快にさせるような発言を
繰り返すなんてレベルの低いことやってるんじゃないよカッコワルイ。

嫌味を言って満足してるだけのオナニー野郎は
社会の屑としか思われていないからね。
知識が幾らあっても、今のあんたは言葉を自慢げに羅列するだけで
何の尊敬にも値しない。いや、むしろ終わってる。

大体その日本語の使い方からしてお寒い。
「わ」とか「す」とか、自分なりにイイと思ってるのかもしれないが
はっきり言ってキモ過ぎ。周りがどう感じているのかに鈍感だから
空気読めてないんだよ。
自尊心が肥大しているから、裸の王様という現実に全く気づいてない。

これだけ改善すべき点を言っても、どうせ「これだから〜は〜なんだよな」と
関係ない論点へすりかえて、逃げ道を作ろうとするだろうから先に言っておく。
CPUよりまずお前の対人コミュニケーション能力を先に見直したほうがいい。
ただ人に嫌われるだけの人生で終わりたくなければね。
人に好かれたことがあるのか疑わしいよ、こんなクソ。

以上スレ違いでした。

>>590
単なる事実の提示に対して火病を起こして長文書き連ねるより(笑)、私の書き込みのリンク先でも読んだ方が
よっぽどあなたにとってもタメになると思うすけどね。。。

そうやって身に付けた基礎知識の上にたって、あなたの知見をここで書くようになればスレッドそのものも
活性化するってモノす。

>>586
2chは●の売り上げなどで運営しています。
大した金額ではないのですから●くらい買いましょう。

>>589
まぁ、名前は大事よ？
でも嘘はいかんわけですが。

>>583
>まあ、PPEと共通なのは命令のフォーマットが op src1 src2 dest の順で32ビット固定長なことくらいですな
>RISCだからレジスタ間オペレーションね。

これで共通といってしまうとほとんどのRISCは共通になっちゃうよ。
＃SHとかの16bit命令長2オペランドRISCコントローラは狭義のRISCではないだろうしね。

>俺はVMXさえなければG5は爆熱にならなかったんじゃないかと本気で思ってたりするわけだが。

どうなんだろう。
G3+AltivecなG4があれぐらいで済んでいるなのだから、やっぱりVMXを落としてもそこそこ熱いプロセッサにはなったと思う。

8051といえば...

むかし、X1で、I/Oコントロール部分に1つとキーボード内で1つ
合計2つ使ってたっけ
X1ターボでは、もう一つ増えて3つだっけか。

そいや、8801とかはFDDコントロール用にZ80積んでたって？
(既出ネタだが。）

こういう、PC内部に使われてる組み込み用プロセッサって、
他に何があるの？

キーボードやマウスは使ってるだろうが、他にもあるよな。
一部HDDではSuperH使ってるとも聞いたっけ。

>>594
G4は当初クロック伸び悩んだでしょ。それでパイプラインの細分化を余儀なくされたわけだけど。


まぁはっきり言ってキワモノですなこれ。
SPEは4オペとそれ以外をどうやって区別してるのかと思えば、どーやら最初のビットが立ってるのが4オペランド命令で、
それ以外の命令は全て0になってる。
実質3bit、たかだか8種類の命令しかサポートできない。
かなり厳しいなこれ。

あとの5種類の命令フォーマットもビットが立ってるか否かで区別してるっぽい。
なんか凄まじいアーキテクチャですな。

可変長のx86よりはマシだろうけど。
AthlonはL1命令キャッシュにフェッチするときに命令長を予め計算して先頭に付加するから高速に
デコードできるとなんかの本で読んだけど、Pentium Mあたりでも同じことやってるんだろうか。

PenMはPIIIコアをほとんどそのまま流用してあるだけじゃないの？

まあキャッシュだの分岐予測だの、一部命令追加だの以外の
の処理コア自体は大差ないという噂はあるな。

>>571
＞どうでもいいけどEEの時も展開考えてるみたいなこと言ってたけど全然でしょ。

どっかの板で、GS+EEの石採用考えて問い合わせてみたら
10万個単位で注文おながいしますとか言われてorz、って話を見た。

ハン板のITスレだな。
あれでもパチにつかわれているって話があったと思うんだけど。

あー、多分それだ。意外と住人いるんだな・・・

パチ屋の場合、ハードは共通でソフト違いなのが多いだろうから
（コンピュータ周りね。台そのものでなく）
そういう用途なら大量の需要が見込めるから使えるんだろうね。
ドリキャスそのものが使われてたこともあったし。

>>595
X1は
本体:8049
キーボード:8048
じゃなかったかのう。
turboはキーボードも8049だっけ？

8051はX68kのキーボードだったような気がするが。

ノートPCの電源制御&KB処理でH8つーのは結構あるようですな。

>>601
>ドリキャスそのものが使われてたこともあったし。

NECの黒歴史VGAチップ、PowerVRでは。
ドリキャス丸ごと組み込んでるとして、パチンコでSH4何に使うか思いつかん。

GS+EEって、プレステ2のEmotionEngineとGraphicSynthesizer?
パチンコにそれは豪華過ぎかつ熱過ぎジャマイカ。

パチンコは結構処理能力使いそうだが。ＥＥはともかくＳＨ４ぐらいは。
サミーならＳＨ４＋ＰｏｗｅｒＶＲは使うだろ。ノウハウが余ってるわけだし。

>>574
だいたいPowerPCが作られて時にPOWERから削られた命令はなくても支障のない命令ばかり
POWERだから高性能だと思ってるのはPowerPCやPOWERの命令セットについて何もしらないやつ

>>595
i960がRAIDコントローラに使われてる。
HDDのコントローラでもARMが勢力伸ばしてる。
SeagateがMaxtorを買収したので、またARMが増える。

パチンコはサブCPUは豪勢だな。最初に32bitCPU(SH)を使ったのは華観月らしい。VRも人気だったよ。

>>563
> それ以外にISA的に遅くなる要因があるなら教えてくれ。
なんにもないのでOpteronなんかは速い。
レジスタのパーシャルライトは特許の関係上いろいろめんどうくさいが。

>>579
製造終了、だと思った。
Am2900シリーズのプリンタなんて聞いたことねえぞ。Am29kじゃねえのか。29kは先細りそうになって消滅したんだよ。

AltiVecはモトローラか。欲張って高機能化した挙句に後で高性能化の障害になるのは昔からだ。
中学生の考える最強CPUだな。

>>596
> あとの5種類の命令フォーマットもビットが立ってるか否かで区別してるっぽい。
命令エンコーダはずいぶん楽になるよ。

>>607
680x0だとオートインクリメントあたりと例外処理がかなり足をひっぱりそう。
滅びてしまったのでもはや比較もできないが。

いずれにせよ、ISAはよほどクソ(例:SPARC)でないかぎりは性能には大して影響しない。

究極のCISCとしてはRekursivを挙げておくよ。iAPX432とは甲乙つけがたい。

>>608
デコーダだな。吊ってくる。

>>603
うんにゃ、サミーの猛獣王でDC採用と書いてあったよ＞パンフ
あんときはセガがDC撤退でだぶついていた部材をサミーが引き取ったかと。

北斗も使ってたし、もう無くなってきたかな、部品

>>603
あー、それとたしか山佐の鉄拳が使ってると聞いたことがあります＞GS+EE

最近のx86はCISC命令をプロセッサ内部で複数のRISC命令に分割して実行する。
と言うような事がどこかに書かれていましたが、
これって相当無駄な作業なんじゃ？
なぜ最初からRISC命令にしないのでしょうか？
Windowsが動かなくなるからですか？

＞Windowsが動かなくなるからですか？

まぁ簡単にいえばそう。
マイクロアーキテクチャはCISCよりRISCのほうが性能面で優れてるんだよ、結局のところ。
でも、x86には莫大なソフトウェア資産がある。これは性能より大事な強みだ。

その作業のおかげで、ソフト側からは従来のx86アーキテクチャに見せ互換性を保ちつつ、
高速なRISCアーキテクチャの恩恵を受けられるわけよ。

もちろん、「無駄」を省くための試みは行われてきてるんだけどね。
TransmetaのCrusoe/Efficeonはx86→マイクロアーキテクチャネイティブコードへの変換を
ソフトウェアで行い、リコンパイルされたVLIWを実行するCPUだ。
Pentium 4もデコード済みの命令を一定量キャッシュすることで、デコードのコストを削減す
るアーキテクチャになってる。
両方とも結果的に従来型CRISCのPentium Mに敗れたわけだが。

PowerPCの方が同じクロックで比べると速いと言うのもこの違いからの差なんですね。
例えば新しく出るmelomやconroeなんかはその無駄な作業による無駄を少なくするようにたくさん工夫されてると思うんですが、
無駄があるのとないのとで何パーセントくらい差があるものなのでしょうか？

AppleがIntelのx86に移行する事で、
今までその無駄が必要なかったのにわざわざ無駄のある方を選んで、
その無駄に合わせるというのが勿体ないと思えちゃいます。
IBMのG5移行に期待できないからとか理由はあるのだろうけど…

これはAppleの妥協なのでしょうか…

>>606
PCI-PCIブリッジにも入ってるのがありましたな。
最近はXscaleコアになっちまったようですが。

>>614
> PowerPCの方が同じクロックで比べると速いと言うのもこの違いからの差なんですね。
違う。
単にマイクロアーキテクチャの差。

> 無駄があるのとないのとで何パーセントくらい差があるものなのでしょうか？
1%くらい(AMD談)。

x86のCISC-RISC変換といっても、昔からあるマイクロ命令となんも変わらん。

無駄が１%というのはパフォーマンスの面で、という気もする。
組み込みなんかは性能比以上に消費電力が低いだろうし。
PowerPCに関してはあっちもデコードしてると聞いたが。

実行時の変換コストは低かろうけど、分岐予測やレジスタリネーミングなんかの
機構を考えるとx86命令を維持するのにかかったコストはかなりのもんだろうな。
今後はSMTの導入などでまた悩まされる。

>>614
以前どっかで読んだ、AMDのアーキティクトへのインタビューでは
x86互換によるペナルティーは、レジスタが少ないことで10%、
可変長命令で10%、ただしコード密度が高いことでキャッシュ効率が
良くなって10%相殺で、同規模ロジックならRISC比90%の性能って
言ってた

>>617
1%ってのはダイサイズで
Opteronのデコーダ面積が全ダイのなかでその程度
パフォーマンスでは、少なく見て10%、多く見て20%程度の
損失なんじゃないかな?

命令長を無駄に大きくしても、SSEのレジスタ数を
32〜128本にしておくべきだと思った
整数演算では、x64の16本の汎用レジスタで
あんま困ってないっぽいし
だから速いわけで

かなり色々やってるEfficeonでも、変換ロスは1%程度と言ってた記憶。

>>613
コードモーフィングも、トレースキャッシュも
プログラムの局所性が高くないと、効率悪いんだよな
P4のL1命令キャッシュじゃ、スレッド切り替えの度に
ゆっくりと再デコードだもの

>>614
>PowerPCの方が同じクロックで比べると速いと言うのもこの違いからの差なんですね。

それはアップルお得意の誇大広告だよ。

>>623
ﾌﾟｷﾞｬｰ

連カキすまんが、PowerPC（色々あるけど、x86の同世代と比較して）が同クロックでも速くないと思ってる奴いるのか？
消費電力あたりの性能差はx86が気の毒なほどあるし

Athlon64の方が同じクロックのPentium4と比べると速いというのもこの違いからの差なんですね。
それはAMDお得意のモデルナンバーマジックだよ。

と言われても否定できないな

「ﾌﾟｷﾞｬｰ」のレスの直後に連カキコでまじめなレスつけても信頼出来ん。
まあPowerPCは十分高性能だろ。どっちが凄いかはわからんが。
PowerPCが劣っているのはノート用とかそっちのほうが……

x86がむちゃくちゃすばらしいとかPowerPCがむちゃくちゃうんこだ
とか言いたいわけではなくて
常にどんな状況であろうとも同一クロックならx86よりPowerPCが
速いんだ的内容はアップルお得意の誇大広告だよということだよ。

spec95,2000、実アプリベースの各種ベンチマークテストを見ると、
同世代のPPCとx86の、クロック当たりの速度は、同等かx86がちょっと上
くらいだろ
消費電力あたりの性能は、G4が圧倒してるけど
速度的に1世代前だから当別なもんでない
GeodeNX見ればわかるように、クロックを下げれば
既存x86コアでも、10〜20w程度のTDPは達成できる

同価格帯で、チップセットやメモリサブシステムで差を
つけられないんだから、CPU速度がたいして変わらないのは
当然なんだけど、それがわかるまで何年もかかったよ、orz
alphaも外付けキャッシュをなしにして、メモリをFP-RAM　1chに
すると、同条件のx86以下の速度しか出なかった

>>607
最初にヤラカシたのって、68040のときだっけ？
6800系8ビット時代にも、そいうｺﾄあった？

いや、68000だって充分、その部類かも知れんけど。

>>614

P4はクロック当たりの性能が悪すぎ。
x86系CPUの多くは、P4よりも
クロック当たりの性能が何割か高い。

P4は、
「P4に適した処理を、P4用に最適化したアプリで実行した場合にだけ速い」
って感じで、

たいていの処理は、クロックで劣るAthlon64とかPentiumMと同等以下

>>620
それをすると、クロックを上げれなくなる。
モトローラがいつも繰り返す失敗が、それ。

>>623
いや、おれは「PowerPCの方が同じクロックで比べると速い」という話は信じてる。

ただ問題は、コンパイラの質が悪かったり、
OSのオーバーヘッドが大きかったりして、
それらの性能上の優位点を、すべて相殺していること。

PowerPC自体は速いけどPowerMacは速くないわけ。

ま、それで相殺される程度の、ちょっとした差しかないんだろうけど。

>>630
6800、6809は命令が強力だったが、アキュームレータ、メモリ-メモリ間演算
アーキティチャで、レジスタが極端に少なかった
モトローラは複雑で遅いってのは70年代からの伝統
でも68000〜68030は、当時の実装レベルにマッチした
いいCPUだったのではないか?って思う

>>607
記憶が怪しいのだけど、
プリンタにAm29000が使われていたのは、
AdobeのPostScriptのエンジンがAm29000用だったから?

>>633
逆に言えば，Am29000がその当時としてはレジスタが多くて
演算性能がそこそこの素直なRISCプロセッサだったので
ターゲットにしやすかったというのもあるだろうね。

…ワークステーション崩れで組込用途というパターンの先駆けか。

>>634
割り込みまわりがよく出来ていたことやハードウェアコストも理由だと思う。
最初からどちらかというと組み込み向けだったぽい。

>>614
ttp://pcweb.mycom.co.jp/column/sopinion/005/
> で、内部でx86→RISCの変換を行って処理するのと、RISC命令をそのまま実行するのと、どちらが
> より効率的かといえばそのまま実行する方が高速に決まっている。ちょっと前の話だが、
> AppleのCMで、400MHz動作のPowerPC G3搭載マシンと1GHz動作のPentium IIIマシンを並べ、
> Photoshopのフィルタ処理を実行させるとPowerPC G3マシンの方が高速といった話があった。

ﾏｯｺｲオタが必死にPenMマンセーしようとするのも頷ける。ジョブズは何が悲しくて
x86デコードの泥沼に足を踏み入れるんだか。

Windows信者がx86を使い続けるのとはちょっと違う理由だよな
アポにはPCに全力投球するx86（他に使い道がないからｗ）と、インテルの供給能力が欲しくて、それがPPCのメリットを捨てる価値があった、と。

>>632
うーん、68000の非同期バスや68020のリッチなPMMUなんかは、
バランス感覚を疑うな。
68030はわりとバランスは取れていたと思う。

>>636
> より効率的かといえばそのまま実行する方が高速に決まっている。

根拠のない決め付けをしてPOWER4が出てきたときに恥をかいたわけだが。

POWER以外にも、SPARCやAlphaもuop変換やってるよ。

> より効率的かといえばそのまま実行する方が高速に決まっている。
その点については程度はともかく間違いないだろうけど、
そこだけみればということであってIntelの方が良い面も沢山あるわけだから、
全体をみて良い方を選んだって事。

AppleがおしてるオープンソースソフトにしたってPowerPCってどうしても後回しにされがちだからね。

>>638
>POWER以外にも、SPARCやAlphaもuop変換やってるよ。
やってねーよ。

>>641
やってる。
SPARC64Vの資料見てみ。
21264は少なくともメモリアクセス命令は分解してる。

>>641
alphaは、uopとはちょっと違うけど、超越関数とVMS向けのメモリ保護を
マイクロコードでやってる
ワイヤードロジックだけで、全部処理するってのも非現実的だからな

>>636
K7って、メモリ-レジスタ演算も1uopで発行して、ALU直前のバッファで
レジスタ演算とロード/ストア命令に分解するっていう、
uop fusionみたいなことをやってたんだな
x86だと、スタック操作をパイプライン出せるとか↑で
スケジューリングを楽にできる部分もあるんで不思議だよな

最近知ったんだが、itaniumってレジスタウィンドウ対応だったんだな
33〜128本目が回転レジスタなの
itaniumがSMTやOOOに対応しない理由のひとつって、
あほみたいに覆い、論理レジスタがあるでしょ?
EV8みたいにレイテンシ長くして、巨大なレジスフアイルを
回すって方法もあるけどさ
レジスタウィンドウなんだから、論理レジスタ減らしといたほうが
幸せだったと思うのはおれだけ?

さて、久しぶりに空想のCPUでも考えてみるか
CPUはアリスちゃんにしとこう
で、まず現代のマイクロプロセッサに足りないものはなんかっていったら
それはベクトル命令だ
数値計算を効率的に処理しようと思ったら、ベクトル式以外ありえない
このベクトル演算を実装するにあたって、何がネックか?
っつーと、巨大なレジスタファイルだ
NECのSXシリーズは、ベクトルレジスタが144KBもある!
これではチップがレジスタだけで埋まってしまう
そこでベクトルレジスタには、L1キャッシュを同じロジックを使用する
速度が問題だが、itanium2のL1キャッシュはなんとレイテンシ1クロックだ
32KB、3読み込み、1書き込み、各ポート512bitでレンテインシ2くらいにすれば
低コストでベクトルレジスタを実現できる(かな?）、やったぁ!
ベクトル演算ユニットは、レジスタポートが512ビットなんで8wayだ
2Ghzで動けば、32Gflopsである

>>643
みたいな、っていうより、PenMのが後発。

ただ、ALUとAGUを各パイプごとにペアにしたK7に対して、PenMでは従来のPentium III同等の
演算ユニット構成でそれを実現しているのが凄い。
YonahではSSEの128bitパックド演算にもそれを適用したことで最大4RISC命令
（QWORD Load×2とQWORD演算×2）を1opで扱えてる。

AMDのパイプライン構成ではSSEμOPsフュージョンは原理的にかなり難しい気もするけど

>>644
ItaniumのL1のレイテンシが短いのは厳しい選別と低クロックのおかげだったりするわけだが。

>>645
ALUとL/SUがセットで、SSE/FPUから離れてるからね

>>646
低クロックはともかく、itaniumって選別してるの!?
ただでさえダイサイズがでかくて高コストなのに･･･

少なくともCeleronなんかの選別基準と同等ではないと思うけど。
Pentium IIIでもXeonやS(Tualatin)はL2容量の割りにレイテンシが短かった。

あと、キャッシュのアソシエイティビティ落とせば容量を増やせるかレイテンシを小さくできると思う。

L2のレイテンシはCoppermineとNorthwoodが異様に小さかった希ガス。

>>648
IA-32は、駄目なチップだったらceleronで売ればいいけど
他はそうはいかないから、選別してないとオモテたよ
RISCチップとかはみんな選別品なんだろうな

＞＞あと、キャッシュのアソシエイティビティ落とせば容量を増やせるかレイテンシを小さくできると思う
それだ!
6502のゼロページみたいなもんを用意し、そこにのみキャッシュを
おけば、ライン検索を短くできる!
ってレジスタそのものですね、はい

>>649
northwoodは短かったけど、大容量化できなかったんだよね
だからnorthwoodのXEONは、オンチップL3キャッシュだった

>>643
ItaniumではOoOやらないと決めてから論理レジスタの本数を決めたんじゃない？

SMTはこれといった障害はなさそうだけど。物理レジスタがコンテクスト数ぶん
増えるだけだし。
レジスタファイルがでかくなって大変だけど、P4でも条件は同じ。

>>644
メインメモリどうするんだよう。
あとベクトルはモダンなOSと相性悪いよ。
コンテクストでかいとかベクトルロードでページフォールトするとか。

次期Itanium2はCGMTだっけ？レジスタファイルが二重化されててI/O待ちになると即待機中のスレッドがアクティブになる。
つーか、6命令同時発行のEPICアーキテクチャで128本って決して潤沢すぎるとはいえないと思う。

IBMのサイトにあるPowerPCのBookVers2.02ってやつ読もうとしたけど、
さっぱりわからなかった。

>652
古い記事だけどitaniumにもOoOをやろうとしてるみたいだよ。
一番下のほうを参照
ttp://pc.watch.impress.co.jp/docs/2002/1115/kaigai02.htm

ちゃぐちゃぐうまっこ(・∀・)

>>638
大丈夫か? 「内部でx86→RISCの変換を行って処理する」か「RISC命令をそのまま実行する」かの
二択を見比べたときに「そのまま実行する方が高速に決まっている」以外の結論が出ちゃだめだろ。
CISCのほうが命令長的にキャッシュの効率が良いとかそんな理屈?

>>643
> alphaは、uopとはちょっと違うけど、超越関数とVMS向けのメモリ保護を
> マイクロコードでやってる
> ワイヤードロジックだけで、全部処理するってのも非現実的だからな

これをuopと言うなら、インテルの486もuopと言わないといけないわけで、
uopと言うのは不適切ですな。

ワイヤードロジック、マイクロコードなんて言葉がまだつかっているなんて。

JavaがCのラッパー言語だとまだ信じてるんだろうな。

どう?

ここのみんなは薄々きがついているんだろ?
日本のマイコン、プロセッサ業界が未だにヘネパタ本洗脳から抜け出せず、
技術者のレベルをさげていることを。

日本の情報処理の試験なんていまだに

RISC ワイアードロジック　パイプライン処理
CISC マイクロプログラム制御

で正解だからなw
これが許されるのは80年代中盤までだよねぇ。ｷﾓｰｲ。

大体ワイアードロジックなんて殆ど教科書用語じゃねぇか?
デジタル回路でもつかわねーし。
せめてhardwiredにしてくれよ。

>653
ALUが6基もあるもんな
128本くらいいるよな
>658
ごめん
実装の仕方なんて些細なことだし
今時マイクロコードとか死語だよね

Windowsをx86と同じだけ力を入れてPowerPC版を作ってくれてたら、
かなり変わってただろうに。

エクースボクース360搭載のXP組み込み版はNT4PPCとはまったく別の設計らしいね。

>>657
x86-RISC変換とは言われるものの、uopはマイクロアーキテクチャにべったり依存していて
外部プログラムの表現にそのまま使えるようなものじゃないので、
「RISC命令をそのまま実行する」というのはナンセンスなんだけど。

>>658
似たようなもんだけどね。俺も違いはよくわからん。
逐次処理されるのがマイクロ命令で、動的スケジューリングされるのがuopってとこ？

>>664
細かい定義はどうなんだろうね?
ちなみにマイクロ命令には、一命令に複数の命令が入ってる
水平型マイクロコードと、そうでない垂直型マイクロコードに別れる
マイクロ命令っていっても、レジスタをアキュムレータに接続するっていう
レベルのものから、普通のマイクロプロセッサの命令のようなものまで
実装はさまざま

>>662
NT4.0までは、同じだけ力をいれて作っていたけど、ちっとも売れなかったんだよ!

>>664
俺は667ではないが、RISC命令そのままでなくても基本的な考え方は同じだろ。
例えば、
ADD [m32], r32
(r32で示されるregister値をm32のregister値が示すアドレスで示されるメモリ
上の値に加算して、その加算結果をm32のアドレスで示されるメモリに格納する)
という命令がx86にあるけど、一般的なRISC CPU用の等価なプログラムでも
IntelやAMDのx86 CPUの内部uop処理でもload,add,storeの3命令で表現するのは
明らかで、RISCとCISCの違いはRISCがソフトから見えるアーキテクチャレジスタ
で表現できるのに対し、x86は、CPU内部のに閉じた物理的なレジスタであると
いうだけ。
したがって、外部プログラムの表現にそのまま使えるものではないというのは
そのとおりなんだけど、657が言っていることに関しては本質的な問題ではない。
RISC CPUであれば、この例ではload latency(例えばL1-hitで2-4cycle程、
L1-miss,L2-hitで10-20cycle程度)を考慮してloadと後続のadd,storeを引き離して
配置することができる等、コンパイラチューニングの余地が多く、RISCの方が性能
を引き出すのに本質的に有利であるということを>>657は言ってるんでしょう。

> この例ではload latency(例えばL1-hitで2-4cycle程、L1-miss,L2-hitで
> 10-20cycle程度)を考慮してloadと後続のadd,storeを引き離して配置すること
> ができる等、コンパイラチューニングの余地が多く、RISCの方が性能を引き出
> すのに本質的に有利であるということを>>657は言ってるんでしょう。

load と add,store を引き離すことはCISCでもできるよ。
RISCの方が有利なのは、コード変換に必要な分のパイプライン段数を
省略できることで、パイプラインが乱れた場合のオーバヘッドが少ない
点でしょ。
トレースキャッシュで、このオーバヘッドをある程度は隠蔽できるが、
キャッシュをはずした場合には駄目なので、完璧に隠蔽するのは無理。

ただし、Prescottみたいに32段もパイプラインがある場合は、コード
変換に必要な段数は、割合としては少なくなるので、どうでもいい面は
あるかも。でも RISC系 プロセッサの場合、それほどは段数が多くない
(6段とか8段しかパイプラインが要らないものまである)ので、差は大き
めに出る筈。

あと、CISC対RISCには関係ないけど、x86対RISCだと、レジスタ数の違いも
大きい。8レジスタは少なすぎる。x86_64だと、まあそれほど問題ないレベル
だけどね。

>>666
でも95や98とサーバ用途じゃなく一般向けはx86だけだったよね？
この流れは大きかったのはある気がするし、
PowerPC乗るのがMacのみになっていったのもあると思う。

>>667
> コンパイラチューニングの余地が多く、RISCの方が性能を引き出すのに本質的に有利

ソースコードから自前でコンパイルする世界なら、それでもいいだろう。
しかし、
バイナリ配布の世界なら、そういうわけにはいかないだろう。

>>669
MS-DOSというシガラミがないPowerPCに、どうして95や98なんかが必要なのよ。

>>668
>RISCの方が有利なのは、コード変換に必要な分のパイプライン段数を
>省略できることで、パイプラインが乱れた場合のオーバヘッドが少ない
>点でしょ。
RISC対CISC論で真っ先に言われるこれだけでもないということです。
>load と add,store を引き離すことはCISCでもできるよ。
register operandなRISC的命令だけでプログラミングできるということ
ならたしかにそうだけど、memory operndな命令を多様せざるを得ない理由が
まさに以下のことです。(CISCとx86を混同してしまったのは認めます。)
>あと、CISC対RISCには関係ないけど、x86対RISCだと、レジスタ数の違いも
>大きい。8レジスタは少なすぎる。x86_64だと、まあそれほど問題ないレベル
>だけどね。
まさに8レジスタでは命令間引き離しはおろか、work用registerが不足して
メモリへのspill/fillまで多発させてしまいます。
命令間引き離しをまともにやったらRISCで一般的な32レジスタでも不足とも
言われていますね。

>>670
>ソースコードから自前でコンパイルする世界なら、それでもいいだろう。
>しかし、
>バイナリ配布の世界なら、そういうわけにはいかないだろう。
CPUの実装に依存しない一般的な範囲での最適化ならバイナリ配布でも
意味があることです。

RISC対CISC論で重要だったのは、実際のアプリケーションでRISCの方が速いということだ。
>>657みたいな全否定には定量的な結果が必要だな。

>>673
おれは定量的な結果とやらの前に
おまいがきちんと文意をつかむことの方が先だと思う。

>>672

667> コンパイラチューニングの余地が多く、RISCの方が性能を引き出すのに本質的に有利
↓
670> バイナリ配布の世界なら、そういうわけにはいかないだろう。
↓
672> CPUの実装に依存しない一般的な範囲での最適化ならバイナリ配布でも意味があることです。

おかしいぞ。

>>675
>670からしてすでにおかしいが？

マジレスするとRISC, CISC論争なんて今さらいらね。

数万ゲート以下では、ゲートを節約するためにマイクロプログラムなどを使う必要がある。
大体、数万から数十万ゲートの時代にRISC命令セットは生まれた。

それから、数百万ゲートの時代へ。
スーパーパイプライン、スーパースカラ、アウトオブオーダー、
数百万ゲートの世界ではRISC, CISCも大差がなくなり、
どちらの命令セットでもも似たような機能、高速化技術が導入される。

数千万ゲート、数億ゲートの現代では、
大容量のオンチップキャッシュ、非常に高速なIO、マルチスレッド、特殊ハードウエア、
リコンフィギュアラブル、周辺チップの統合といったRISC, CISCを超えたところでの勝負になっている。

使えるゲート次第で特に突飛なことを考えない限りとれるアーキテクチャはほぼ決まってくるので、
RISC, CISCの優劣比較なんて空論でしかないでしょ。

で、uopについてだが、>>664は良いことをいった。
uopは命令と制御信号の仲介役を担う非常に低レベルな命令であって、
RISCと割り切って考えることももはや出来ない。
はっきりいって、マイクロアーキテクチャに都合の良いエンコーディングをその都度採れる
uopの方が、古参RISCアーキテクチャの命令セットなどよりずっと進んでいるだろう。

>>678
面白い意見でわ、あるす。ただ、その定義だとPOWER4/PPC970のcracking/millicodingわuopとわ呼べないという
ことになるすね。あれ、普通に2入力１出力の通常PPC命令の並びに置き換えるだけすから。。。

ttp://mypage.odn.ne.jp/www/k/8/k8_hammer_trans/files/Hammer-Info.html
> AMDでは、x86はRISCの頭に載せられると思ってる人が多いです。29K RISCプロセッサを
> 作ってたときも、ちょっとハードを付け足せばx86が動くようにできると思ってました。
> K5以降K8に至るまで、この考えは取り入れられています。

なんてーか、x86はもはや中間言語だよな。

>>657（´・ω・） ｶﾜｲｿｽ
変換するのと元から変換してあるのでどっちが速い？という話で、
後者が速くなければおかしいだろ、というつっこみをしただけなのに。

>>682
どっかのトーシロがPowerPCのx86に対する優位性を主張するためには、
RISC命令を直接〜というのはナンセンスな仮定だと言ってんの。

>>671
開発費の問題

>>684
却って高くつくが？

移植するだけなら安い。
むしろ互換性だろうなぁ。アプリケーション使い回せないんだったらOS移植しても意味なさそうだし。

>>686
x86べったりの9xの移植が簡単だとマジで思ってるのか？

...ひょっとしてx86エミュレータの上で動かせばいいとか思ってるのかな。

>>682
CISC ISAはおろかRISC ISAすら老朽化しはじめている現代、
かならずしも直接実行する方が速いとは言い切れなくなってきているわけで。

>>688
そりゃ変換しない方がいいに決まってるがな。
ただもはやRISC ISAだからといって変換せずに実行できるとは限らんというわけで。
どうせ変換するならCISCだろうがRISCだろうが関係ないわな。

なら変換しないですむISAをつかえば？となるだろうが、問題はISAはそうそうころころ
(追加するならともかく)変更するわけにはいかんということなんだよな。

そういう意味でIA-64の明示的なんとかは、
変換せずにここまで詰め込みました。というISAだと思う。
(Intelスレで書いたら理解されなかったが…)

今プロセッサアーキテクトが新しいISAのプロジェクトを立ち上げるとしたら、

1.想定されるソフトウエアの対応力、トレンド
2.想定されるハードウエアの内部実装(マイクロアーキテクチャ)
3.将来への拡張性

を考慮して最適な集合・エンコード形式を選択するだけでしょう。
1.RISC　2.CISC　3.VLIW　のどれか?という分類論に今さらどれだけの価値があるのか…。

電気・電子板で、CPUを造ろうというスレが立ったときには、
ISAはCISCか?RISCか?という議論に終始しててやっぱ日本人は…とおもてしまた。
以上戯言でした。

> どうせ変換するならCISCだろうがRISCだろうが関係ないわな。

全命令変換するなら、たしかに関係ないけど、RISC系プロセッサ
の場合、いまだにまったく変換なし (Niagaraとか) とか、一部の
命令だけ変換して、多くの命令は変換なしといったものが多いから、
まだ関係あると思われ。

>>690
　　-------------------
　　ISAはCISCか?RISCか?という議論に終始しててやっぱ日本人は…とおもてしまた。
　　-------------------
新アーキテクチャ実装の際にISAで揉めるのわ、日本人だから。。。って訳じゃ無いす。
以下、ゲーハー板で紹介されたCELL開発ストーリーから引用す。
　　===================
　　2000年11月ニューヨーク郊外のホテル。APUの命令セットの
　　基本方針を決める合宿。VLIWかSIMDのどちらを選ぶか？
　　それぞれ一長一短。中々結論は出ない。
　　「汎用性の高いVLIWの方がいい」
　　「いや、オブジェクト・コード効率を考えたらSIMD以外は有り得ない」
　　===================

引用元の記述足りなかったすね。これ日経エレクトロニクス誌の記事の一節す。
　　

> そういう意味でIA-64の明示的なんとかは、
> 変換せずにここまで詰め込みました。というISAだと思う。

同感。速くするための工夫がたくさん詰まってる。
でも、ソフト屋からすると、CISCとは別の意味で複雑だなあと
思ってしまうんだよなあ。

> ISAはCISCか?RISCか?という議論に終始しててやっぱ日本人は…とおも
> てしまた。

新しいISAを設計するのに、いまさらCISCはないでしょう。
売れるためには x86 完全互換であるべきだってなら、まだ分かるが。

> 日本人だから。。。って訳じゃ無いす。
> 基本方針を決める合宿。VLIWかSIMDのどちらを選ぶか？
> それぞれ一長一短。中々結論は出ない。

これならまだ合理的な議論だろ。
新しい ISA に CISC を選ぶってのは、それとはだいぶレベルが違う。(w

全命令変換でも可変長と固定長じゃ電力消費量が違うんじゃない？



ところでx86にも680x0のｻﾌﾞｾｯﾄColdFireみたいなのはできないのかな

> 全命令変換でも可変長と固定長じゃ電力消費量が違うんじゃない？

確かに固定長命令の方が作るのはかなり簡単だろうなあ。

>>690
>そういう意味でIA-64の明示的なんとかは、
>変換せずにここまで詰め込みました。というISAだと思う。

のはずだったんだが、パフォーマンスが出ないのでISAを(あまり)いじらず
どうにかしようとしたら、ごてごてと余計なことをするようになってしま
いました。
という感じなのでは？

まぁVLIWは難しいと思うっすよ。バイナリ互換を要求される用途だと特に。

>を考慮して最適な集合・エンコード形式を選択するだけでしょう。
>1.RISC　2.CISC　3.VLIW　のどれか?という分類論に今さらどれだけの価値があるのか…。

ある実装方針(たとえば柔軟性重視とかコードサイズ優先とかだな)を考えた時に
VLIWになったりRISCになったりRISCコントローラ(16bit固定命令長2opな奴らは原始RISCと区別したい)
になったりする訳で。
目標→形式っていう方向で議論するなら意味があると思うよ。
＃CELLがSIMDにするかVLIWにするかでもめたというのはこういう方向。だから意味はある。

方針が決まれば分類がおのずと決まるわけで。
＃ハイブリッドなISA連中っていうのは、拡張した結果「そうなってしまった」でしかない。

>電気・電子板で、CPUを造ろうというスレが立ったときには、

CPUを作ろう。だけで進めるとそうなるだろうね。
「どんな」CPUを作るのかが重要なのに。

> ごてごてと余計なことをするようになってしまいました。
> という感じなのでは？

ごてごてって何？
キャッシュをやたら載せる以外になんかやってたっけ。
foxton のこと？

>>636のようなことになる理由をx86デコード以外の要因に求めてみる

1.今後のIntel CPUの礎たるPen3は純粋性能でみても他社製品に
クロックあたり2.5倍の差を付けられるダメダメだ。

2.ﾌｫﾄｼｮの一部または全部のフィルタ処理はWindows(x86)向けには十分に
最適化されていなかった。その点を利用してマシン(CPU)性能差が偽装
された。中指欠損の腐れﾏｶｰ共が企てた陰謀に過ぎない。

3.L2キャッシュ容量が局所的に有効だったため明暗を分けた。

4.CPU以外のハードウェア性能

5.ライターの妄想

6.Windowsプラットフォームって…うんち?

>>699
で、1-6の中であなたの妄想以外が根拠になっている話わ有るすか？

>>700
すごいレス早いね。

Cell開発はもめてたところに、
IBMエンジニアの鶴の一声でいまの路線になったとか。
正直、最近のCPUはハイブリッド化しすぎてて、
特定の方式、アーキテクチャの名前付け自体が困難と思われ。

>>702
しかしCELLの場合は、完成品のISAを見る限り命令エンコーディンが詰まり過ぎで汎用性やら拡張性やら
わゼロと言い切って良いくらいす。あんな風になるくらいならVLIWの方が良かったような気がするす。。。

CELLの場合はローカルメモリ少ないしコード密度のほうを重要視したってことだろ。
後々禍根を残すかもしれないことくらいは当事者のほうが実感しとるんじゃねーの。
スタートアップでこければそれもない。

VLIWにしたってやたらめったら拡張できるわけでもないしな。

>>698
プリディケーションとかキャッシュを制御するヒントとか
レジスタスタックのことだろ
IA-64の命令は厳密には2000くらいある
でも高速化には役に立ってるんじゃないかな?
現在のIA-64が、コア面積の割りに速くないのは
演算器が無駄にリッチだからだろ
ALU6が同時実行されるときとか、レジスタの18ポートが埋まるときとか
どれだけあるのかと

>>703
PS3にしか使われないんだから、オペランド部が狭くても良かったんだろ
2ｉｓｓｕｅだからVLIWにする必要もないし

>>705
　　----------------------
　　2ｉｓｓｕｅだからVLIWにする必要もないし
　　----------------------
件の記事でわ、
　　======================
　　00年秋基本アーキテクチャがまとまった。 APUには演算ユニット、LocalStoreと呼ぶ専用メモリ、
　　DMAコントローラを備えていた。
　　======================
とあるすから、マイクロアーキテクチャが(2-issueに)決まってからISAを決めたと思われるす。VLIWで有効
という成算わ あったんじゃないすかね？明らかなメリットわレジスタ指定に28-bitも喰われる積和演算や
permute命令がevenパイプとoddパイプで重なる可能性わ低いすから、合計64-bitとすると命令数の制約
わ非常に楽になったと思うす。

>>706
あぁそっか
32bit+32bitじゃなくてよくなるんだ
VLIWで、中の命令長変則のほうが素直になるな

> プリディケーションとかキャッシュを制御するヒントとか
> レジスタスタックのことだろ

なるほど。
これは後からごてごて拡張したというよりは、最初からその
つもりでごてごてつけたって印象なので、そういうのとは
別に何かあるのかと思ってしまった。

> IA-64の命令は厳密には2000くらいある

IA64 が複雑だってのは >>694 でも書いたとおり、同感。

> でも高速化には役に立ってるんじゃないかな?

これも同感。

> 現在のIA-64が、コア面積の割りに速くないのは

どうなんだろ。
キャッシュがほとんどで、コア面積自体はそれほど大きくは
ないというか、x86 に比べると遥かに小さいけど。
SPEC の結果で IPC を計算すると、Pentium M に比べて 20% 以上
も良くて、既存コアの中ではトップだし。もちろんキャッシュの
おかげもあるけど。

>>708
itaniumのコアサイズは小さくない
130nmMadsionで、130mm2くらい
90nmのmontecitoで、60mm2くらいだ
それにたいして、x86はyonahとかopteronで、40mm2(90nm)程度だ
IPCは、たしかに抜群だけど、レイテンシ1の超高速L1と
さりげに大容量のL2の効果もあるし
もちろん同面積でも、X86にIPCで負けることはないだろうけど
もっと性能出て欲しいよねぇ、うん

>>709
　　----------------------
　　itaniumのコアサイズは小さくない
　　----------------------
小さいと言われているすけど。。。
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2598&p=4

ところで、itaniumのFPUって
L1データキャッシュにはアクセスできなくて、
L2キャッシュにデータを読み書きするんだよな
で、そのL2キャッシュのレイテンシは5
EPICとかレジスタの多さが効いてるんだ

>>710
madisonコアが130mm2ってのは、タグとかL2キャッシュも含めた面積かな?
>>710の比較だと、opteronと同等の80mm2
これが正解だな、ごめん
ダイ面積はともかく、コアのトランジスタが少ない
可能性のあるアーキティクチャだった･･･

Windowsがどーたらってのなら、CE系があるんだけど…
標準プラットフォーム(ちょっと語弊があるが)として生き残ったのはARM版だけ。
PowerPCもSHもMIPSも追いやられてしまった…
営業力と(携帯電話での)普及率の差はここでも大きいな…

Windows NT も MIPS, Alpha, PPC があったけど、いまや。。。。

>>705
IA-64は第2世代で、ユニットを増やしてますよ。
メモリまわりの改善とも相まって、
同クロック比で1.5倍くらいは速くなってる。

>>709
大容量なのはL3。
L2は256KBしかない。

>>713
あまり表にでてないけど実質CEが最新アーキテクチャのWindowsだしねぇ
古いNT系とは違うのだよ･･･

ムチとバルカンがついただけにも見えるが

ARM普及の要因はIntelが互換プロセッサ作ってるのが大きいかも。
てか日本メーカー製のPDAってXScale搭載機普通に多いし。

実は中身がTRONだったり……
そうか！　リアルタイム処理が優れているから格闘戦向きなんだ！

>>719
マーケティングじゃね？
組み込み用としてはMIPSよりちょっと優れているとは思うけど。
(回路規模、コード密度、割り込みまわり)

全ARMコアの中でXScaleが占める割合は小さいと思う。年に10億個以上出てるとか。

>>719
伝統的な低消費電力とコストだろ

PocketPCがARMを指命したからでしょ。

指名だ・・・orz

ママ「ARMちゃん、ご指名よ

MSさんはホント、いいお客さんだからがんばりなさいよ」

ARM「はい!」
(MSさんって確かに素敵だわ、あたしなんか釣り合わない」

MIPS「なに?　あのCPU?　あとから出てきた癖にシャシャリでちゃってさ?
あたしのほうが速いんだから」

SH「そうよ　クロックが速さじゃねーんだよ」

MIPS「あんた一番クロック遅いからって何いってんの?」

マネージャ「SH、セガってわかるだろ?　おまえの一番太い客だよ
破産したよ　CSKに身売りしたらしい」

SH「え!?」
(ARMばっかいい思いしやがって。ひとつ締めてやんねぇとな)

68000の日記
palmさんは、あたしのこともう要らなくなったんだって
ARMちゃんがいいんだって
あたしはNo.1････
No.1そうだった
でも、引退かしら?
V70とか先輩たちはもういなくなっちゃった
この前もXX商事のお客様が言ったわ
「今時ね、アドレシングモードとか流行らないんだよ?
わかる?
もうさ、うちの若いやつでもアセンブラとかできなくてさ
コンパイラのほうが速いし、メモリの節約に
命かける時代でもないしね
だから、わかるよな?
おれが貰ってやるからさ･･･」
ＳＵＮとappleさんに拾われて、そのあとはセガさんとか
いいお客さんがいっぱいついて、
組み込みでは、あたしが華って呼ばれてたのに･･･

ARMの日記
今日は会社の忘年会
ママにマネージャに、ＳHさんにMIPSさんにお店の人はみんないる
行く先はどこかしら?
マネージャ「ARMちゃんはここはじめてだっけ?」
知らないお店･･･
ARM「はい･･･なんだか怖いわ」
マネージャがドアを開けて、店に入る
マネージャ「itaniumはいるか?」
itanium「あ!　WinCEのマネージャさんじゃないですか〜?
店に来てくれるんなら、電話のひとつくらいくださいよ〜
今席つくりますからね、ちょっと待ってくださいね」
itaniumさんって言うのかぁ
スマートな顔立ちだわ
ｉｔａｎｉｕｍ「おい、席つくれ
あとボトル探せ　ネックはWinCEさんな」
itaniumさんは、若い人たちに指示を出してる

itanium「へぇ〜、ARMちゃんって言うんだ
かわいいな、ってごめん!
初対面なのにさ!」
ARM「かわいいだなんて、言われなれてなくて･･･
itaniumさんって人気なんでしょう?
すごく素敵　お仕事できそう」
itanium「そうでもないよ
っていうかさ、おれ才能あるって言われてこの業界入ったんだけど
なんかパフォーマンスでなくてね
頑張ってはいるんだけど・・・」
itaniumさんの顔が曇った
ｉｔａｎｉｕｍ「この商売、正直自分の実力だけじゃ駄目なのかな?
って思うことがある
コンパイラとかが足を引っ張って･･･
あぁ、ごめん
こんなつまんない話しちゃって」

すまん、ｱｹﾞる
続きはなしでつ
糞レス書いてすみません

ARMって、PDAよりもっと小さい機器が主戦場じゃないの？

>>730
携帯とか、それ以下が主戦場だな
PC関係だと、エントリクラスのNASとかルータとかみんなARM
MIPSとかPPCはないんじゃないかな?

うちのケーブルモデムはモトローラ製なんで中の石はfreescale製だろうな。いや、分解してみる気は無いが。

ゲームボーイアドバンスがARM7、あとNintendo DSはARM7とARM9のデュアルプロセッサ構成だったっけ。
PSPに比べて電池の持ちがいいのは単純にスピンドルの有無やクロック差だけじゃないだろうな。

>>732
水をさすようで悪いが、PSPとNintendoDSの消費電力の差は
単にパフォーマンスの差からきてるんだろ
PSPはMpeg-4デコードできたり、PS2クラスのグラフィックス
ロジックの周波数も150〜300Mhz
NintendoDSは、PS1世代のスペック
比較できる製品同士でない

性能いいのかやっぱり。DS馬鹿売れでPSP不振に、うちの知り合いのGK候補が嘆いておりました。
レボに使われる石ってPPC系で確定？PC(Intelアーキテクチャ)対ゲーム機(PPC)って構図も面白いかも。

>>734
PS2やGBAより販売ペースいいらしい、NintendoDSは
で、レボの石はPPCベース確定だろ
ハードウェアベースで、GameCube互換らしいから
(今では変更されてるかも)

PSPはR4000の2コア構成でクロックは最大333MHz。
DSはARM9-66MHzとARM7-33MHz。

それなんだけど、最大222MHzで普段111MHzまでスペックは落とされてた筈だお。

>>731
>PC関係だと、エントリクラスのNASとかルータとかみんなARM
>MIPSとかPPCはないんじゃないかな?

その辺はMIPS。ARM7/9はもうちょい下。
ルータとか通信系はMIPS強いよ。
NASに使うにはARM7/9はちとパワー不足。XScaleがそろそろ降りてくるぐらいか。

ルータはMIPSが多いけどOptとかSHらしいな。持ってないけど。
エントリクラスのNASは家庭用NASの代表格とも言える玄箱、Linkstationが
PPCを採用してたと思う。

玄箱系はMPC8241。実質PowerPC603eやね。
LinkStationだとMIPS採用機も有。石はAMDのｱﾙｹﾐらしい。
白箱はSH-4、新型でXscaleになった。

ごめんｱﾙｹﾐ嘘。混ざった。IDTのR3000互換。

AppleがIntel CPU搭載のMacを出して、
コード変換していてもPhotoshopがこんなに高速に動くよ、とデモをしたそうな。

もうね、CPUアーキテクチャは何だっていい、という時代なのかな。
あんまり面白くないな。

CPUアーキティクチャがどうでもよくなった一番の原因は
コアが複雑になったことじゃなくて、
CPUパワーの割りに狭いメモリ帯域幅と
異常に長いメモリ･レイテンシだろ
DDR2 128bitで、限界が決まってる

インストラクションセットアーキテクチャといっても、
ようはただのインターフェイスでしょ？

>>744
カッコいいこというなー!！

>>743
Niagara みたいなのを作ろうとすると、x86 だと 8 core も
入らないんじゃない？ だとすると、コアの複雑さは、やはり
まだ関係していると思われ。
single thread 性能を追求すると、どうしてもコアが複雑に
なるから、ISA は余り関係ないだろうけどね。

>>746
かといってNiagaraが面白いアーキテクチャかというとそれもどうか

俺はNiagara面白いと思うが。
ま、486の8発みたいなモンだからつまらんという意見も理解できるけれど。

>>746
PS3のcellと、Pentium�Vの各々のロジック規模って
なんとほとんど同じ
IA-32で8コアでも、あんま問題ないと思う

>>747
アイディア自体は素晴らしいが、Sunの実装だからね･･･
Sunでさえniagaraで、これだけの性能が出るんだから
IBMやintelがやったら、どんなのが出来るか興味ある

いまだにCyrixが死んだのが惜しく思う漏れ・・・
もし生き残ってたら、
今の混迷としたCPU業界で、
どんな突拍子もないアプローチをしてくれただろうか・・・

んー、Cyrixは突拍子もないアプローチというより反則技という印象があるな。
FSB最速66の時代に75を要求したり。

いまだにCrayが死んだのが惜しく思う漏れ・・・
もし生き残ってたら、
今の混迷としたスパコン業界で、
どんな突拍子もないアプローチをしてくれただろうか・・・

>>750
Cyrixの血自体は生きているが…
だが、NSやAMD、VIAは活かし切れてないというか?

ま、例えばMediaGX系はCE.NET(WindowsMobile)と同様に
世の中で求められている様で求められていない様で…立ち位置は微妙だね…
この手のデバイスってのは、即効性の利益を求めるメーカーにとって
美味しくないのかも知れないけどさ。

高IPCどうの言うなら実はCyrixが最強だったわな。
そのぶんクロックもあげにくかったみたいだが。

>>754
x86ならmP6じゃね？

>>755
mP6はむしろx87だった…

>>750
どれだけ狭いCPU業界だよｗ

>>753
Cyrixは死んでるよ
VIAのC3は今じゃIDT系になってるからな

今おもえばインテルのネットバーストは
Cyrixのリニアバースト(時代のチップ)を
パクッたかのような豪熱路線だったな。

NexGen 最強。

いっそのこと、
Microsoftの.NETのCLRの中間コードに特化したCPUを作ってしまえ・・・

・・・ってそれはJavaチップだっけ?

未だに死んで惜しいと思えるのはAlphaじゃないの？

UltraSparcT1のブロック図どっかにないかな？
最近arch系の雑誌入手できなくてTT。

8coreは良いとして4並列SMTで性能出ると
思えない。キャッシュも足りてなさそうだし。

Pentium系は133までしか無く、P-Pro200が最強と信じて疑わなかった頃、
既に300MHzもの動作速度を実現していたAlphaAXP。

まさに異次元の怪物を見る思いだったよ。

>>764
たしかにAlphaもすごいんだけど、大改造されつつもいまだに現役なP6コアこそ怪物といえる。
当時はさんざん叩かれていたが。

AlphaってPentium3(河童)に対するPentium4(藁)みたいなものだよ。
熱くて、高速なメモリシステムがなければ速度を発揮できない。

21164以前と21264を比べるならPentium4→PentiumMだけどな。

>21164以前と21264
Out of order導入だっけか。
21364で予定していた4コア統合も凄いと思ったが…。

> UltraSparcT1のブロック図どっかにないかな？

フロアプランだったら
ttp://www.aceshardware.com/read.jsp?id=65000293
にあるけどね。
パイプライン構成なら
ttp://pc.watch.impress.co.jp/docs/2005/0531/spf07.htm
にもある

> 4並列SMTで性能出ると思えない。

Niagara は SMT じゃなくて、FGMT。
メモリバンド幅については、DDR2 を4チャンネル用意して
カバーしている。1.2GHz×8コアなので、周波数あたりの
メモリバンド幅でみると、デュアルコア Opteron (DDR を
2チャンネル) の倍のメモリバンド幅があることになる。
SMTの場合、さらにこれをスレッド数で割らなければいけない
計算になるけど、FGMT/CGMT だと同時実行はしないから、そこ
まで厳しくはないんじゃないかなあ。
スレッド数で割ったとしても、Athlon 64 X2 をシングルチャネル
で使ってるのと同じ程度のメモリバンド幅は確保されている計算。

> キャッシュも足りてなさそうだし。

全然関係ないスレッドを32個とかだと、まったく足りないだろうね。
Webサーバだったら、かなり共有できそうだから大丈夫な気がする。
Java アプリケーションサーバはメモリどか食いすることが多いので
キツいかな。SPECjbb の特性に助けられた？ あるいは、最近の
Java で使われている世代型GCの場合、C++やCでnewやmallocを使って
書くよりも、むしろキャッシュフレンドリなので、うまいこと、
そのあたりのサイズを調整すればなんとかなるのかも。

>>763
webサーバーやデータベースだと
処理時間の8割がメモリの待ち時間
なんで簡単なマルチスレッティングで
スループットがかなりあがる

pentium4以外はSMTやイベントドリブン式の
マルチスレッティングでオンライントランザクションが
速くなってる

>>769
さんくす！見てみます。

みんな何を読んだりしてそんなに詳しくなったの？

そういやNiagaraってVerilogの論理設計データをオープンソースで公開するって
話だったな。

人間ナイアガラ！

>>764
Alphaだけど普及させようということでDECがSAMSUGと手を組んでたよね
Alphaが普及してたら今頃CPUでもSAMSUNGが天下を取ってたわけですよ

まぁクロックが予定通り伸びなかった主犯という声もある。

でもISA的には一番好きよ、Alpha。
IA32やx86_64はアレだし、IA64は複雑すぎだし、
Alpha以外のRISCはどれも盲腸みたいな特徴が
いくつかあるし。

三星さんとこは
2002年にAlphaの技術を生かしたらしい1GHzなARMを発表、
2004年には3GHzに到達とか言ってたけど
あの話はどこに行ったんだろう。

>>777
POWERじゃダメなん？

POWER は結構盲腸が…

>>780
条件コードがあるのが気に入らん。

Alphaに性能面での最大の好敵手であったPA-RISCってほんと情報少ないんだな。
RISCプロセッサトークでも比較対象として話題に出てこない。

だってPA-RISCは秘密なんだもん。

>>782
ここいら辺とか。
ttp://www.nminoru.jp/~nminoru/programming/arch/arch_features.html
ttp://www.nminoru.jp/~nminoru/diary/2005/06.html#2005-06-02

PA-RISCのマイクロアーキってPA-8000が96年で、
4 way oooコアで、命令ウインドウも56エントリあるし、FMACもある。
今さらだけどItaniumが高IPCなのってIntelよりもHPの性格がそのままでてるよね。
内蔵キャッシュも750k, 1.5M　〜 3M, 6M, 9M, 12Mだし繋がる。

確か、PA-RISC ってx86と違ってスタックが逆につまれるんだよな。

>>785
FMACはPA-RISC1.1からあったよ。
IA64は大部分がHPの成果だよ。
PA-RISCこそ全身盲腸だと言えるよ。SPARCは全身癌だよ。

>>785
>内蔵キャッシュも750k, 1.5M　〜 3M, 6M, 9M, 12Mだし繋がる。
これはじゃない。SRAMチップだといわれたりしたわけだが。
Itatniumはロジックもでかいけど。

>>787
レジスタウィンドウはウンコだよなぁ。

全身盲腸って。
なんか、自分がハンドアセンブルするときのわかりやすさ、
感覚的ななすっきり具合
で、盲腸とかいってない?

> レジスタウィンドウはウンコだよなぁ。

IA-64 の立場は…

そういや、タスクスイッチするときレジスタウィンドウの内容ってどうするの？
タスクIDでもついてるのか、全部スタックに積んじゃうのか。
後者だとレジスタ多いほどタスクスイッチのコスト高そうだけど、
元々高コストな処理だから気にするほどでもないのかな？

> そういや、タスクスイッチするときレジスタウィンドウの
> 内容ってどうするの？

全部メモリに退避。

> レジスタ多いほどタスクスイッチのコスト高そうだけど、

これはその通り。

> 元々高コストな処理だから気にするほどでもないのかな？

トレンドとしては、コストは若干下がる傾向にあると思う。
Niagara みたいに 32スレッドも CPU 内に抱えてれば、
そもそもメモリに退避することが減るので。

IA-64っていうのはPA-RISCを外販するようにしたもの、なのか。

IA64はIntelがHPのVLIWの技術を分けてもらって作った新アーキテクチャ。
HPが技術協力の見返りにPA-RISCとの互換性を持たせた。

突っ込みあったらplz。

Intelも望んだことじゃないかな。HP-UXがそのまま動かせるからHPの顧客をそのまま引き継げる。
x86はx86デコーダ使ってネイティブで実行するよりエミュレーションしたほうが速いってのは皮肉だよなぁ。
それでも同クロックのXeon並の速度、つまりWillamette並です。Opteron対策として全然役に立ってないなぁ。

32ELなんて飾りです。

>x86エミュ
MercedでもP75並になるんだっけか。

どこで仕入れた情報だwww
それじゃH/Wより遅い。

記憶では月刊ASCIIあたりだったかと。

その昔、Mercedのx86 coreの性能を測ったときにP 200程度だったぞ。
まぁ、ベンチの内容でも全然違うんだがP 75は下に見積もりすぎ。

もはやMIPSなんて、組み込み機器くらいしか使われないんだろうな。

昔は、SGIのモンスター級のグラフィックスマシンのCPUだったのにねぇ、MIPSは。

>>797
HDBENCHの結果ではPentium 100MHz並みだったな。

インテルがx86バイナリでも、
同クロックのPentiumIIIと同等の速度が出る
というのは、いったい何だったのか、と。

>>801
組み込み向け市場の規模からみたら、パソコン市場限定のx86なんて…

でもintelの売上は4兆円クラスで、ぶっちぎりトップだからな

HDBENCHはベンチとしては、、、

>>804
その売り上げって、組み込み向けのフラッシュやXscaleまで含んだ数字なんでしょ？
ちっとも「でも」になってないよーん。

組み込みは段違いに数量出るけど単価＿|￣|○なイメージ
市場規模（金額）どれぐらいなの？

>>807
有名な話だが、AMDが米国の小売市場でシェアトップをとったんだぜ！


そんなAMDが小さく見えるくらいの規模
x86にしがみついて生きてる会社なんてそんなもんですよ
インテルはいろいろ売ってるから儲かる

簡単に想像してもらえればわかるが、身の回りにあるコンピュータと、Petnium/Athlonが載ってるパソコンの数なんて、比較にならないだろ？
携帯電話、ゲーム機、風呂わかし、レンジ、冷蔵庫、時計、テレビ、車、音楽プレイヤー、、、目に入るだけでもこんなんだ
自販機とか駅の改札とか、挙げればどうみてもパソコンの数と比較になりません
本当にありがとうございました

売上はともかく、利益の大部分はx86からだろ
たくさんのメーカーと競争している組み込みやFROMより、
intelとAMDの二社で寡占してるx86のほうが
儲かるに決まってる

>>725-726
セガがガンか。

>>802
そのSGIがMIPSを買収してからMIPSから撤退したメーカーがたくさん出たわけだが
SGIがMIPSを買収しなければx86からMIPSへの乗り換えを提唱した
Ace initiativeはある程度成功したかもしれないのに

>>789
遅延分岐、レジスタペア、アドレスアップデート、単一仮想アドレス

たまにはi860のことも思い出してあげてください。

>>805
HDBENCHのCPU部分は
ドライストンとウェットストンでしょ?
ちょっと古典的だとは思うけどさ。

>>813
i860を搭載したUNIXワークステーションが、クボタから出てたね。

>>811
R4x00の性能だと、intelに比べてあんまインパクト
なかったんで駄目だったと思う

Ace連合って久しぶりに見たな。

MIPS、ALPHAはNT4で打ち止めにならなかったら、もっと伸びてた気がする。

alphaは伸びてただろうね
でも最後はHPに息を止められて
今と同じになってたんだろうな

96, 97年頃のSPECのスコアだと大体
Alpha > PA-RISC > SPARC > MIPS > PPC, x86
くらいだった気がする。癖のある命令セットとかなんとかいってるけど、
あんまネックになってないのはネックになってないよね。

>>818
96,7年くらいということは、
21264, PA-8?00, UltraSPARC, R10000, PowerPC603,4、PentiumProってとこ？

PA-RISCの盲腸は、さほどの害もないがあっても役にたたないのが多いね。かつては気の利いたトリックだったのだろうが。
UltraSPARCは強力なUPAにずいぶん助けられていたと思う。

>>814
呼びましたか？
中身は沖さん（OKIStation7300）でグラフィックエンジンがStardent、OSがKCIです。

OKIstation ですな。
DataGeneral も AViON という i860 機を出してた。
i860 は、割り込みが起きた後の処理がとんでもなく
大変で、全然性能が出なかったって話があったような。

>>821
AViiONは88K
ひっくりかえすとNOVAII

29kを除く初期のRISCはたいてい割り込みハンドリングが大変だったけど、i860は別格かも。88kもひどかったけど。

> AViiONは88K

あああ、間違って記憶してた。どうも。

> ひっくりかえすとNOVAII

そういう意味なんかい。

AViiONの逆はNOIIVAでないかい。

せっかくなのでメタルラック神の文章投下しておこう。
ttp://jun.artcompsci.org/articles/future_sc/face.html#TOC

高橋メソッド版が大笑い。

ベクトルマシンの大メモリバンド幅は、コスト的にもはや割りにあわん
という主旨なんだが、tarusan はこれ読んでどう思うかのう。

どういう話
をするか。
-----------
ベクトルを
買ってはい
けない。
-----------
何故話をす
るか。
-----------
和田君に
命令された。


禿藁

>>792
SPARCのRegister Windowを言ってるんだと思うけど、
SPARCの場合はRegister Windowを2つまで分割して扱うこともできるから、
片方のWindow領域を例えばOSのカーネル用に使えば、全Window Registerを
メモリに退避する必要はないね。
User Process用全部という意味で全部と言っているのなら失礼。

>>820
実際、どんな代物だったんですか?

>>829
薄くて小さい

>>829
OKIStationは普通に素直な作りでしたよ。Mips R3230やDEC Station2100など、
当時のデスクトップワークステーションと構成的には変わりません。
OSはSVR4/i386からi860依存部分を変更したもので、初期のBootMesssageと
CopyRightにはi386の文字がしっかり出てました。

古い書籍で持ってる人がどの位いるかわかりませんが、1989年 ASCII出版発刊の
改訂版UNIXデバイスドライバ(Writing a UNIX DEVICE DRIVER)は、著者の一人
トーマス・テキセイラ(Thomas J.Teixeira)が当時Stardent社員だった事もあり、
Titan Vistra800 をベースに書かれていますので、kernel/deviceまわりはこの
本に目を通すと大体お分かり頂けると思います。

ここからちょっと昔話。

米Ardent社ではMIPS R2000にWeitekのVectorUnitを浮動小数点演算機にし、
それを 1〜4ユニット搭載した TITANを製造・販売していました
（後にR3000+R3010にWeitekのVectorUnit搭載とグレードアップ）。
当時としては最先端を行っていたMIPSのコンパイラに自動ベクトル化／
パラレル化の機能を追加し、廉価にスパコン並みの環境を実現していました。

とは言え冷蔵庫大のサイズですから、これをデスクトップに持ってくる計画が
立ち上ります。開発コードStiletto、仮称BabyTITAN/TITAN500です。
TITANシリーズで使われていた WeitekのVectorUnitを Intel i860に置き換え、
グラフィックサブシステムを統合し IBM PC/ATサイズ（つまりフルタワー筐体）
に詰め込んだ物です。

開発は難航し製品リリース直前までこぎつけましたが、結局ポシャりました。
確か米Stellar社との合併で、開発が重なっていたTitan Vistra800に主軸が
移ったからじゃなかったかな。これがポシャったおかげで日本市場で切望
されていた小規模なTITANが白紙になり、山梨工場R&D の連中が TITANの
バックプレーンを半分にぶった切って TITAN750を作り上げたのは別の話。

で、TITAN Vistra。

OKIStation 7300をベースに Stilettoで培ったグラフィックサブシステムを搭載し、
旧Stellar社のレンダリングアルゴリズムを載せて堂々世に登場…したんだけど、
Stardent社のH/W事業撤退で日本のクボタコンピュータに開発拠点を移し開発続行。
NLXより二周り程大きい程度の筐体に、最上位機種でメインCPU i860、グラフィック
サブシステムに i860x2、合計 3つも載せてた豪勢なマシンです。OKI Station の
ままだとバスのファンアウトが足りなくて急遽バスバッファを強化したとかいう
のはヒミツ。

40MHzの i860による性能はまずまずで、Whetstone 20MFLOPS、Linpack性能で
8〜10MFlops（TITAN 1CPUシステムの半分程度）を出すことが出来ました。また、
グラフィックサブシステムに用いていた二つのi860も演算に使いまわせるように
しよう、という目論見もありましたが、これはキャンセルされました。

実はStardent社はH/W事業撤退の直前まで、i860(XR)の改良版である i860XPを
使ったマルチプロセッサのTITAN後継機種の開発をしていました。が、Intelに
よるi860XPキャンセル（？）で白紙に。モックアップだけで火が入るまでは行っ
てなかったと思う。

そうこうしてるうちにDEC から Alpha発表、OEM供給を受けてTITAN2発売。
50MFlops？は？何その鈍亀（ぷ　って感じ。敵いませんな。んで、Alpha マンセー
とか言ってたら世の中ダウンサイジングでPCの台頭。2000万円でWS買って一人で
やるより10倍遅くてもPC20台で20人同時のほうが効率良いじゃんとか世の中
気がついてWSがバッタバッタと消えて行くっと。

>>832
トンクス。中の人？

TITANってバスが弱くなかった？

一気に良スレ化の予感

CPUのキャッシュについて質問したいんですがスレ違いだったら誘導していただけますか？
http://up.mugitya.com/img/Lv.1_up20314.jpg
このファイルをPDFにリネームして図1を見てください。
メモリーチェインというプログラムを用いてL1/2キャッシュアクセス時間と主記憶アクセス時間、ブロックサイズを推定するというものです。
CPUはAthlonXPのBartonコアを用いています。
配列の要素の大きさは4byteです。

一番低い線が64kBというサイズのチェインを実行したものでL1キャッシュ速度を推定できると考えました。
チェインの間隔を空けても空けなくても時間が掛からないのは一度に64kB分をL1キャッシュ上にロードしたために
どのチェインの要素をアクセスしようとしてもL1キャッシュに100%ヒットするからだと思います。

次に低い線は512kBです。
ここからL2キャッシュ速度を推定したいです。
チェインの間隔が4byte、すなわちチェインとチェインが連続になっている部分に着目するとL1キャッシュとほぼ同じ速度です。
これは一度のロードでL2キャッシュにほぼ総ての配列がロードされたからだと考えました。
それ以降、ほぼ比例的にチェイン間隔32バイトまでアクセス時間が上がっていくのは一度に512kB分をロードできないので
何度も小分けにロードするためと考えました。
4バイト間隔では1度のロード(64kB分ずつ)、8バイト間隔では2度のロード、16バイト間隔では4度のロード、32バイト間隔では8度のロード。
こう考えると64kBずつ8度のロードで512kBのL2キャッシュに総てのデータをロードすることができるのではないでしょうか。
しかしなぜ、チェイン間隔が32kBのところで32クロックという時間がかかったのかが分かりません。
間違えてキャッシュの一部を破棄してしまって再ロードしているのでしょうか。
詳しい方の解説をお聞きしたいです。

>>820さん
昔話ありがとうございます。

>>837
こっちへどうぞ
http://pc8.2ch.net/test/read.cgi/tech/1136527588/

>839
誘導ありがとうございます！

>>835
>トンクス。中の人？
元がつきます。

>TITANってバスが弱くなかった？
し、しししっ、しつれいなぁぁ。
Vistraはともかく、TITANの方は当時のWSとしては強力な部類だと思いますよ。
バックプレーンにはI-BusとR-Busという二つのバスがあって、どっちがどっち
だったかな…一方が通常のR/Wで、片方がReadOnlyの32bit幅、P3システムで
32MHz駆動ですから、最大転送速度で256MB/sec.です。

通常のデータ転送はR/Wのバスを用いますが、ベクタユニット使用時はI/R
両方のバスを用い、ベクタデータの二つのソースブロックを同時に読み出す
事が可能です。つまり、A[..]*B[..]のA列とB列を別々のバスで連続して
読み出しますから、レイテンシが非常に小さくなるわけです。

そしてなんと！(今では普通ですけど）CPUボード、メモリボード共にバスを
切り離す事が可能でした。つまり、CPUがリクエストしたメモリ転送要求を
メモリが受け取った後、実際にデータが現れるまで時間がかかるわけですが、
その時間を別のCPU、メモリが利用できバスの利用率が上がります。

　P2/P3システムではCPUボードを最大4つ、メモリボードを最大4つ（バック
プレーンはグラフィック用を除くと6つまでなので最大4+2か2+4)で構成でき
ますから、マルチプロセッサ構成やマルチメモリ構成の場合に理論値に近い
データ転送速度を実現していました。

大型機やスパコンで使われていた手法ですけど、パーソナルスーパー
コンピュータと銘打ってたのはこのあたりも関係してます。

また、Stardentのもう一つのTITAN、Steller GSシリーズのほうもユニークです。
こちらはデータパス(DataPath)と呼ぶ512bit幅の完全なクロスバースイッチを
中心に配し、メモリ、プロセッサ、グラフィック、IOを結んでいました。

バンド幅の非常に大きなメモリシステムをこのデータパスにつないでいたため、
グラフィックサブシステムは専用のメモリを持たず、今で言うUMA構成をとります。
ビデオDACも直接メモリを参照しちゃいますから、パラパラアニメの性能はダントツ
です^^;

今では、SunのUPAがこれとほぼ同様のバスアーキテクチャですよね。

ConroeとMeromの違いって単にキャッシュとクロックだけなんだろうか？
キャッシュが倍になって、クロックが若干上がっただけで
TDPが倍以上になるもんかな？

Meromにはノーマリーオフ機能がついてるけどConroeはどうなんだろう
FSBアーキテクチャとかも同じなのかな

閾値電圧やVddも違うでしょ。

だな。
製造プロセスのチューニングでVth下げるだけでリーク電流は簡単に数倍は
増やせる。代わりに得られるトランジスタの高速化は20%程度で、配線や
クロックスキューは変わらないから周波数は10%しか上がらない。
Vth化Trはむしろ設計時にクリティカルパスに集中的に使用するのが効果的。

>>843
Yonahの通常電圧版と低電圧版を比べれば、
TDPは倍違うけどクロックは大して変わらない。
それと同じようなものじゃないかな。

捕手

スターデントの裏話をせっかく書いてくれたのにありがたすぎてレスができんですまぬ。プライムの話もあれば聞きたいでっす。

Stellarって細粒度マルチスレッドでしたっけ。Apollo DN10000とあわせて憧れのハイエンドマシンだったよ。
また88kの悪口になってしまうけど、lunaの4CPUモデルは遅かったよ(バスが)。
整数レジスタ上で浮動小数点演算を行う設計も正気の沙汰とは思えん。88110でFPレジスタついたけど。

O2もUMAでクロスバーなのかな。SGIの最後の光かも。本体は1万円くらいだけどOSが高くてなかなか手が出ないや。

ルネサス、600MHz駆動のSH-4A「SH7785」
http://pc.watch.impress.co.jp/docs/2006/0130/renesas.htm

>>849
a[0]*b[0]+a[1]*b[1]+a[2]*b[2]+a[3]*b[3]　がスループット１だもんな
SSEの何十倍速いんだろ

>>849
なんかいろいろ周辺回路も付いてるんだね。
ワンチップマイコンもレベル上がったなぁ。

メモリは外付けだからワンチップじゃねーべさ。

>>850
でもそれだけ速くても話にならないし、Pentium 4でもソフトパイプラインやれば1 DQWORDあたり数クロック程度で済む。
そのクロックで最大単精度4.2GFlopsなら確かにかなりの速度だけど、Pen4なら15GFlops逝くからね。

SHのISAはRISCの中でもコンパクトな部類だけど、即値が使えなかったりするからx86のほうが速いケースも多いよ。

液晶ディスプレイコントローラーって……PowerVR？

RISCでimmediateに制限が発生するのは仕方が無い。しかもISAをコンパクトにすれば当然だ。
団子は下らん事を書いてオナニーする癖がどうにも直らんな。

>>854
ええっ

今気づいた。
4.2GFlopsって4要素・4要素の積和算で7オペレーション分だから単純にクロックのちょうど7倍ってことか。
なるほど。激しくクロックがあげられない気がするのは俺だけ？

しかしSSE3の水平加算ってやたら使い勝手悪いのな。
同等の演算を、巧くソフトパイプライニングして1DQWORDあたり10クロック程度？
参考 ftp://download.intel.com/design/Pentium4/manuals/24896612.pdf

どうみても低速です。本当にありがとうございました。

>>857
ベクトル化が上手く填まるようなコードでは、もはや演算速度は問題じゃないでしょ。
スループットはメモリ帯域だけで決まるといって良い。

>>857
実はSH4はドリキャスの時代からクロックの７倍Flopsと主張してる。
クロックの向上に伴ってメモリも高速化してるので実性能が出ないことはないと思うが。

D$にのっかるデータだけをこねくり回すならそこそこ出るよ。

>>854
SH4はもともと128birの2Dグラフィックコア内蔵してて
ドリキャスはそれと別にPowerVR2を搭載してたんだよん。
それで128bit機を名乗っていたのはどうかと思うけどな。

STMicroとの合弁だったからそっち由来のコアかもしれんね。

ソフトパイプラインなんてやってられるか！
MMXや3DNow!でもできる積和をクロックアップのためだけに排除しているSSEは
イヤガラセでしかない

SH778xは2D/3Dアクセラレータ載ってない。
SH7770とかSH-MobileにはPowerVRが入ってる。

>>862
＞クロックアップのためだけ
それだけで十分な理由だと思いますが何か？（漏れそれが(・∀・)ｲｲ!!ﾄﾚｰﾄﾞｵﾌかどうかはわからないけど）



＞イヤガラセでしかない
は、もっと不条理な仕様のための言葉かと

無用に演算コストの大きい命令サポートすると高クロック化が難しくなるってのはPowerPCとか見てればわかるかと。
でもMPC7450シリーズはすごくいい石だよな。バス帯域が狭いけど。

>>857
> 激しくクロックがあげられない気がするのは俺だけ？

なんで?

レイテンシが1ではないよ。
スループットが1だよ。

クロックを上げるのを阻害するのは、
1ステージの長さですよ。

>>866
ステージ細分化（レイテンシ増大）すれば上げられるのは解ってるよ。PPC970がそうやってるし。

Dreamcastってたしか200MHzだったけど、x86ではDeschutesの450MHzや初代Xeonがハイエンドの頃だろ。
SHのクロックが3倍伸びる間にx86は5倍以上伸びてる。
熱設計の制限のきつい組み込み向けと比べるのは酷かもしれんが、
Pentium MならPentium II/IIIと消費電力そんなに変わらない（むしろ落ちてる？）のに
2.26GHzまで出てること考えれば、SHの進化って鈍いんじゃね？

>>867
SHの展開が遅いのは別に今に始まった事じゃないから。
まあ会社の合併やら大変なんだろうなとは思うが。

SSE3の水平加算はK8のほうが性能いいな
Yonahで改善されたか気になるな

PenMはそもそもSSE3サポートしてませんから。
ところでアレ水平加算って言えるの？Intelの開発マニュアル読むにDWORD単位で転置してからaddしてるだけじゃないかと。
PenMはレイテンシの小ささがイイ感じだけど、浮動小数は実クロックが命かと。
MMX＞SSE2整数がSSE2整数≧MMXくらいになってると思っている。

どっかで見つけた4要素積和算

SSE2
mulps xmm0, xmm1
movaps xmm1, xmm0
shufps xmm0, xmm1, 0xb1
addps xmm0, xmm1
movaps xmm1, xmm0
shufps xmm0, xmm0, 0x0a
addps xmm0, xmm1

↓
SSE3
mulps xmm0, xmm1
haddps xmm0, xmm0
haddps xmm0, xmm0

普通に計算したら依存関係のチェインで33クロックかかる。並列実行でようやく元が取れる。
てかレジスタ8本しか無いのがきつい。

>>869
K8では下のコードで15クロックらしい。実クロックの差加味してもK8のが上だな。

続き。どうみても3D NOW!のが高速です。
とっさに思いついた4要素×4要素の積和算2セット同時実行。

pfmul mm0, mm4 -並列実行可能
pfmul mm1, mm5 ┘
pfmul mm2, mm6 ┘
pfmul mm3, mm7 ┘

pfadd mm0, mm1 -並列実行可能
pfadd mm2, mm3 ┘

pfacc mm0, mm2

最後にmm0の上下に2セット分のデータが入る。pfaccってすごいリッチな命令だな。

レジスタ全部使ってるけど、メモリからロードしてもレイテンシは十分隠蔽可能なので
まだまだ並列化の余地は十分ある。

※K8ではmulpsはマイクロアーキレベルでは上下に分けてpfmul×２発行してるだけの実装。
しかもデコーダの負担はxmmベース1命令＝mmベース2命令
mmレジスタのほうが小回りがききやすい→MMX/3D NOW!のほうが速い

小さい計算だけで比較して命令の優劣を語るバカ

大きい計算やってもSSEはうんこ

SSEはユニットが128bit化されてから価値が出てくる。それまではMMXや3D NOW!のが速くても已む無し。
つかK8の整数/単精度浮動小数でSSE＞MMX/3DNOW!になるケースってほぼ皆無じゃね？

Pentium 4はL/Sだけは128bit化されてるからロード/ストア回数が多い演算に限ってはMMXよりSSE2整数のが有利。

じゃあ
プレス子のSSE3で4要素×4要素の積和算4つな

mulps xmm0, xmm1
mulps xmm2, xmm3
mulps xmm4, xmm5
mulps xmm6, xmm7
haddps xmm0, xmm2
haddps xmm4, xmm6
haddps xmm0, xmm4

データシートどおりなら多分これで40clkくらい。
レジスタ無駄遣い辞めて8並列くらいやればもっとスループット上げられるかも。

>>867
当時は200MHzがそもそも無理したクロックなので、166MHz版と比較してやってくれ。

>>867
消費電力やプロセス、パイプラインの段数を考えればSH4はそんなもんじゃないのかな？

組み込みだから割込応答を考えるとパイプライン段数は増やせないし、熱設計を考えれば
プロセスを細かくした分を純粋に周波数アップにも使えないだろうし。