360のC＃　　vs　　PS3のAssembler　　

Wiiでよくね？

http://www.gfdata.de/archiv03-2007-gamefront/trustypack.jpg
74 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2007/03/18(日) 10:07:20 ID:7aYTLuWs0
店舗側が用意した仮パッケでOnlyじゃないと喜んでるGKﾜﾛﾀ
100 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2007/03/18(日) 11:11:22 ID:x13sn16W0
自分はカラーコピーしたものDVDケースに入れて展示してる（有る意味店で用意した）
店は見たこと有るけどね実際の所
　 　　　／　　 　 　＼
　　　／　 _ノ 　ヽ､_　 ＼
　 ／ oﾟ(（●）) (（●）)ﾟo ＼ 　ショパンのオンリーオン表記が消えちゃったお…
　 |　　　　 （__人__）'　　　　|
　 ＼　　 　　｀⌒´ 　 　 ／
　 　 　　　＿＿＿_
　 　　　／⌒　　⌒＼
　　　／（ ●） 　（●）＼
　 ／::::::⌒（__人__）⌒::::: ＼ 　　だから「店舗側が用意した仮パッケ」ってことにするお！
　 |　　　　　|r┬-|　　　　　|　　　カラーコピーしたものをDVDケースに入れて展示してる（有る意味店で用意した）
　 ＼ 　　 　 `ー'´ 　 　 ／　　　　店は見たことあるお！

言語よりも、アーキテクチャの問題だな。
PS3は設計思想がつぎはぎだらけでウンコッコ

Wiiで作るくらいならPS2で作るよ

C♯ねぇ……
悪い言語じゃないとは思うけど、ゲーム開発に使うのはどうなのよ？

Wiiでいいね

高級言語はコンパイラの質次第じゃ。
C++使いが一生懸命VB使いこき下ろすような
アホスレになっては困る。

>>5
ハード直叩きをさせない事で、後から720pの旧ソフトでも1080pに対応したりという
利点はあるが、どうなんだろうねぇ。
一応、C#の場合でもシェーダは使い放題でグラフィック周りは問題ないとの事だが。
まぁ、余計な事を考えずにゲームロジックに集中できるという利点はあるかもしれんが。

秋月電子のキットを買ってプログラム♪

>>5
わざわざC#なぞ使うわけがない
普通はC++

>>10
や、スレタイにC＃とか書いてあるからさ。

つーか、C++はC++でもManaged C++だったりしないだろうな。

C#しか知らんけど、アレ便利そうじゃん。
俺もXNAで一儲けをｒｙ

>>11
俺の書き方が悪かった、スマン
普通のゲーム会社の360開発ではnativeなC++しか使ってないと思うしC#ｲﾗﾈ
という個人的な意見

個人でゲーム作るんなら
ただのCで組みたいな。
C++やC♯だとメンドクサイ

Cって相当にめんどくさい言語だと思うがな。
使えるならC++の方がいい。

つーか今はどのゲーム機もC++でそ

PS3はアセンブリ
SCE推奨

>>15
アセンブラに比べたらCなんて随分楽だろ

>>15

ん？C++はCの拡張版だから、面倒くささなら、C++の方が単純に上だろうに。

面倒くさがり屋はプログロムもゲームも辞めたほうがいいな。

重かろうと何だろうと俺はJavaが好きだ。

Cが面倒くさいってどれだけ面倒くさがり屋なんだ…

ここにも少子化の要因が

>>19
何を言う。
C++だと簡単にできることがCだとできないから面倒なんじゃないか。
CでできることはC++でもできるしな。

>>24
Cでできないってのは間違いだな。
面倒なだけ。

このスレタイはマジなのか？
だったらPS3完全死亡じゃね？

>>25
うむ、だからC++の方が楽だと。

>>22
何を言う、めんどくさがり屋だからプログラマーなんてやっているのだ。

>>26
マジ
ネタじゃなくSCEが「コンパイラは遅いのでアセンブルしてください」
って言ってる

ttp://www.watch.impress.co.jp/game/docs/20070316/pe.htm

＞　また、SPUのプログラミングそのものについても、ソニー自体がもがき苦しんでいるのが伝わってくる。
＞本来はSPUは高級言語でプログラミングできることがウリだったはずなのだが、
＞ソニー自身が「Cコンパイラの出力コードは信用ならないのでSPUプログラミングはIntrinsicsネイティブ命令を使いましょう」と奨励し、
＞「Intrinsicsだとコンパイラの20倍高速です」と自ら言いきってしまっているのが、まさにその象徴だ。
＞SPUコンパイラにはソニー製とIBM製があり、Playstation SDKにはソニー製のものが使われているらしいが、IBM製のものが、どの程度のものなのか気になるところだ。

C#でも1080pレースが作れる箱○に対して
アセンブラでｶﾞﾘｶﾞﾘ書かないとまともなパフォーマンス出せないPS3ｱﾜﾚ

まあ、どういう糞言語であろうと
アセンブラでは到底適わんな。

うわ・・・
PGに死ねって言ってるようなもんじゃんかw
WEB系と携帯のソフトしか作った事無いんだが、今でもゲーム業界だと
アセンブラちょくちょく使ってるのかな・・・

>>31
細かいところでは使ってるだろうけど・・・
大部分は高級言語でしょ。

>>32
だよね。

中小のゲームメーカーは開発できないんじゃないかな・・・
エンジンやらライブラリ作るのでめっさ金かかりそうだ

NEO-GEOじゃねえんだからアセンブラはやばすだら

C++＆ｲﾝﾗｲﾝｱｾﾝﾌﾞﾗが最強

Intrinsicsがどんなもんなんかまだ明らかになってないんだよね。
アセンブラ説があるだけで。

マジレスすると、C#とアセンブラ以前に、360だとDirectXのAPIひとつ叩けば済むところを、
PS3だとレジスタ叩いて初期化して云々で100ステップくらいになる。
一応、sceホゲホゲのCライブラリで出来ん事もないが、なぜかPS2より遅くなったりする。

ゲーム開発の現場は知らないけど
それって1回同じ機能を自前で作っちゃえば後は必要時に呼び出すだけで済むことじゃん。

>>36
スクリプト言語だったりしてｗ

XNAでお遊びプログラミングならC#最高だーな
C# + DirectXはこれ以上の組み合わせはねーよってくらい便利で強力
売り物に使うのは無理だけどな

で、ナニ？PS3はSPU Intrinsicで書け？
おー頑張ってくれや



俺はこんな超低級言語まっぴらごめんだけどなｗｗｗｗｗ

>>38
デバッグは？
移植は？
後方互換は？

スクエアやクロムやコナミがどれだけ血を吐いてるか、
容易に想像できる。

>>38
普通、サード各社がそんなアホみたいな作業せんでいいように
ファーストがきちんと整備しておくもんだけどな

ハード牽引も他社任せなら、開発環境作りも他社任せって愉快すぎるぞ

「DirectXのAPIひとつ叩けば済むところ」　で言えば、
DirectXがやってることと全く同じ機能を書いてしまえば
移植性も互換性も確保出来るんじゃないの？
DirectXというライブラリを使う時点で急な仕様変更に対応できなきゃならんから
ラッピングするなりしておけばデバッグも最小限で済むじゃない。

>>42
何人か死んでるんじゃね？ｗ

>>44
どんだけ金かかるんだよ

>>44
それはファーストがやることだよ。

やってるのかしら？

>>44
それをSCEがやればサードは助かるんだろうけどね。

>>44
誰がそれをやるんだよ。

PS2で血反吐を吐いたPG

俺は知らね

　　　[ｽｸﾘﾌﾟﾄ] ― [ﾌﾟﾛｸﾞﾗﾑ] ― [社内ﾌﾚｰﾑﾜｰｸ]　― [ﾌｧｰｽﾄ提供のAPI（DirectX・OpenGL・ｶｽﾀﾑAPI等）]
　　　　　　　　　　　　　　　　 Ａ　　　　　　　　　 　 　　Ｂ
担当：ｽｸﾘﾌﾟﾀｰ　　ｹﾞｰﾑﾌﾟﾛｸﾞﾗﾏ　　　ﾌﾟﾛｸﾞﾗﾏ　

このB区間から先が用意されてなくて分厚いﾊｰﾄﾞ仕様書見ながら三角形一枚書くのに地獄を見たのがPS2と聞くけど
PS3も丸っきりそうなん？

好意的に考えると

Ｃ＃で作れるぐらい
ドライバやら環境やらが
充実してれば、
３６０は新しい道が開けるような気がする。

若手を育てるという意味では、
いいかもね。

＞DirectXがやってることと全く同じ機能を書いてしまえば

開発環境として、ファーストがサードに提供するような代物を
お前ら各自で勝手に作れ。とな？

ってかPS3ってOpenGLベースのAPIが用意されてるんじゃなかったの？

>>44
それを作るのに一体どのくらいの時間がかかると思ってんだ

DirectXだって最初に出たDirectX1.0からもう13年も経ってんだぞ

自前で作ってたらいつになってもできねえからSCEはOpenGLのライセンス買ったんだろうが
でも多分そのままじゃPPEで動くようにしか移植できないだろうから
SPE対応するように書き換えるだろうが果たして成功したのかな

OpenGL/ES2.0を移植する予定だったんだけど
全然仕様を満たせずに劣化OpenGL/ES2.0の独自規格PSGLになった
現場で使われてるのかは知らん

>>55
impressで記事にもなってたけどカプコンなんかは既にバリバリやってるね。
並列処理のためにSPUを使いこなすフレームワークの自製。

>>57
それがどれほどのものか興味深いな。
何せまだ姿を見せてないから。

アセンブラでプログラムする苦痛を知っているなら、PS3なんぞ関わりたくないと思うぞ普通。
今まで食べたパンの数を覚えることができるような人ぐらいしかプログラムできないぞ。

これは久多良木の罠だ。
アセンブラで超ムズプログラミング必須という印象を植え付け、
後で何らかの形で簡単にする。
例えそれが相対的に他のプラットホームより難しくても
こうすることによって、「めちゃくちゃ簡単になった」と印象付けることができる。

各社で勝手に作る羽目になるから、結局互換性がなくなるわな。

エンジニアはPS3で作りたいはずなんて、書き込みがあったが、
アセンブラで作れって言われたら、断固反対するよな。

業務命令で渋々やってんだろうけど。

ファーストからAPIが提供されてても互換性の保障なんてどこにも無いんだけどね。
稀な例だけど、APIを公開仕様通り使ってテストまで済んでるのに特定の型番で正常動作しなくなるとか。
APIもAPIでDirectXなんかはMSの都合で 「旧ﾊﾞｰｼﾞｮﾝのあれは全て廃止しました、当ﾊﾞｰｼﾞｮﾝからこうなります」
環境依存性の低さが売りのOpenGLでさえ各メーカーの拡張APIが乱立状態。
なので最近話題になるような売り物レベルの汎用エンジンまでいかなくてもソースレベルでのフレームワーク作りは必須。
海外メーカーのマルチ展開の早さは見習うべきものがあるかも知れない。

>>62
DirectXは互換性だけならOpenGLより遙かに上だろ。
そもそもDirectXの場合、旧バージョンの機能は、一切削除も変更もされない。

バージョンが上がると、例え同じ内容のAPIであってもAPI名や構造体等の
末尾番号が変わって、まったくの別物扱いだし。

は？
10になってから、9でのアセンブラシェーダ撤廃だし
HW:T&Lのときもそやった

DirectDrawなくなったやん('A`)

ぶっちゃけC++だろうがC#だろうが
Framework上で動かすのなら
同じ中間コードオブジェクトになるから関係ないんですけどね

ワロス

おいおい、また捏造だろｗ

PS3はASMだけじゃねえぜｗ
ていうか、元がPS3のグラフィック言語はCgだからCふうに書ける。
知らないバカもいるが、HLSLはCgがベースなんだぜ

勉強になったろ？

D3D10になって、一番困ったことは
指摘のあるようにASMシェーダができなくなったこと。
HLSLはCg分かる奴からすれば楽なんだが、やはりASMはそれ以上に楽だった。

それに、D3D9からの大きな大きな変更点、改悪点として
固定機能の廃止
があるんだなこれがｗ
互換性放棄ｗ
だから、固定機能をエミュレートするシェーダをHLSLで書かなければならないわけだ。

俺のようにASMシェーダとCgしかやれないバカは死活問題。
Cgだけじゃなく、ASMで最適化するのが俺の手法だから面倒。

ゲームプログラミング専門にやってるPGが言語にグダグダ言うわけないよ、仕事だし
開発の容易さこそ最優先すべき課題であって、C++、C#のレベルなら何で開発しようが同じ

C#やらVBやらは実際取っ付きやすいけど、初心者臭くて無能なイメージはもう遠い過去の話
状況にもよるけど、最近の基幹業務システムではJavaに並んで当たり前のように使われてる

ちゅうかSPEのネイティブインストラクションって


自分で書かなきゃならんものではなく


用意されてるもの


なんじゃんｗ

用意されてる物が使いものになるなら何ら問題ないのだが…

>>64
10では廃止だが、9までのAPIは上書きされずにそのまま残っているだろ。

DirectXをバージョンアップしても、既に動いているモノは更新なしに動き続けるのがDirectX。
でも改変（完全対応）するとなると、新APIに置き換えという一大作業が発生するのもDirectX。
これはマイナーチェンジでも別ライブラリの「追加」扱いだから、こうなる。

利用者からすると「最新ランタイム入れたら動かなくなった」というのが無くて嬉しいという代物。
開発者は大変だが。

えっ？PS3ってアセンブラなん？
大変だなぁ

アセンブラは無いわｗ

>>74
> DirectXをバージョンアップしても、既に動いているモノは更新なしに動き続けるのがDirectX。

それは単にバージョンアップしても旧版ライブラリを使ってビルドしていて、
PCに残されている旧版のDLLで動作してるだけでは？
新バージョンに完全対応させる時に、末尾の数字の書き換えだけでは対応できないケースが出る。
提供されるAPIは用意されているだけマシと思っておかないと。

>>77
まったくもって、その通り。
だが、旧版のDLLが上書きされないので、互換性の問題も出にくいのも事実。

アセンブラでゲーム作るなんて地獄だな。
アセンブラなんて組み込みとかOSとかドライバぐらいでしか既に使わなくってなくね。

N64が負けたのもアセンブラが使えなきゃどうにもならなかったからだよね。
そんな時代に逆戻り。アホか。

>>80
N64が開発しづらかった理由であって負けた理由とは言い切れない

DirectXのバージョンに関して言えば、74の書いてることが正しいわな．
COMのしくみを使ってバイナリの動作互換性は保たれてるから、
例えばDX9が入ってるマシンなら、DX6, 7, 8などの古いAPIを
使って書かれたプログラムも問題なく動作する．
（まあPCでの場合で、360とかのコンシューマは関係ないが）

このバイナリ互換性があるので、逆にMSはバージョンを上げるときに、
比較的ラディカルに仕様を変えてくる．これが開発者にとっては
「また変更かよ」と嫌がられるわけだ．
反面、新機能を貪欲に取り入れるので、バージョンが上がると
機能が大幅にアップするわけだが・・

あと固定機能パイプラインが廃止ってのは、影響はそれほど
ないと思うがな・・HLSLで一回書いてしまえばそれを使いまわしすれば
いいし、むしろ固定とプログラマブルの違いがなくなるので
シンプルになると思うがどうだろう

大手数社が血眼になってようやく使いこなせる･･･

そんなもんが許されるわけないだろ
誰が追従すんだよｗ

wiiはどうなんだろ

アセンブラたって680x0とか80386以降ならCISCの命令群から組みやすいと
思うけどな。昔は、高速化したトコはアセンブラ使うってのは常識だったし…。

で、PS3のアセンブラって組みやすいのかいな？

命令セットちらっと見てみたが、別に組みにくいということはなさそうだったな

最近のCPUはどれでもそうだろうが

>>86
けど、2種類あるんだぜ？

CELL はハードレベルで分岐予測や並べ替えしてくれないわけだから
決して組みやすいってことはないと思うけど。
通常ならCPUが勝手にやってくれることを
人間が必死こいて面倒見るなんて馬鹿げてる。

>>85
演算周りを組むのは昔と複雑さは大差ない。
ローカルのメモリ、作業空間が狭いから これを持ってきて
その間にこっちはこの計算して、結果をこいつに渡して
ここがボトルネックになってるから この計算は複数並列化できるように
モジュール切りして、、、、 と延々とシステム周りのチューニング設計を
面倒みないと性能出せない点が死ねる

>>87
2種類ってPPEとSPEのことか？

PPEのほうまでアセンブラ使う必要はねーだろ

>>90
>>28
＞「メインCPUのPPE（Power Processor Element）が遅過ぎる。
＞体感でPentium IIIの1GHz前後くらい。場合によってはPS2のEE（CPU）の方が速いと思うことすらある」
って書かれてるから、コンパイラの吐くコードが糞なんだろ
インラインで書いてる連中もいるんじゃないか？

いまどきアセンブラ推奨ってどういう環境だよ
環境整備なにもしてませーん！って言ってるのと同義だぞｗｗｗ

SCEはこういうことするから、またPS4で互換性の問題が出てくるんだろうな

>>92
PS１の時は色々環境揃えてきてたよ。でもかなり使い物にならんものだった。
PS1初期のゲームって、ネットやろうぜ！レベルのクソゲー大量に出てたでしょ？
遅くて使い物にならん！ってサードがハード直叩き始めて、中期以降は
どんどん同じハードのものと思えない水準に上がっていった。

その経験からなのか、PS２の時は仕様だけ公開して、どうぞご自由にと
投げっぱなしの環境渡すようになってたｗ

64もﾊｰﾄﾞを自由に叩ける仕様なんだよね。
GPU上で行う処理はﾏｲｸﾛｺｰﾄﾞを書いて自分なりにチューニングしてネ という投げっぷり

聞きかじりだけど、Cellの設計段階でIBMはSPUへのコード振り分けを全自動化した
コンパイラも込みでプレゼンしたのに、SCEはチップ設計に口を挟んだ上コンパイラは
ケチって買わなかったとか・・・

>>91
PPEって要するにPowerPCだろ？
さすがにコンパイラはこなれてると思うがな

それとな、SPEでアセンブラ使えってのは、
SCE製のSPEコンパイラが吐くコードがしょうもないってのもあるかもしれんが
コンパイルするとサイズがデカクなってLSに入らないから、が本当の理由じゃないかと思うのだが

アセンブラで書きゃそりゃコードサイズは小さくなるからな
場合によっては1/1000とか1/10000とか
劇的に小さくなるだろ

もちろんその分メンドクサさもメンテナンスのしにくさも上がるわけだが

>>97
いくらなんでも1/1000とか1/10000は無いだろ、常識で考えて
どんだけ糞コンパイラなんだよｗ

やることは一緒だからアセンブラで縮められるのは
から速度を犠牲にしてせいぜいオプティマイザが吐くバイナリより若干小さく出来る程度。

>>98
いやCを全く使わず、ゼンブアセンブラで書けば、って話なんだが

Cで書くとフツウはランタイムがリンクされるので、どんなに小さくても数10KBとかなっちゃったりするじゃん

そーなるともはやメガデモの世界だがなｗ

どっちもＣ++ですよ-。
アセンブラ＝魔法と勘違いしてる？>>1

Winなら/nodefaultlib（ライブラリ無視）で組めば何もしないプログラムは1KBになるな。
メガデモの4KB/64KB introでは常套手段。

プログラミングにも８対２の法則が適用できてな、
全体のコードの２割が、全体の８割のCPU/GPU負荷をかけているんだ
全体の８割は、開発性を優先した高級言語で十分なんだ




と適当なことを言ってみる

>>102

>>28

64KByteで音も絵も動いてるデモ（WinXP）

Farbrausch - fr-13
http://www.youtube.com/watch?v=xDKFQIoWUAs
Farbrausch - fr-08
http://www.youtube.com/watch?v=LkEsP9H2HGM

Conspiracy - Chaos Theory
http://www.youtube.com/watch?v=ciIeJk3COAg
Conspiracy - Beyond
http://www.youtube.com/watch?v=DjI8tJWkEBM

まあパッカーで圧縮されてんだけどそれでも凄い

>>125
やれって言われても無理。
早いのは判るよ、当たり前。

俺らに奴隷のように働けって？
勘弁してよｗｗｗ

やはり、性能ってやつは低容量で動かせる技術に応用しないとな。
BDなんていらない。

ttp://www.youtube.com/watch?v=KgNfqYf_C_Q
スクショ
ttp://kk.kema.at/files/gfx/full1.jpg
ttp://kk.kema.at/files/gfx/full2.jpg
ttp://kk.kema.at/files/gfx/full3.jpg
ttp://kk.kema.at/files/gfx/full4.jpg

こいつはexeが96KByteのFPSゲーム。まあこれもパッカー圧縮だけどそれでも凄すぎる

ごめん
>>125 改め　>>105

容量使うのはプリレンダムービーや波形データだろう

>>95
SSも自由にハード叩けるよ
SBLのマニュアルの後ろだかにメモリマップトＩＯの一覧が大公開されてたはず

4MBくらいのロムカートリッジでも
仮にハードスペックが高ければ>>109くらいのものを詰め込む事も可能？

スタック管理を自前でやる必要があるドリキャスも中々面倒というか取っつきにくかった。

>>109
展開したら280MB近くなってワラタｗ
どんなけ凄い圧縮なんだよｗ

お！このスレは良すれ。

Cellスレよりもはるかに役に立つ。

こんなもんを64KBだの96KBだのに押し込めるとなると
メモリが許す限りロムの容量が足りないというのは言い訳にもならないんだな

>>111
だけどさ、実写と変わらないCGを作れるって豪語してるのに
まさかプリレンダムービー使うわけないよなｗ

>>117
まぁ超絶的なテクニック使うからなぁ・・メガデモ作るヤツラって

ハッキシ言って、ついていけねえっす
あの世界には

まーメガデモ作るような連中ならPS3はハマルかもしれんな
あ、でもPS3向けLinux入れてもRSXは使えねえとか聞いたな

意味ナス・・

アセンブラならスーファミみたいなソフト作れば良いじゃん

帳票出力したいんでCOBOLで組みたい(´･ω･`)

それを、PS3なり箱○なりで組んでどうしようというのだ。

>97
こいつ、Ｃのソースファイルとアセのバイナリファイルの大きさを
比べてるんぢゃないか？

>>2
亀だが、ショパンはオンリーオンだよ
ソース
http://www.xbox.com/ja-JP/games/t/trustybell/

>>123
多分DLLとか連れてくるとか思ってるだけなんでは？

どっちにしろＣの中に書くから
全体でみれば、サイズはあんまり変わらないと思うよ

完全なアセンブラでもないから、余計話が面倒くさくなってるような気がするなぁ
しかしゲームとか作る人はホント大変だなぁ

SPU Intrinsicsって、ネイティブっちゃぁネイティブだけ
ど、「超豪華マクロアセンブラ」みたいな、C言語っぽい
言語だな。
IF〜ELSEやDO〜WHILEがマクロ化されてるアセンブラ
があるのだが、それっっぽい感じ。

ほとんどSPUの機械語と１対１に変換されるんだろう。

ただ、それだけに人間が最適化処理をせにゃならん
ワケで、ダメプログラマがプログラムしてたら意味が
無いね。

>>126
そりゃ理想論じゃね？
優秀なPGだってミスはする。
アセンブラなんて問題外だろ。こういうのはコンパイラあたりで対応してやらにゃ

ネイティブの意味がわからんな。C++は中間コード止まりなのか？

>128

C#はNETフレームワーク上で動くんじゃなかったっけ？
VisualStudioはVer6どまりなんで詳しくないのよ。

>>129
俺も基本はVC6使いで、時々VS2005使うくらいなんで
アレだが、C#やC++のManagedなバイナリ(つまり中間
コードな実行ファイル)は、.NETフレームワークが実行
時にターゲットマシンのネイティブコードに変換するん
だってさ。

JavaのJITだわな。で、たぶん変換した結果はキャッ
シュされて、２回目以降の実行では変換による速度
低下が無くなるんじゃね？

C++のは中間コードじゃないだろ。マネージじゃないじゃんけｗ

keep

マネージドなC++だろ
C++/CLI だっけ？

http://it.nikkei.co.jp/digital/news/index.aspx?n=MMITew000022032007

　特に困っているのがネットワークに関連する部分だ。Ｘｂｏｘ360ではユーザー間の
マッチングやランキングシステムなどの基本的なプログラムが、マイクロソフトによって
提供されているため非常に容易に開発できる。「しかし、ＰＳ３ではそういうプログラムが
ＳＣＥからまったく提供されていない。その部分をゼロから自分たちで開発しなければ
ならないため開発費を押し上げ、プロジェクトの大きな負担になっている」。


まさか、ネットワーク部分までアセンブラではあるまいな。

> ソニー自身が「Cコンパイラの出力コードは信用ならないので
> SPUプログラミングはIntrinsicsネイティブ命令を使いましょう」と奨励し、
> 「Intrinsicsだとコンパイラの20倍高速です」と自ら言いきってしまっている
SONY純正のEdgeですらこの始末だ。

>>134
TCP/IPを各社自分で実装して下さい　とか…

>>136
実際、IPのプロトコルスタックとかどこからもってくるんだろう。
PSXがNetBSD入れてたから、NetBSDからなのかな？