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

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

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

ソフトとハードはちょっと流れが違うなーと思ってさ

>>770

当初からハードウェア関係者からは叩かれてる > JAVA仮想マシン
Hotchipsでパターソンとかに突っ込まれてたよ〜な〜。

以前、FJでもバトルがあった。>>JAVA仮想マシン

>>753
印刷して参考書片手にがんばれ。

調べてみた(はじめて読むpentiumを参照)。
x86の場合アドレスバス(32本)の仕様は、1、2、4byteのデータを読むための
アドレスを流す。これから、1byteの時は、1の倍数、2byteの時は2の倍数、
4の時は、4の倍数アドレスしか流れない。>>762さんが、言った
「そもそもアライメント不整合なアクセスはできんし」はこれが理由だと思う。

流されたアドレスから、データを読むときデータバスは64本なので、一度に8byte読める。
さらにデータバスの一部だけを使うってことも出来るそうな。
だから、8byte以内ならば一回のアクセスですむ。
8byte境界をまたぐような、変なデータの並びになっていると、
アドレスバスに、流れるアドレスを変えなくてはいけない。
alphaは、データバスの一部だけを使うっていうのが、無いのかもしれん。
これは調べて見る。>>732さんの発言がそれを匂わせているような気もするし。
VAXだと、データの並びなんかお構いなしだったんだけど、何か秘密がありそうだな。
VAXのアドレスバスと、データバスの関係も知りたい!
やばい、仕事より面白くなってる。

>>774
アドレスバスは、搭載されたメモリチップ全部が共有している。
従って、アドレスバスの内容を、一部のチップだけ変更するような形で
複数のアドレスを一気にアクセスすることは不可能。
これは基本的に、CPUのアーキテクチャとは無関係。

で、アドレスバスの内容が同じであっても、
そのうち一部分のメモリ内容だけを取り出して、
特定レジスタと値を授受するためのハードウェアは、
x86などには搭載されているが、アルファには搭載されておらず、
アルファの場合は読み込んだデータを
シフタやアンド命令によって加工する必要がある。

最新マイクロプロセッサテクノロジって本の旧版(増補版でない方、96年頃発行)
なんか参考になるかも？

いやきっと不十分だ。
まあ、このレスの内容ぐらいまでならば、その本でも充分だけど。

Windowsのタスクマネージャで見るCPU使用率ってなんでしょうか。

CPU使用率100％の場合、CPU内部のどの箇所が限界に達しているのでしょうか。演算ユニット?内部バス?

>>776
アイドルプロセスが動いて「いない」時間の割合っていうだけで、
実はCPUが忙しいとは限らない罠

｢AlphaAXPアーキテクチャ概要」をみつけた。
"Alpha Architecture Handbook"
http://ftp.digital.com/pub/Digital/info/semiconductor/literature/alphaahb.pdf
の訳本。
訳者序文に、夢いっぱいなのが、いまとなっては哀しい。
で、775さんの言っている通り、バイト操作に関する命令が無い、回路も無い。
もう、32、64bitアクセスに命をかけるといった思想のようだ。
VAXの文献は、会社の書庫から、
"VAX11　ARCHTECTURE　HANDBOOK"、"VAX　HARDWARE　HANDBOOK"というのを
引っ張りだしてきた。
VAXには、バイト、ワードムーブ命令がある。命令コードも定義されている。
ということは回路があるってことだな。あーすっきりした。
しかし、もうこれは、トリビアの世界だな。
ありがとう、レスくれた皆様。

最新マイクロプロセッサテクノロジの旧版、アマゾンで注文しました。
送料込みで680円だったし。

きてみたら話がおわっていた。
>>778
そうなんだけど、それはトリビアではなくてAXPの本質なのでは。

勝手に、話終わらしてごめん。
トリビアといったのは、VAXといいalphaといい、フェーズアウトしていったCPUの
知識って、自分以外には無駄知識なのかもと感じたから。

でも、ソフトを組む上で、それを知っているかいないかでは、設計に違いがでるよね。
この仕事が終わったら、次はSUNねと言われた。もう、SPARCしそう。

>>778
その本は 21064 つう最初の chip が出た時の本で、
21264 つう２世代後の chip ではバイトアクセスも
できるようになってしまいました。
ワードアクセスしかできないのは CRAY-1 とかでは
よかったけど、WS だと雑用が多いのでしょうね。

雑用と言うか文字操作。バイトロードなんて大した事無いんだから無いのが
おかしい。ストアが面倒なのは理解できる。

いつの間にかバイトロードストアの話になっているが、もともとはアラインの
話だったよな。さすがにミスアラインのロードストアはできないだろ。

たいしたことないからコンパイラが吐いて毎回実行すれば
いいはずだった。

VAXのマイクロコードを納めたメモリのサイズが cache の何倍も
あって気持悪いから RISC したのに元の黙阿弥。

バイトロードをハードで作るのが大した事無いんだって。
Cのコードだといちいち符号拡張するようなコードを付加しないといけない。
最適化で大体消せるはずだが。

現実は、そうなったのでそうなのでしょうね。

アラインの問題は、cache からのロードでもペナルティがあるんでしょうね。

alpha は今の複数CPU を突っ込むところまで生き残ったらおもしろかったと思う。
(韓国の景気後退がなければサムソンが頑張ったのに)

> アラインの問題は、cache からのロードでもペナルティがあるんでしょうね。

むしろメモリからのロードはキャッシュライン分ごっそり行われるから、
ほとんどアラインもくそも．．．と思う。
キャッシュラインは Athlon や III が 64bytes で 4 が 128bytes だっけ？

>>784
どうだろう。結構クリティカルパスになりそうだが。

>>785
三星さんは買ってきて放置して腐らすのが得意だから
どっちにしろだめぽだったんじゃないかなぁ・・・

>>788
低価格Alphaでは一応三菱と組んでいたのですけどね。
その忘れ形見の21164PCマシンがうちに一台落ちてますけど。

たしかAMD-761チプセトのAlphaマシンを出してたよな。非常に欲しかった覚えが。

AMD761はそれほど速くないﾜﾅ。

Tsunamiに比べてメモリバスが圧倒的に細いからな＜irongate
AGPが使えるぐらいしかメリットないだろうね。

速いかどうかなど問題ではない。
Alpha + AMD chipset(=PC世界) という組合わせが
コレクター魂をくすぐるわけですよ

コレクトするならただで配っていたときに手に入れればよかったのにね。

>>781
alphaでも世代によって、命令コードが追加されてるのね。
自分が個人所有しているのは、multiaで、alpha21066, 166MHz だったりする。
今、FreeBSD　alphaをいれているけど、OpenVMSのHobbyistに挑戦しようかなと
思ってたりする。

アラインの話、蒸し返すようで悪いんだけど、
BYTE、WORDという順番で、データをならべたら、OpenVMSのフォートランコンパイラが、
ミスアラインだよと警告してくる。メモリ上の並びが、
アドレス：データ　と表現すると。
00　　　:Byte
01　　　:WORD(下位)
02　　　:WORD(上位)
となっていて、WORDがミスアライン。
WORDをアクセスする時にアドレスバスに、流すのは、00、02の二回流さなきゃならない。
バイトアクセスできたとしても、01、02の二回必要なのは代わりが無い。
そこで、新たな疑問が湧いた、
「WORDをアクセスする時にアドレスバスに01を流さない(流せない？)のはなんでだろ」
>>782氏のいう「さすがにミスアラインのロードストアはできないだろ」
この、理由を調べてみることにする。

>>795
x86あたりだと健気にバスサイクルを分けてロードストアするけど。
今時のプロセッサだとアドレス下位ビット叩き落して適当にロードストアする。
例えば0x000C番地からワードストアしようと思ったら、
適当に下位2bitを落として0x0008番地からワードストアしてしまう。
構造体などを無理やりキャストしてアクセスするお行儀の悪いプログラムはこれではまる。

「さすがにミスアラインのロードストアはできないだろ」はこれを指してると思われ。

各種プロトコルで、バイト単位で詰め込んであるのを、構造体でダイレクトにアクセスする
っていうコードは、Alphaの人はどうするの?

>>796
今時のプロセッサとは具体的に言うとどういう種類？

>>797
今まさに、それで困っている。
VAXの構造体のデータがバイト単位で詰め込まれている。それを、alpha側で、
読もうとすると、同じ定義の構造体でも、メモリ上の格納位置が違うため、
データがずれる。アライメントをあわせるために、未使用域が追加されてしまうから。
で、自分の主張は、ミスアラインでも良いから、バイトで詰め込んであるのだから、
そのまま読みましょうよと提案したんだけど、ミスアラインも嫌、VAX側のデータ
構造も変えたくない、何とかしろ、などと無理なわがままをいう人がいるので、
それは無理ですというために、いろいろ調べている。

異ベンダーのマシンとの通信で、メモリデータの転送をするのを組んだ時は、
alpha側で、双方の構造体の構造を定義したデータ(データタイプは何で、オフセットはどこからで)を持って、
その定義をみながら、向こう側のこのデータは、alpha側では、このオフセットから何バイト書き込み、
とかひとつひとつやっていた。エンディアンも考慮して、バイト反転が必要な場合は並べ変えるという
処理をアプリケーションでやってた。今はどうか知らないけど、当時のDigitalUNIXは、
ミスアラインアクセスが起こるたびに、メッセージが表示されてた記憶がある。

>>796
0x000C番地->0x000B番地 ですよね。
強制2bit落としだと、確かに、ミスアラインは無しですね。

プログラムリスト上の定義と、実際のメモリ上の配置、そのデータがCPUで
どういったルールで処理されるか、を知らないと、
お行儀の悪いプログラムははまりますね。

すんごい手間になってるのね。
日本語と英語の翻訳解釈に通訳が苦労するみたいな感じに思える。

アンパックの部分だけアセンブラで書けばいいんじゃないの？

Cコンパイラはアライメントのことを隠蔽してくれないの?

x86でVC使いなんだけど、
その手の構造体の宣言の部分だけ、アライメントの単位を1バイトに変更するよ。
そうすれば、あとはコンパイラが適当にやってくれる。

Alpha用のCコンパイラでは、部分的にアライメントの単位を1バイトに変更する機能ないの?

>>787

>どうだろう。結構クリティカルパスになりそうだが。

正解。アライナを抜けるのは結構時間がかかるのよ。
しかも、キャッシュから読んだ後にここを通るから厳しい。
パイプを深くすれば周波数は上げられるけど、後続
命令で使っていたらストールしちゃってCPIは下がる。
性能命のCPUだったらバイトだろうがなんだろうが、
32bitなり64bitなりにアラインしている方がいい。

ちなみに、ワードのミスアラインで自動的にバスサイクルを
２回起こすチップも作ったことあるが、これはそんなに
クリティカルだった記憶はないっす。
昔のことだから単に忘れているだけかも知れないが。
あっ、でもダイナミックバスサイジングまでやると厳しい。

いつまでも、バイトが基本の Unix が生き続けたのが誤算だったか

>>805

っていうか、0〜255とか限られた範囲しか取らないデータに32bi使ったりするのは
抵抗があるからだ。
ちょっと使うだけならともかく、構造体とかは検索とかに使う事が多いから
なるべるオンメモリでやる事を願って節約したくなる物でしょ…。

バイトロードって、ワードロード+8nBit Shift+符号拡張だけですけど、
それほど問題になりますか？

797さん
自分が今まで調べた知識からの推理なんだけと、VCの「アライメントのことを隠蔽」とは、
ワードを読むのに、バイトバウンダリで１インストラクションで読むのではなく、
バイトアクセス２回でやっているのだと思う。使う側からすれば、ワードが
読めればよいのだから、表面上はわからない。これを隠蔽と解釈した。
X86の場合、バイトロード命令があるから、まだましだけど、alphaには(初期チップだが)無い
から、また余計に手間がかかる。
alphaの場合、隠蔽するのを良しとしなくて、「性能を上げれるよ」ということを、
積極的にユーザに通知すべしという考えなんだと思う。
コンパイラでの警告は、まだ許せるが、実行イメージ(実際に出しているのはOS?)だろうが、
メッセージを出すのは勘弁してほしかった。
>Alpha用のCコンパイラでは、部分的にアライメントの単位を1バイトに変更する機能ないの?
部分的にというのはわからないが、構造体のデータ並びを最適化しないオプションがあったと思う。
かなり怪しい記憶だが。
ちなみに、今やっているのはFORTRANだったりする。
>>802さん
当時の自分にはスキルがなかった。(今でも無いが、当時に比べたらもっとエレガントな実装も思いつくかも)

>>808
/nomember_alignment

>>803
特になにもしなくても32bitアラインでパディングしてくれてた記憶が・・・

>>808

アラインミスのアクセスをすると例外になって OS まで行って
OS がごていねいにデータをちゃんと設定して戻してくれるけど
すごいオーバヘッドだからコンソールメッセージ位は出しても
よさそう。

>>758
遅ﾚｽだけど、ICC8.1の出力（ｵﾌﾟｼｮﾝ /QxP /O3）

;;; for(i=0;i<LEN;i++) for(j=0;j<4;j++) a[j] += b[j] * c[i];

movapd xmm1, XMMWORD PTR [esp+48] ;8.46
movapd xmm0, XMMWORD PTR [esp+64] ;8.46
xor eax, eax ;8.6
ALIGN 4
; LOE eax ebx esi edi xmm0 xmm1
$B1$2: ; Preds $B1$2 $B1$1
movapd xmm2, xmm1 ;8.53
movddup xmm3, QWORD PTR [esp+eax*8+80] ;8.53
mulpd xmm2, xmm3 ;8.53
mulpd xmm3, xmm0 ;8.53
addpd xmm2, XMMWORD PTR [esp+16] ;8.38
addpd xmm3, XMMWORD PTR [esp+32] ;8.38
movapd XMMWORD PTR [esp+16], xmm2 ;8.38
movapd XMMWORD PTR [esp+32], xmm3 ;8.38
add eax, 1 ;8.16
cmp eax, 100 ;8.2
jl $B1$2 ; Prob 99% ;8.2

Alphaの話はもう無いのか。

>>809
OpenVMS alpha Cだと、そのオプションでＯＫですね。
OpenVMS alpha FORTRANだと、
/ALIGNMENT=(COMMONS=(PACKED,NOMULTILANGUAGE),RECORDS=PACKED)
で、コンパイルワーニングは出るけど、境界整列しないでバイト詰になる。
Tru64 のCでは、 -misalign　を付けると、バイト詰にはならないが、
実行時のミスアラインメッセージを抑制してくれる！
今ごろ発見かよ．．．onz
当時の俺に教えてあげたい。知ってれば誤魔化せたのに。
コンパイルオプションを良く調べなかった俺が悪いのか。
でも、最適な速度でアプリが実行されているぜ。と自分を慰めてみる。
ちなみに実行時ミスアラインのメッセージは、こんな感じです。
Unaligned access pid=20985 <a.out> va=11ffffd29 pc=120001238 ra=1200011a0 type=ldl
こんなのが、ワサワサでると、原因突き止めて直せといわれるわな。

質問です。
なぜ、CPUのクロックスピードに2.93GHｚといった
端数が出てくる場合があるのでしょうか？

>>815
CPUのクロックはベースクロックを数倍にしたものだから。
例えばベースクロック166、倍率が11倍のCPU（AthlonXP2500+)だと
166 x 11 ≒ 1.83GHz
みたいな感じになる。

>>815
ワインの樽みたいに少量のクロックが内部で蒸発するんだよ。

>817
天使の分け前かw

おまえらあたまいいなぁ
ドリキャスでここみてるおれにはさっぱりだ

815です。
816さんありがとうございました。

>>819
ドリキャスはSH4だよね。
記憶が正しければ、さらに音楽専用に68HC000を積んでる。

ついでだからSH4の話に移行すれ

SH4は渾身の力作

SH-MobileイイYO！

Athlon64 4000+はいつ発売されますか？

SH4がPS2のEEにかなわなかったことを考えると
ゲーム機では汎用のCPUが主役になりえないという証拠だろうな
ルータで復活してほしいが、どうも省電力化に成功してない。
PDAもARMに押されて……

ARMときたら任天堂DS

SH2はどえりゃー割り切った設計のCPUだと思った覚えがあるが
SH4はどんなだっけな・・・

ISA的にはふつーのチップだったと思うけど＜SH2
16bit固定長命令、基本はop8-r4-r4の命令フィールド。

ブロードバンドルータのOPTにSH4が使われてるけど、
CPUの善し悪しは関係ないからなぁ。

もちろん、熱暴走したりするような論外な奴とは次元が違うよ。

ゲーム機に使われているCPUか。SH4、面白そうだな。
ちょっと調べてみたら、マザーもあるじゃないか。
http://www.interface.co.jp/catalog/prdc.asp?name=mpc-sh02
自作できるな。いくらするんだろう。
X86系以外で、自作できそうなCPUの話題が出てきたのは初めて？

>>831
凄く高いよ。普通のPC用マザーと同じ値段では買えない。
組み込み向けのシステムの評価に使うくらいだと思う。
SH4でLinuxを試すなら，IOデータのNASを買うのが安い。

ルータはCPU性能が低いとパフォーマンスがでない。
この分野ではMipsが多いような気がする。
SH-4はMipsやARMがライバルだと思うけどPDAでもルータでも勝てない
携帯は型落ちの設計を流用しているので単価を高くできない。
いったいSHは何をしたいんだか……

家庭用ブロードバンドルータで最高速を出すSuperOPTは、SH4ですよ。

あーでも、SuperOPTは日本で設計してるからSH4なのかも。
海外で設計してる、他のほとんどのルータではSH4使わないからなぁ。

>>832
一瞬、本気で問い合わせようと思ったがやめた。FA用は良い部品使っている
かわりに、高価だからな。高いのもしかたないか。
手軽にSH4いじれる方法ないかな。
ドリキャス改造とかやっているところあるみたいだから、プログラム書き込んだり
できるような気がする。

>>836
各種エミュプレーヤにしたり、
かなりいじっているみたいよ。

VAIO type XはSH搭載。
富士通はEden搭載。

>>836
この会社のボードは値段が結構手頃だと思うよ。

ttp://www.embedded-sys.co.jp/shop104/ms104sh4.htm
>MS104-SH4 は、32bitRISC_SH4CPU を搭載した組込みシステム用途の小型ボード(PC/104 規格準拠)です。
>10/100baseT, CF, RS232c, RTC, SDRAM,Flash 等の機能を搭載しています。

□CPU ：SH7750R 240MHz品

□RAM ：32MByte SDRAM
□ROM ：16MByte Flash メモリ
□Ethernet ：10/100BASE-TX(RJ45) 1Port　LAN91C111
□CompactFlash ：メモリカードモード対応／I/O カードモード対応可能
　ホットスワップ対応, 3.3V カードが使用可能, Type1(カード厚3.3mm), 1Port
□外部バス：PC/104 サブセット
　16bitバス幅
□RS232C ：2Port ( COM1:TXD,RXD,GND COM2:TXD,RXD,RTS,CTS,GND)
□RTC：キャパシタによるバックアップ(170h)
□電源：＋5V 単一電源
□基板サイズ：95.9×90.2×1.6mm Layer6層,両面実装
□H-UDI/JTAG 14pinインタフェース

44,940円

SH-4のFIPR命令はベクトルの内積をスループット１で実行するありがたい命令
Intelはこういう命令を絶対に実装してくれない

>>834
SuperOPTの事をよく知らずに恥ずかしい書き込みをしてしまった……
だけどこれだけの性能でシェアが取れない営業力は……

セガと運命を共にしたような状況が哀愁を感じさせる。

SH-4がEEに敵わないのは単純にトランジスタ数や外部バスの数の差じゃないかなあ・・・

トランジスタ数って言ったらどうしようもないだろ。
それより特化した方がいいんじゃないのか？価格か性能か省電力かとか。
どっちつかずだとセールスもしにくいだろ。

んで完全にｽﾚ違いになってる気がするのでちと聞きたいのだけど
未だにムーアの法則って成り立ってるの？
4GHzを越える気配無しじゃない？

ムーアの法則は周波数のことを言ってるのではなくて
半導体の集積度のことを言っているだけ

>>841
海外の設計屋が採用しやすいように、技術サポート体制を充実させるしか。

SH系はASICに特化してて縁遠い…。
標準品がイマイチだし…。

ところで今のCPU業界がx86を捨てるのはいつになるのだろう・・・

ソフト資産が膨大すぎて無理

インテルとAMDが火事になって全生産プラントと設計資料が燃えたらあるいは……

>>850
そしてどこかが車輪の再発明をすると。(x86互換として)

>>849
IA-64デスクトップ全面展開でこの先x86フリーの可能性があると思えた日々が懐かしい（遠い目）

Alpha 互換機や PowerPC 互換機(CHRP)に夢を馳せた日々は遥か彼方...

気がつけばSunが♪を採用してる時代とは…

なぁ、今はもうマルチコアな時代に突入ですよ。
なので、GPLで過去にある全プロセッサを
搭載したマルチコアなGNU Processorを出すのだ。

>841
SH4+Routing処理専用ASIC搭載だったりする罠
CPU自体の性能はそれほどではないと思うけど。。。

>>856
じゃあ、やっぱだめじゃん
と思ったけど、知らない間にSH-4Aが出てるのか。どうなんだろ。

SHって、SuperHの略で、やっぱりHはHitachiのHなんだろうな。
｢スーパーひたち｣か、
http://www.katomodels.com/product/images/651kei/651kei_1.jpg
651系は485系の後継らしいが、これ見る限り古さを感じさせるな。

>>856
専用ASIC積んでないですよ。
少なくとも、OPT100とOPT G5の基板の写真を見る限り。

>>859
ひょっとすると、
専用ASIC上にSH-4が搭載されてるとか？

いや、現物見てないのでわからんけど、
SH-4はASIC上に(ASICの内部に)実装するようになったんでしょ？たしか。

>>860
チップの刻印は↓です。
http://bb.watch.impress.co.jp/column/review/2003/09/17/ph08.jpg

これってASICなのかな・・・。

>>861

そいつは標準品。
ttp://www.renesas.com/jpn/products/mpumcu/32bit/sh/sh7751r/index.html

凶箱はPen3(セレとも言えるけど)だしなぁ...
海外じゃ1.2GHz位のセレに換装した代物が売られてたりする（もち非純正

ドリキャスはSH4を240MHzにOCして遊んだなぁ。今でも元気に動く。
セガラリー2とか首都高バトル2の処理落ちが結構改善できたり。
冷却系をいじらないとオーバーヒートでフリーズするけど。

民衆のマシン クラスタは
安くて速くてよいマシン

ベクトル機では高すぎる
専用機では品がない

民衆のマシン クラスタは
安くて速くてよいマシン

結局SHシリーズがリテールパッケージでPC店に並ぶのは無いってことね。

強いて言えば秋月通商か若松半導体部

リテールパッケージで店頭に並んじゃうCPUのほうが稀有だけど、
昔の若松みたいにCPU単体を扱う店はへったよなぁ…。

SH4使うならOSはOS-9な、約束だよっ(嘘

ハドオフにドリキャスのジャンクを探しにいったが、3000円だった。
ゲームできなくてもいいから、500円ぐらいでないものか。
セガサタなら、あったのだが。
SH4の記事が、インターフェース増刊号で発刊されていた。
買うかどうか迷う。

>>868
3000で状態よければいいじゃない？
音源から全部コミコミセットでいろいろ遊べるみたいなのだし

DCで遊ぶならBBAと対戦ケーブルの有無が重要ですな。
無いといまひとつ面白くない。

>>870
カニチップのBBAを未開封で腐らせているおれ

ところで419は何のためにいつまで数字コテハンを名乗っているんだ？

たんにフォームに残ってるだけなんだが。

419のネタをひっぱりたいのかもしれない

消せないの？＜フォーム
ただの目立ちたがり？

電車の中で若い女性がプーと屁をこいたらしい。
すると、その女性は突然、隣りに座ってるおじさんに話しかけた。「おじさん、お腹の具合でも悪いのですか？」
そのおじさんは、でかい声で言い返した。「わしが腹の具合が悪いのと、あんたが屁をこくのと、何の関係があるんだ。」
その女性は次の駅で降りたのは言うまでもない。

>>870
>>871
★ドリキャスをPC経由でネットにつなぐ★
http://pc5.2ch.net/test/read.cgi/network/966240838/

名前欄消しといた。
Tru64とOpenVMS買ったので遊んでみる。

AMDが気張り過ぎた。
x86は20世紀の過去の遺物と化す予定だったのに。

>>879
しかしSPECintの結果を見るにつけ、x86 ISA(FP除く)は実はかなり優れていたのではないか
という疑念が頭から離れん。

>>880
x86が速いのはシングルだけ。スケーラビリティが低いのは何とかして欲しい。

>>881
それはISAのせいではなかろう。

>>882
じゃ何のせい？この辺をうまく考察できた奴はいままでどのスレにもいない。

x86のメモリモデルってどうなってるの？
SPARCでいうところのTSOとかRMO見たいな奴。

>>880
ISAって命令セットのこと？

>>885
命令セットアーキテクチャ

>>883
ほかの事が原因であることを説明しても、ISAが起因していないということは
説明できないからなぁ。
まず 881 or 883 が x86のスケーラビリティの低さがISAに起因していることを
説明すればよいと思うだが。どうだろうか？

スケーラビリティが低いって具体的に何の事を言っているの？

>>888拡張性
いろんな使い方するけどこのスレ的にCPU限定だと
CPUを２個→４個→８個→いっぱいに増やした時に単純合計性能から実性能がどれぐらい減ったか
いくらCPU数増やしても実性能があんまり上がらない＝スケーラビリティが低い
＃　とするとPowerPC440カスタムチップ数万個のBlueGene/Lは（Linpack限定で）そこそこスケーラビリティあることになる・・・ｗ







ところで久しぶりに読み直したけど
＞Prescottは10年に1度の大きなアーキテクチャ変革
http://pc.watch.impress.co.jp/docs/2004/0209/kaigai062.htm
そういえば386も性能的には？なCPUだったっけ
http://www.atmarkit.co.jp/fsys/pcencyclopedia/007procs_hist01/procs_hist02.html
淫照ってアーキテクチャ大変革した直後は力使い果たして性能＝放置なのかもｗ

Prescottはマイクロアーキテクチャの変更だけど、80386は命令セットアーキテクチャの
変更なのでちょっと違うと思うけど。
それにPrescottｎの性能が出ないのは、90nmCMOSテクノロジがリーク電流が多過ぎて
予定どおりにクロックを上げられなかったのが原因で、マイクロアーキテクチャの変更
とは関係無いのでは。

90nmなら消費電力減るから電気食い回路でも大丈夫。更にクロックもageられる
　↓
前提崩れてもうだめぽ

でなかったっけ？

>>891 そうだと思う。

90nmテクノロジで消費電力が減る
↓
Tr数を激増させてパイプライン段数を増やしテクノロジの性能向上以上のクロック向上を狙う
↓
90nmテクノロジの問題でリーク電流が多く予想どおりに消費電力が減らない
↓
クロックを上げると消費電力が激増するのでクロックが上げられず
↓
性能が思ったより上がらない

>>889

SPARCの"S"はScalableであったな。
881が何をいいたいのかチトわからんが。

>>892
でも、AMDは90nmでも結構うまくいってるんだよな〜CPUの構造の違いなんだろうか？

>>894 IBMから技術導入したSOIの威力、という説があるけど。

P4に比べてクロックが低めってのも効いてそうだ。＞90nmのAthlon 64

>>895
IBMのSOIが特に優れてるわけではないかもしれんぞ
Ｉｎｔｅｌの90nmだってｸｿなのはﾌﾟﾚｽｺであってPenMは消費電力削減に成功してるしな

NetBurstは倍速ALU積んでて、一部のゲート速度は表記クロック以上だし。
加えてPrescottはそれ以前のと比較してパイプライン1.5倍、キャッシュ2倍、
64ビット拡張用のロジックとレジスタファイルっててんこ盛りだから、
そりゃ消費電力尋常じゃないでしょ。

ぜんぜん命令セットの問題じゃないじゃんｗ
バス、メモリアーキテクチャの問題だったりネットワークや
プログラミングモデルの問題ならわかるけど。

単にIPCの限界が命令セットにあるといいたいのかな？
スーパースカラになっちゃうと（VLIWとかは別として）
どこも変わんない気もするんだけどね。

Blue GeneとかスパコンってＣＰＵいっぱい使って高速化してるじゃん
今の技術でZ80を１ダイに１万個くらい乗っけたら速くなんないかな

制御する方にパワー喰われてｼｮﾎﾞﾝﾇに1000ｶﾞﾊﾞｽ

>>900
スパコンって並列処理で高速化してるように見えてるだけでしょ。
直列処理やらせても大して速くならんが。

亀レスだが
>>878
Tru64ならまだしも、OpenVMSに挑戦するとは漢だな。
Itanium2用の評価判を持っているが、ハードを持ってない。
一時は、VMSも生き長らえるかなと思ってたんだけど、
HPは、もうIta2用のワークステーション出さないっていっているし、
HP-UX11iv2も、PA用に対応させる動きもある。Itanium2失敗の動きが加速してるね。
なんかもう、全てx86に収斂して行きそうな気がする。つまらんなー。

>>903


CPU大統一時代の到来だよ。

>903
HPはアーキテクチャクラッシャーになってる(継子どころか実子まで処刑)が、
IBM の POWER は可愛い子に育ってます。
SUN の SPARC はグレ気味か。

>>898
それだけ高クロックで動作してるというのに、
圧倒的にクロックの低いアスロンやPentiumMと同等性能って、
クロック上げる意義が失われている。

倍速ALUのクロックが最高速モデルなら7.6GHzだとして、
実クロック2.4GHz程度のAthlon64と性能の差がほとんど無いなんて、
以下に無駄な高クロックであるか...

>>900
どっちかっちゅーとその方向で考えられたのがCELLかな
実行性能は現物がでてこないとわからんが

>906
結果的にその倍速クロック部分が熱湯クロック向上の足枷になったという
分析をしている人(サイト)も多いよね。
つーか intel 自身が認めたんだっけ?

http://www.aceshardware.com/SPECmine/top.jsp
スケーラビリティが低いっていうのはCPUの数を増やしたときに性能が伸びにくいということ。
x86はIA-64やRISC系のCPUと比較してスケーラビリティが伝統的に低い。
よくバスの問題とかいってる人もいるけど、
歴代x86がスケーラビリティでRISC陣営より劣り続けている事実さ、
IA-64のスケーラビリティの高さを見る限り、
ISAに起因している要素が何かあるという可能性も否定できないのでは？

スケーラビリティの高さは、なにによって決まるのですか?

ごめんなさい。聞き方が悪かったです。

CPUの数を増やしたときに性能が伸びるようにするためには、何が必要なのですか?
具体的に、x86は何が悪くて、CPUの数を増やしたときに性能が伸びにくいのですか?

>>909
最初からそうやって具体的にデータを挙げてくれないと。
性能と言ったって何の性能かも分からないし。

その表のSPECint_rate2000では、上位のRISC陣はデュアルコアチップで
倍のコア乗せてるから成績が良いだけ。
実質的にXeonMPがRISC勢に負けている感じはしない。

Itanium2のFSBは128bit400MHz。
XeonMPのFSBは64bit400MHz。
FSB帯域が倍違う。
それとItanium2は大容量の高速オンチップキャッシュ乗せてるし。

>>909
「可能性は否定できない」ねぇ。
それで何か説明したつもりなの？

>>912
漏れにはx86はスケーラビリティが低いように見えるけど。
HPC分野でx86があまり使われないのはスケーラビリティが低いから
っていうのが一つの原因だと思うけどね。
あと、具体的にデータを提示できないのが残念だけど、
昔のスペックでもx86はスケーラビリティがRISCに対して悪かった。
ま、結局原因不明ってことでこのネタはいいや。

>>913
漏れは何も説明・解説する気はさらさらない。
何故x86はスケーラビリティが低いのか？
ISAとスケーラビリティの関連性はどの程度有るのか？
識者がこのスレにいたら説明して欲しかっただけだよ。

> HPC分野でx86があまり使われないのはスケーラビリティが低いから
> っていうのが一つの原因だと思うけどね。

う〜ん、SMPでの鯖アプリならともかくHPCでの並列化効率にゃ
内部の命令セットなんて関係ないのは間違いない。

> ま、結局原因不明ってことでこのネタはいいや。

何勝手に決め付けて一人で納得してるんだ？
なんか聞きかじった知識で偉そうに（←これ重大）理屈こねてる
だけのようにみえるが・・・・・・

>>916
別に素人だし聞きかじった知識しかないが、そんな偉そうにしてるつもりないけどなぁ。
ただ、ISAの出来とスケーラビリティの相関性について知りたかっただけなんだけど。

>909
基本的に x86 プロセッサは desktop PC 向けの設計だったから
というのが本質でそ。

AMD Hammer(Opteron)は設計当初からスケーラビリティの点を
大きく意識して設計してあるから RISC 系と比べても互角だし、
Intel Xeon ですらチップセット(などと呼べる代物ではないが)側を
頑張ればスパコンに使われているわけで。

>>917
だからどこからISAがスケーラビリティに悪影響を及ぼしているという電波を受けたんだよ？
わかんないならISAが関係しているとか言わなきゃいいのに。

そうそう。
「関係してない」というのを証明しろってのは悪魔の証明だからな。
そんなもん要求するな。と付け足しておく。

>>919->>920
もっとも簡単な例でいくと
レジスタが少ない
　　　　　↓
メモリアクセスが頻発
　　　　　↓
バストラフィックが増大してスケーラビリティが低下

というパターンが考えられると思いますが。

>「関係してない」というのを証明しろってのは悪魔の証明だからな。
全く関係ないと思っているのは今のところこのスレではあなただけでは？

付け足し
http://ascii24.com/news/i/tech/article/1999/05/27/602463-000.html
>注)EPIC：和訳は明示的並列命令コンピューティング技術。
>インテルが提唱する、スペキュレイティブ実行、条件タグ付き命令、
>明示的並列実行といった技術を組み合わせることで、より高い並列実行性
>やスケーラビリティを実現するというテクノロジー。

厳密なISAからは外れますが、EPICはスケーラビリティの高いアーキテクチャ
だとIntelは宣伝しているようですが。

と、この辺のISAの質とスケーラビリティの関連について語れる人の
レスを期待していたのですが、期待はずれだったのでこのネタやめようかと…。

>>921
キャッシュの存在は無視ですか？

>>921
x86プロセッサの汎用レジスタは本当に(物理的に)8個しかないと思ってるの？
レジスタリネーミングって言葉きいたことない？

そもそも内部でμOpに分解されて全然別のコードが走るんだからISAなんて関係ないと思うけどな。

>キャッシュの存在は無視ですか？
レジスタにないデータが全てキャッシュに全てヒットするわけないでしょ。

>x86プロセッサの汎用レジスタは本当に(物理的に)8個しかないと思ってるの？
何で物理レジスタやレジスタリネーミングの話がここででてくるのかが理解できません。
>>921で書いたのはあくまでも例であって特にx86意識した書き込みでもないし、
一貫してスケーラビリティとISAの関係の話をしているので、ここでレジスタリネーミングの効果
がどの程度有るのかなどの話題に興味はありません。

>μOpに分解されて全然別のコードが走るんだからISAなんて関係ないと思う
そうですか。

む。レジスタリネーミングは意味合いが違うか。この場合。

なんにせよいまどきのIA32プロセッサなんてIA32->内部RISC命令のトランスレータ
をかぶせたRISCプロセッサでしかないんで、ISAの優劣なんざもはや関係ないと思う
のですよ。

>>926
＞>μOpに分解されて全然別のコードが走るんだからISAなんて関係ないと思う
＞そうですか。
ISAは関係ないということで終了ですね。

なんか ゆんゆん してますねぇ (´д｀)

関係のないものの関係を語っている奴が、
他のものがどう関係するかについては >926 "興味がありません" だってさ…

ISAによってメモリモデルが違うって時点で関係ないわけないでしょｗ
もはやどうでもいいがｗ

>>922
> >注)EPIC：和訳は明示的並列命令コンピューティング技術。
> >インテルが提唱する、スペキュレイティブ実行、条件タグ付き命令、
> >明示的並列実行といった技術を組み合わせることで、より高い並列実行性
> >やスケーラビリティを実現するというテクノロジー。
> 厳密なISAからは外れますが、EPICはスケーラビリティの高いアーキテクチャ
> だとIntelは宣伝しているようですが。
元記事みてもよくわかんないけど、Intelは
・スペキュレイティブ実行
・条件タグ付き命令
・明示的並列実行
でスケーラビリティがあがるっていってるの？
並列実行性しかあがんなそうだけど。

>>903
そうか？互換性なんてつまらん部分をx86レベルに押し付ければいいから中身はなんでもあり
・クロック最優先（部分的に7Ghz超が家レベル・・・とんでもない時代になったもんだ！）の熱湯
・IPC優先の浜（というか製造技術勝負になったら淫にかないっこないから？）
・P6アーキテクチャーの正統後継者PenM
・内部VLIWのEfficeon

本家UltraSPARCにOutOfOrderがつかない（で不時通SPARC64Vに先越された）のは
互換性とるためにレジスタウインドウを捨てられないからだってこの板のどっかで見た

>>930
relaxedなメモリアクセス命令を増設

>>926
キャッシュにヒットしてもコヒーレンシの維持とかいろいろ必要だしね。
制御プロトコルを簡単にしてコストを減らす(レイテンシも減るかも)か、
スケーラビリティを大きくするかといったトレードオフもあるんじゃないかな。

レジスタ数の大小とキャッシュ外のメモリへのアクセス頻度は関係ないですよ。
本質的にはレジスタもキャッシュなんですから。

で、ID:y8U13TKuさんは知ったかぶりだと思うよ。
Webで公開されている、たった1つの文を根拠に色々推測するのは、よく知らない証拠。

とくに断りなく言う場合の広義のスケーラビリティというのは、
同一のアーキテクチャで小さいものから大きなものまでカバーできますよ、
というくらいの意味しかない。
「スケールアップ」「スケールアウト」という言葉を聞いたことない?

Itanium2のその話に関しては、
スループットが出る力強いプロセッサでハイエンドのアプリに対応できるよ、
というような意味でスケーラビリティがあると言ってると思う。「スケールアップ」だね。

もちろん、Itanium2には多数のCPUを並列にする機能もあるけどね。これは「スケールアウト」だね。

>Webで公開されている、たった1つの文を根拠に色々推測するのは、よく知らない証拠。
EPIC云々の文章は今日適当に検索して見つけただけです。
漏れはSPECベンチの歴代スコアの方から純粋にISAがスケーラビリティに
大きく影響しているのかなと妄想していたのです。
漏れの考えは的はずれだったということですね。

>>934
キャッシュヒットする場合、そのキャッシュラインが
他のプロセッサと共有されてない限り
コヒーレンシ維持の為に外部バスにアクセスすることはないと思うけど。
レジスタの代わりにメモリ(普通はスタック)に確保した変数は
他のプロセッサと共有しないから。

>>936
妄想が当たると何がいいことがあるの？

>>937
まあそうだけど、キャッシュラインに変数が1つしかないわけではないから。
コンパイラは載らないようにするんだろうけど。
実際キャッシュ制御の違いによる差ってどれくらいなのかな？

(あと、共有していなくてもストアするとステートが変わって、ディレクトリ
へに書きにいくアクセスがある。ディレクトリって無い奴もあるのかな？)

そういえばx86=x86-64(AMD64&互換EM64T)に自動脳内変換してスケーラビリティ話を>>930まで読んでたｗ
でもx86だけだと普通x86-32だよな（x86-64的言い方すれば）
そりゃ基本的に最大4GBを小細工してカバーじゃオーバーヘッドでスケーラビリティ低くなるのは当然だｗ




y8U13TKuたんって実は超級釣り師なんじゃ？

いや、ただの引きこもりだろう

正解ｗ

知ったかの集まるスレ

>940
みな釣りなの分かってて戯れてるだけなんだから
"超級"ってのはないっす

それはともかく、
論理レジスタは何個が最適なんだろう？

用途にもよるし、誰も知らない。

基本的には命令コード長とご相談。ってところじゃない？

おかげでインラインアセンブラが使いやすい
PPCじゃこうはいかない

もうすぐ次スレか？
うんこはどこいった？

>>948
演算ごとに使えるレジスタに制限があるｘ86のアセンブラが使いやすいとわ初耳す。
RISCのアセンブラわ、メモリからレジスタへのロード命令をいちいち記述しなければいけない分「手間」わ
かかるすけど、命令の直交性が良いすから記述わ楽だと思うす。固定長命令なので、逆アセンブルも
楽だし(笑)

その変な日本語を直せ

>>950
　>>948では無いけど、制限があることで逆に使用パターンとか
クセとかが固定されて使いやすい＆読みやすいと感じることはある。
PPCのアセンブラは知らないけど68ｋではレジスタをどう使おうかと
結構悩んだ。

>>952
管理教育の弊害がこんなところに。

>>952
68kはアドレスレジスタとデータレジスタがあるから使いづらい。
そしてアドレスレジスタは余り、データレジスタは足りなくなる。

x86は不思議な良さがある気がするんだが。慣れてるだけかね
プロテクトモードのアフォみたいな複雑さにはひたすら閉口するのみだが。

日本人って限定された環境で力を発揮するのが得意じゃん。
ヘタに自由度が高いとどうしていいのか分からなくなる人が
多いんじゃないかとオモタ。

俳句みたいなもん？

>>954
あ、やっぱり？そして効率的な使用法でまた悩むことに。

>>956
俺まさにそのタイプだな。

128個〜512個のレジスタを効率的にスケジューリングして
必要最小限のロードストアになるコードはどれほど大変なことやら。
r317とr28の和をr34に入れてr17と差分を取り．．．．

>>959
　　----------------------
　　128個〜512個のレジスタを効率的にスケジューリングして
　　----------------------
私の知る限り、主要なRISC ISAのレジスタ数わ、こんなもんす。脳内プログラマの方すか？
　・PowerPC, Alpha, MIPS, PA-RISC: 32(int)/32(fp)
　・SPARC: 136(int, ただし、一つのプロセスから見えるのわ32)/32(fp)

959は多分物理レジスタのスケジューリングまで考えているのだろう。

あとSPARCは1プロセス32じゃ無いよ。
それとレジスタウインドウの事を考えて132と言っているのだろうけど、
実装によって異なる。

512個もレジスタを扱えるようにしたら、命令コードのうち9bitx3=27bitも
オペランドに食われちゃうわけで。32bit命令長だと相当きついと思うがな。
というか無謀。

しかし64bit命令長というのもそれはそれで、コードデンシティが相当低く
なりそうだ。
＃まぁあるけどな。64bit命令長のプロセッサ。