Sun Microsystems 最大の岩望

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

Rockは出るのか!?

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

**名無しさん＠お腹いっぱい。** · 2009/07/31(金) 20:07:57

>>188
Niagara出たときSPECwebで取ってなかったか？

**名無しさん＠お腹いっぱい。** · 2009/07/31(金) 20:08:05

>>187
はて、最近の記事では、
ttp://pc.watch.impress.co.jp/docs/column/kaigai/20090724_304602.html
ノートPCで使われるCeleronよりもAtomのほうが利益率が高い。

**名無しさん＠お腹いっぱい。** · 2009/07/31(金) 20:08:48

>>188
あれ? なんでそこで住人論?

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

日立、富士通、三菱電機、沖電気はTRONチップのGMICROシリーズ出してたな
なつかしい

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

>>187
(ARMと比較して)消費電力と価格が高い現行のAtomでも組み込み向けに10億ドルのシェアを持っている
そしてこれからもどんどん微細化してコストも消費電力も下がる

**名無しさん＠お腹いっぱい。** · 2009/07/31(金) 20:20:34

>>195
TRONって、本当に癌だったよな。
もしTRONにリソースを浪費させられなければ・・・と思うと・・・ねぇ。

**名無しさん＠お腹いっぱい。** · 2009/07/31(金) 20:34:19

TRONの32bitマイクロプロセッサはNEC Vシリーズと並んでいいCISCだったよな
中途半端な680x0とは違う綺麗な命令セットで当時は使ってみたいと思ってた

OSのB-TRONもなかなか面白かったから米国のクソどもが茶々入れてなけりゃ
もうちょっと違った世の中になってたかもしれん

**名無しさん＠お腹いっぱい。** · 2009/07/31(金) 20:44:57

いよいよ腐ってきたな、このスレ

**名無しさん＠お腹いっぱい。** · 2009/07/31(金) 20:48:05

SPARCにしがみついたままの連中がいるからな

**名無しさん＠お腹いっぱい。** · 2009/07/31(金) 20:59:02

>>198
いや、TRONは絵に描いた餅だったってば。

坂村の言うことを真に受けて洗脳された人たちはヨイショしてたけど、
実際の開発をしていたメーカーの人たちはボロクソに叩いていたよ。

坂村は旗振り屋なのに、あたかも自分が設計したかのように吹聴して回るし、
しかも、その設計が一流あるいは新規性があるならともかく、二番煎じでダサい。

**名無しさん＠お腹いっぱい。** · 2009/07/31(金) 21:04:11

きな臭くなってまいりました

**名無しさん＠お腹いっぱい。** · 2009/07/31(金) 21:09:32

TRONの仕様を無償公開した、メーカーは自由に使うことができる
そんな恩着せがましいことを言ってたが、その仕様が酷いシロモノだった
見たことない人はググってみ
アメリカの外圧で潰されたとか以前に、WindowsやMacOSに対抗できる実力がないことがわかるから。

**名無しさん＠お腹いっぱい。** · 2009/07/31(金) 21:31:28

G-MICRO出た当時はDOSが幅きかせてた頃だよな？
なかなか出なかったOSはともかくCPUは悪かったのか？

**名無しさん＠お腹いっぱい。** · 2009/07/31(金) 22:37:52

RISC CPUに性能面で差をつけられてたからな
TRONチップは開発したメーカーですら採用しなかったようなCPU

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

そういえば、坂村氏が自画自賛していたTRONチップの命令セットは洗練されてたのか？

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

なわけないじゃん。

アトミックな文字列操作の途中に割り込みが入るのは良くない
なんて言うような人だぜ?

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

> アトミックな文字列操作の途中に割り込みが入るのは良くない
> なんて言うような人だぜ?

へー。アトミックな操作中に割り込みが入ることが許されるんだw

アトミックって言葉の定義がおかしくね？　おまえの頭。

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

普通の人
「アトミックな文字列操作」に呆れる

>>208の人
「アトミックな操作の途中に割り込みが入るのは良くない」のは当たり前だ、どこがオカシイの? と相手を罵倒する

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

文字列操作がアトミックである必要がないという話なんじゃないの?

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

V60とか懐かしいね

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

Linuxってバカなの？
http://journal.mycom.co.jp/news/2009/07/31/036/index.html

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

もしかしてTRONチップのストリング操作命令がアトミックだと信じてる
バカがいるのか？

**名無しさん＠お腹いっぱい。** · 2009/08/01(土) 13:27:03

>>208 = >>213
話をすり替えるな

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

俺はTRONチップの命令セットよりも680x0系の命令セットの方が好き

**名無しさん＠お腹いっぱい。** · 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で実現したクロックにさえ
追いつけていないが…