Sun Microsystems 最大の岩望

**名無しさん＠お腹いっぱい。** · 2009/07/10(金) 19:13:24

Rockは出るのか!?

【前スレ】
Sun Microsystems 最期の落日
http://pc12.2ch.net/test/read.cgi/unix/1244286002/

**名無しさん＠お腹いっぱい。** · 2009/08/01(土) 15:42:58

いまさら墓を暴いて死体に鞭打ってもなぁ。

**名無しさん＠お腹いっぱい。** · 2009/08/01(土) 20:25:50

アセンブリ言語で書くならVシリーズがずっと良さそうに見える
68kとは違って本当の汎用レジスタだし本数多いし

性能はどうだったのか知らんけど

**名無しさん＠お腹いっぱい。** · 2009/08/01(土) 21:22:35

レジスタの本数が多いと、その割り当ての管理が面倒なんだよ。

**名無しさん＠お腹いっぱい。** · 2009/08/01(土) 21:53:16

だからといってレジスタウインドウは？

**名無しさん＠お腹いっぱい。** · 2009/08/01(土) 21:56:24

レジスタが多いほうが楽しいと思ったんだよ！

**名無しさん＠お腹いっぱい。** · 2009/08/01(土) 22:44:29

SPARCもレジスタの数を増やせるアーキだったらよかったのにね
（レジスタウィンドウ数じゃなくて・・）

**名無しさん＠お腹いっぱい。** · 2009/08/01(土) 23:52:12

レジスタの割り当て管理が大変・・・？

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 11:28:29

アセンブラで書いていた時代の話、今の人には、わからんだろう。
RISCとCISCでは、レジスタと言っても、それは別物だったのだし。

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 11:47:28

多すぎるなら必要数だけ割り当てておけばいい話
そんなことを大変だとか意味不明

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 12:00:06

>>224は知らないなら黙ってれば?

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 12:18:50

知っているなら大変な点を説明してみれば？

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 12:28:04

聞く気がない人に説明してもなぁ
ていうか
経験がない人には説明しても無駄

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 12:34:23

根拠が曖昧だから説得力のある説明ができないと？

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 13:00:25

「めんどくさくなる」この一言で説明おわりなんだが、>>228には理解不能だろ?

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 13:57:18

うまく説明できないということですね、わかります

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 14:17:49

そういうものなんだよ、わかれよ、とか
説明したってわかんねーよと言い張ってごまかす人を思い出した

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 16:51:12

chaitin graph-coloring register allocator 位は学校でならなかった？

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 16:54:14

手間が増える。
なぜか、レジスタが多いから。

門外漢には意味不明だが、アセンブラでコーディングしている人には良くわかる。

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 17:07:19

x86 の欠陥はレジスタ数が決定的に足りないところw

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 17:10:12

その分高速だけどね

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 17:10:42

C言語で言うならば、レジスタというのはグローバル変数のようなものなの。
C言語でauto変数を使わずに、g0～g31という名前のグローバル変数を、
うまくバッティングしないように人間が「管理」して使いまわす・・・考えただけでゾッとするでしょ。

レジスタが少なければ、レジスタとメモリあるいはスタック間でのやりとりの手間は増えるが、
しかし、スタックはグローバルじゃないし、メモリは複数の用途に使いまわすようなことは
(よほどメモリに窮する場合でなければ)しない。

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 17:15:02

レジスタが豊富→レジスタの内容をメモリに退避する頻度が低くて高速、しかし、動作クロックは遅い
レジスタが少ない→レジスタの内容をメモリに退避する頻度が高くて低速、しかし、動作クロックは高い

一長一短だね

たとえば128本のレジスタと演算器との接続、レジスタからのロード命令が欲しくなるくらい、通るゲートが重そう。
かといって、汎用レジスタではなく演算器の付属物なのは、勘弁してほしいが。

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 17:17:17

その辺は２０年以上前にグラフ理論をベースに技術は確立されてる。職人芸を否定はしないが、
新しい（そんなに新しくもないが）技術を学んでいかす事も大切。

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 17:20:36

RISC のクロックが伸び悩んでたのはスーパースカラのための命令の依存性のチェックに
手間取るためで、その辺割り切るとクロックは CISC よりあげやすい。Alpha しかり。
Power は 4, 5GHz で x86 より高クロックだと思うが。

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 17:22:20

>>238
昔話をしているんで。

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 19:50:48

>>236
g0～g7にしとけよ

あとその例だとレジスタウィンドウ万歳じゃねーの？
今はそういう流れじゃないよ、残念ながら

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 20:08:24

そのときはそう思ってたんだよ！

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 20:21:51

>>241
んー、SPARCのレジスタ・ウィンドウよりはIA-64のレジスタ・スタックだな。

まぁ、レジスタ・ウィンドウは必要ないっていうのは、かなり早い時期に実証されてる。
にもかかわらず、IA-64がレジスタ・ウィンドウの発展形を実装したのは、どういうことなんだろうね。

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 20:24:40

レジスタ本数の少ないx86では、スタック操作を高速に行う必要があってさ。
その延長線上で考えると、スタックの先頭をレジスタに割りつけてしまえ、ってなるのさ。

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 21:01:14

今夜の官僚たちの夏は「電算機」話だよｗ

**名無しさん＠お腹いっぱい。** · 2009/08/02(日) 21:09:18

テレビドラマで勉強しちゃいかんよ。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 10:19:24

>>243
> まぁ、レジスタ・ウィンドウは必要ないっていうのは、かなり早い時期に実証されてる。

実証されてねーよ。実例示してみろ。
レジスタウィンドウが不利な状況があり得る、ということに過ぎん。
状況は時代の変遷でコロコロ変わる。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 11:22:15

>>247
MIPS

MIPSはレジスタウィンドウを持たないが、しかし、レジスタウィンドウを持つプロセッサよりも速かった。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 11:29:48

>>248
...でさ、その速ぁ～い MIPSが出た後で、レジスタウィンドウを持つプロセッサーが
出てないのか?
オマエ真性だなwwww

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 11:31:13

MIPS MIPS言ってるバカは、MIPSをおとしめるためにやってるんだろうな。
技術的な話なんか一切ないしな。セコいやつだな。恥しくないんかね、人として。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 11:32:47

>>249
それは、SPARCにバイナリ互換を切れと言ってるのか?

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 11:33:38

>>250
はいはい、ファビョらない、ファビョらない。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 11:34:20

>>249
レジスタウィンドウを持つプロセッサーで最新なのは・・・痛ニウムだな。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 11:40:56

現存でレジスタウィンドウを持つもの
SPARC
IA64

持たないもの
ARM
x86

レジスタウィンドウを持たないほうが主流だね。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 11:42:58

SPARCやi960のレジスタウィンドウには欠点があり、am29kはそれを解決していた。
しかしSPARCのレジスタウィンドウは、am29kのようなものに改善されなかった。
なぜか。バイナリ互換が損なわれるから。

SPARCのアーキテクチャがイマイチだっていうのは、もう明らかなんだよ。
でも、バイナリ互換のために、使い続けているんだよ。
それはx86も一緒だな。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 12:15:32

なんの証左にもなっとらん。MIPS使うやつって、アホやねんな。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 12:18:16

>>255
MIPSの後で Alpha出たよな? で、その技術構成要素の差は全て「劣悪」て
ことになるのかよ。幼稚園児かおまえは。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 12:25:30

レジスタウィンドウの話は繰り返し繰り返し出てるが、具体的な問題点は
一度も明示されたことはない。
今回のは特に、話にならん。
ない、ってことだな、要するに。
「クロック上げにくい」だの、「使い切った時のペナルティ」だの、アホ話ばっかり。
そんなもん初期の設計時点からわかりきったことで、トレードオフ検討した上で
メリットありと判断してるから盛り込んである。

おいアホ、少しはまともな理由付けをしてみろ。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 12:36:35

>>258
ねえねえ、>>254が見えてないの?

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 12:38:54

>>256
>>257
アホだの幼稚園児だのとレッテル貼りしなきゃならんほど、ぐうの音もでないのか。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 12:40:56

>>257
意味不明。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 12:43:21

>>258
> 「クロック上げにくい」だの、「使い切った時のペナルティ」だの、アホ話ばっかり。

あんたが認めたくなくてアホ話と言ってるだけで、それが具体的な問題点だよ。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 13:14:20

こういう FUDのたぐいって、やればやるほど自分が支持するものの評価が
下がって行くんだけど、わかんないのかね?
どうせ「おつむよわい」ってここでさんざん言われてるやつだと思うけど。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 13:20:12

>>262
それは技術の一側面を表してるだけで、問題点の実証でもなんでもない。
第一、それを上回る手続き呼出しの高速化というメリットがある。

ほかに何もあげられないんだな、問題点。みじめなこった。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 13:34:25

>>264
現実に、SPARCがベンチマークで遅いのは、どう説明するの? 実証ではないと?

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 13:35:51

エンタープr

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 13:36:41

>>265
...おまえがバカだということばかりが、実証されまくり。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 13:48:17

昔ならともかく今のソフトウェアはプロシージャコールのネストが深い
8レベル程度では頻繁にトラップが発生する
トラップハンドラ自体は短いのだが、その移行のコストが馬鹿にならん
かといってレジスタを増やすわけにもいかない
レジスタウィンドウの行き詰まりである

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 14:20:12

>>268
あのー.. レジスタウィンドウだとウィンドウ数は実装で好きなように
増減できるんだけど。手続きからの見かけ上のレジスター増やすんじゃなくて。
で、ウィンドウ数増やすのがモロに対策なんだけど。

> レジスタウィンドウの行き詰まりである

何も行き詰まらないんだけど。
そもそも、「8レベル程度では」って、v7とかの頃の話?

＃レベル低～。本気か?

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 14:27:22

もうひとつ言っておくと、短に呼出しのネストが深いだけなのが問題じゃなくて、
ウィンドウ数超える深さの行き来が頻繁に起こる場合メリットが相殺されるので
あって、深い段階に行ってもその時のウィンドウ数の範囲内で留まるのであれば
高速化の効果を十分に享受できる。

短い手続き呼出しが瀕出するプログラムにおいても、一概に不利とは言えない。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 19:11:54

>>270
ウィンドウレジスタがうまく働く場合はたしかにそうなんだけど
平坦にたくさんレジスタ使えるほうがやりやすいよね、
てのがその後の方向性かと

むかしの貧弱なハードでは資源節約のため
細かい関数コールが多かったんだけどね…

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 19:35:36

>>271
> 平坦にたくさんレジスタ使えるほうがやりやすいよね、

ほう、多段にネストした手続きに多数のレジスタを効率良く割り振る手法は、
例えばどんな方法?

> てのがその後の方向性かと

そんなことないと思うね。Itaniumは?
むしろ舞い戻ってきつつあるのがトレンド。>247に書いたとおり、
どういう手法が有利かは状況によって変わっていく。

> むかしの貧弱なハードでは資源節約のため
> 細かい関数コールが多かったんだけどね…

またそんな適当なことを。
オブジェクト指向言語が普及して手続き呼出しのネスト具合は深くなる傾向だろ。
昔は資源節約で細かい関数コールだぁ? ウソこけ。C言語でそんな配慮して
書いてたなんていう事実はない。

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 22:43:45

突っ込んでほしいのか

Itaniumがトレンドって、どこのトレンドだよ！

多段にネストした手続きって、ウィンドウレジスタ有利前提かよ！！

つか、お前ディスクもメモリも少ない時代にプログラム作ったことないだろ！！！

**名無しさん＠お腹いっぱい。** · 2009/08/03(月) 22:49:20

そんな時代に生まれなくって良かったと
心からそう思う今日このごろです

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 00:00:13

今はビットフィールドなんてほとんど使わなくなったしな。
本当にいい時代になった。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 00:12:23

レジスタウィンドウだからOoO実装しにくいの？
それともSunの実装が悪いの？

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 08:24:56

SPARC64はOoOだよ

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 08:40:48

富士通の実装にはあって、Sunの実装にはない理由はなんでしょう？

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 09:00:40

>>273
> 多段にネストした手続きって、ウィンドウレジスタ有利前提かよ！！

なるほど。手続きを多段にネストさせないわけだな? そいつはすごい。

...ところで、MIPSの取ってる手法をご披露いただけるかと思ったんだが、
違うんだなww 知らないわけ?プ

> つか、お前ディスクもメモリも少ない時代にプログラム作ったことないだろ！！！

わはははははははははは。アセンブラで? 商用 RISC以降で? 知識ないんだねw

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 09:06:27

>>273
> Itaniumがトレンドって、どこのトレンドだよ！

Itanium以降で新しい ISAって、あんまりないと思うけど。
SHくらいじゃない? あとはマイナーなやつしかないでしょ。

そんなにレジスタウィンドウが問題なら、レジスタウィンドウなくした
ISAが新規提案されて意味があるだろうしね。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 09:22:03

>>275
ジャンルによるよね。OSやネットワークプログラミングだと使いまくりだよ。今でも。
ふつーのアプリだと確かに皆無。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 10:14:52

>>280
SH1が 1992年、SH3でも 1995年出荷。
Itaniumは 1994年共同開発を発表、詳細の発表が 1999年だから
SHの方が古いね。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 11:01:53

ちなみに、i960は非常に優秀で売行きも堅調だったが、
DECから StrongARMを入手したことで部隊を PenProに移し、打ち切られる。
Am29kも優秀なアーキで多数出荷されており、後継にスーパースカラーや OoOを
計画されていたが、K5を開発（中身は結構 Am29k）するために打ち切り。

レジスタウィンドウの CPUで自滅したのは正味 Itaだけ。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 11:14:11

米Appleは8月3日（米国時間）、
米GoogleのCEO、Eric Schmidt氏が自社の取締役を辞任すると発表した。
Googleの事業領域拡大でAppleとの競合関係が強まっているためという。
Schmidt氏は2006年8月からAppleの取締役を務めていた。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 11:52:19

>>272
>　そんなことないと思うね。Itaniumは?

普段はItaniumを貶しておいて、こういうときだけ持ち出すのは卑怯だな。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 12:04:47

>>269
>　レジスタウィンドウだとウィンドウ数は実装で好きなように増減できる
>　ウィンドウ数増やすのがモロに対策なんだけど。

SPARCの名前のスケーラブルというのは、まさにそれなんだが、
ウィンドウ数を増やすのは性能を上げるためではなく、性能低下を防ぐため。
ソフトウェアに合ったウィンドウ数が「必要」なのであって、誇るポイントじゃない。

> そもそも、「8レベル程度では」って、v7とかの頃の話?

いま13レベルだっけ? どんどんレジスタを増やさないといけないね。

128本もレジスタがあっても、そのうち頻繁に使われるのは32本だけ。
しかも、用途が限られていて、自由に使えるわけじゃない。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 12:09:57

>>272
> ほう、多段にネストした手続きに多数のレジスタを効率良く割り振る手法は、例えばどんな方法?

具体的な手法を知りたければ、しかるべき論文に当たるべきだろう。
俺はIEEEの会員じゃないんで、当れない。

で、結論だけは周知なわけで、
MIPSは、そんなに多数のレジスタは必要ない、そこそこの数のレジスタを使いませば良いという話。
同時期のSPARCよりもMIPSのほうがレジスタの数が少ないのは、そういうこと。

> Itaniumは?

あれはレジスタウィンドウというよりはスタックのレベル0キャッシュのようなものだよ。
それを操作する命令は、スタック操作そのものだよ。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 12:11:40

>>277
SPARC64のOOO実行は、何か無理をしているって話をどこかで読んだ。

そもそも、RISCにOOOは邪道だ。
1命令を1クロックで実行するのだから、コンパイラが上手に命令を並べれば、OOOは必要ない。
それに、OOOはトランジスタと電力を浪費するので、マルチコア時代には不適切な技術だろう。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 12:16:19

>>283
> ちなみに、i960は非常に優秀で売行きも堅調だったが、

嘘を付くな。

i960は本来の用途がポシャって、しかたなくI/Oプロセッサとして再利用されたのよ。
メインプロセッサとしてi960が積まれたシステムなんて、ないに等しい。

Am29kが優れていたのは、その通り。x86のために打ち切られたのも、その通り。
そのAm29kよりも劣っていたSPARCが現在まで残っているのは、Sunが固執したからだね。

ていうかさー、ここSunスレなんだよ。i960とかAm29k、少し前にはARMの優秀さを主張していたが、
それらが優秀だとしても、SPARCが優秀だってことにはならんのですよ。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 12:24:30

ttp://slashdot.jp/comments.pl?sid=78200&cid=271537
レジスタウィンドウとOOOは排他ではないが、しかし、実装が難しい
SunはOOOによる性能向上よりも、クロックを上げることを選択 (OOOはクロックが下がるか、上げにくくなる)
レジスタウィンドウとCMTも排他ではないが、しかし、実装が難しくクロックを上げられない

ってことらしい。
事実、Niagaraシリーズはクロックが低いよね。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 12:30:13

SPARC64 VIはレジスタ128本ではなく156本×2セット
で、デカいです

ttp://journal.mycom.co.jp/articles/2006/12/11/sparc64/index.html
andoさんいわく、
> 富士通のSPARC64 V/VIは、
> IntelのCoreアーキテクチャのプロセサと、概略、同程度の複雑さのプロセサである。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 12:56:16

>>290

「クロックを上げることを選択」したくせに、富士通がSPARC64で実現したクロックにさえ
追いつけていないが…

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 13:19:28

>>292
それはSunがダメダメだから。

最先端のプロセッサは、その製造を他社に委託してちゃ、クロックは上げられんのですよ。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 13:21:25

>>285
はぁ? 普段けなしてると例に持ち出しちゃいかんのか? 却下。バカ?

>>286
はぁ... めんどくさ。仕様上は 32セットまでいけるわな。

> しかも、用途が限られていて、自由に使えるわけじゃない。

意味不明だな。レジスタ足りないの?

>>287
> 具体的な手法を知りたければ、しかるべき論文に当たるべきだろう。
> 俺はIEEEの会員じゃないんで、当れない。

あははははははははっははははははははははははははははははははははははははははははははははははははははははははははは

IEEEの会員? ひーーww なにそれー??ww IEEEが元締めで決めてんのかー初耳ー

> で、結論だけは周知なわけで、

とんでもない押しつけ論だな。そういうの「結論ありき」つって常識ある人からは
気嫌いされるんだけど、知らないの?

>>289
いや。ウソなんかつかん。Intel上層が取り合わなかっただけ。
i960はきわめて優秀だった。典型的な戦略ミス。

> それらが優秀だとしても、SPARCが優秀だってことにはならんのですよ。

レジスタウィンドウは優れた技術。今そういう話してんだぞ? 文脈わかってるか?

アホ過ぎて話にならんわ。最初から勉強してこいや。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 13:28:53

>>290
そうだよ。性能上のトレードオフでその都度選択してるだけ。
レジスタウィンドウのメリットを取れば共存の難しい手法を見送る、
別になんの変わったこともない。
他の手法のメリットを取って、レジスタウィンドウの実装にシワよせが来たところで、
わかってやるんならそれもまたいいだろうし。

最初の UltraSPARCは SuperSPARC IIまでの反省をいろいろ盛り込んで
設計されたが、コアのシンプルさを損なうものはできるだけ避けている。

レジスタウィンドウを悪者にしたくてしょうがないバカが 1名いるが、
とてもそんなことを理解できるレベルではない、ということがここまでで
はっきりした。
あまりにバカ話でレベル低すぎるのでもう相手はしない。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 14:29:54

> あまりにバカ話でレベル低すぎるのでもう相手はしない。

約束を守れよ

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 14:31:51

>>294
> はぁ? 普段けなしてると例に持ち出しちゃいかんのか? 却下。バカ?

SPARC > Itanium > SPARC
ほら、何かオカシイだろ。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 14:44:26

>>294
> はぁ... めんどくさ。仕様上は 32セットまでいけるわな。

32セットだとレジスタ何本だ? 280本か? 多いな、とてつもなく多いな。

> 意味不明だな。レジスタ足りないの?

その前の行の
> 128本もレジスタがあっても、そのうち頻繁に使われるのは32本だけ。
ってのがあるんだから、レジスタが無駄に余るって話をしてることくらい、わかれよ。

1回のプロシージャコールで、入力8本出力8本ってのは、多すぎるんだよ。
それに、何でもかんでもレジスタ変数にできるわけじゃないしな。

> IEEEの会員? ひーーww なにそれー??ww IEEEが元締めで決めてんのかー初耳ー

その手の論文の投稿先は、たいていIEEEなんだよ。

> いや。ウソなんかつかん。Intel上層が取り合わなかっただけ。
> i960はきわめて優秀だった。典型的な戦略ミス。

売れ行きが堅調だってのが嘘なんだよ。
敗者復活戦のI/Oプロセッサ転向前に、いったいどれだけ売れたというのだ?

i860のunixワークステーションはクボタの製品を見たことがあるが、
i960のunixワークステーションなんて見たことないぞ。

> レジスタウィンドウは優れた技術。今そういう話してんだぞ? 文脈わかってるか?

Am29kのようなレジスタウィンドウが優れているのであって、SPARCのそれはイマイチだって話だ。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 15:46:39

>>298
わかった。じゃ、あとは IEEEに出しとくから、IEEEからもらって読んでくれ。

...ぷ .kkkkkkkひーーひーーwwwwwwwww

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 16:13:23

IEEEって、会長志村けん?

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 16:53:29

ACM じゃだめかよｗ

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 16:54:55

いえええ

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 18:41:02

IEEEれカス

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 21:54:41

自社で半導体工場を持たないメーカーがサーバー向けCPUを開発するのは無理
成功してるメーカーはもう残ってない
SUNはSPARCの開発をやめて富士通に一任すべきだよな

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 22:11:39

富士通も半導体工場持つの止めるよ

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 23:02:06

「ムーアの法則の前に投資規模が..」云々いうやつは、Intelでさえ軽く
耐えられないから、何も心配ないよ。
だいいち、サーバー向け CPU作ってる会社が既に数社しかないのに、
以前の方法論当てはめてみたって意味なんかないし。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 23:09:56

>>299
査読のあるやつに投稿しろな。
査読が通ったら知らせてくれや。

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 23:37:22

IEEEって、論争になった時、卑怯な手に使えるんだね。知らんかった。これは便利

**名無しさん＠お腹いっぱい。** · 2009/08/04(火) 23:48:31

いいかげん見苦しいぞ

**名無しさん＠お腹いっぱい。** · 2009/08/05(水) 03:01:21

次はセグメント方式ではじまりそうだ。

**名無しさん＠お腹いっぱい。** · 2009/08/05(水) 03:37:25

>>310
お前が見苦しいって言われてるの、わかってないでしょ

**名無しさん＠お腹いっぱい。** · 2009/08/05(水) 08:52:43

>>309
理由は IEEEから入手してくれや。

**名無しさん＠お腹いっぱい。** · 2009/08/05(水) 09:00:26

>>310
セグメントは IEEEで禁止されている。作った CPUは回収命令w

**名無しさん＠お腹いっぱい。** · 2009/08/05(水) 12:59:35

>>312
>>313
見苦しい連投やめなよ
キチガイだと思われるぞ

**名無しさん＠お腹いっぱい。** · 2009/08/05(水) 13:25:50

キチガイって、すぐ IEEE言うやつだろ?w