トップページ⇒tech
1001コメント278KB

【IA64】64bitプログラミング総合ｽﾚ【x86-64】2

■ このスレッドは過去ログ倉庫に格納されています
0001 ◆TimpoiKAMI 2005/07/21(木) 14:26:37
ようやく64ビットを気軽に試せるようになったので、
せっかくだから
ナニヤラ目新しいことして遊ぼう藻前裸。

64ビット環境プログラミング全般の話題おkだけど、シェア事情により
x86-64(AMD64, EM64T)の話題が圧倒的に多くなる気配。
しかし、プラットフォーム・OS・言語問わずに逝こう。

前スレ
http://pc8.2ch.net/test/read.cgi/tech/1109121175/l50
0153デフォルトの名無しさん2005/07/25(月) 10:26:19
P4の命令ﾚｲﾃﾝｼ/ｽﾙｰﾌﾟｯﾄ表をみると、MMX→SSE2化で効果ありそうだけど
逆にAthlon64だと効果ないっぽい。

2x2の行列の掛け算を148の(2)(3)でSSE2化しても、Opteronでは
まったく速くならないし遅くもならなかった。
まぁ、精度の関係でもうMMXは使っていないけどねー
0154デフォルトの名無しさん2005/07/25(月) 10:54:34
>>153
SSE以降は、MMXでは精度が足りないようなところを補完する形で
使うとプログラムの全体的なアップにつながるね
0155デフォルトの名無しさん2005/07/25(月) 13:54:43
Mathematica」がマルチコア対応、64bit環境をフルサポート
http://pcweb.mycom.co.jp/news/2005/07/25/100.html

64bit対応メリットは何かな？
0156デフォルトの名無しさん2005/07/25(月) 14:25:23
>>155
大量のメモリが使える。つまり馬鹿でかい配列が使える。
0157デフォルトの名無しさん2005/07/25(月) 14:36:39
マセマチ子さんは超巨大データを扱う需要はありそうだね。
0158デフォルトの名無しさん2005/07/25(月) 17:22:11
>>156
64bitじゃないと確保できないサイズの配列って、どんな演算に使うの？
0159デフォルトの名無しさん2005/07/25(月) 17:25:54
>>158
シミュレーション等ではいくらでも用途はある。
0160デフォルトの名無しさん2005/07/25(月) 17:40:29
天気予報とか？
0161デフォルトの名無しさん2005/07/25(月) 17:57:26
32bitでの、XMMがMMXより速い点。
・XMMはレジスタが広いので、同じ8個でもアンロールした効果が得られる。
・Pentium4ではL1からのLoadがMMXの倍の帯域。
・Pentium4ではMMXが弱い（レイテンシがXMMと同じ）ため、相対的に速い。

遅い点。
・使ってみるとわかるが、movdquがなぜかmovq*2より遅い。
・単純にレジスタが大きいから小回りが効かない。
・特定ユニットを使う命令が連続すると、命令が大きいため逆に並列実行を妨げる。
・Pen4以外では、内部でMMX*2に分解するのでデコーダの負担が少しある。
・psadbwは命令自体がMMX*2仕様なのでXMMで使うと余計な演算が必要になる。
0162デフォルトの名無しさん2005/07/25(月) 18:00:05
>>151
1.5倍ということはPentium4だね（違ったら教えて）。
依存チェーンがきつい場合にSSE2は強いかも。

>>155
64bit*64bit=128bitの整数乗算ができるのが大きいと思う。
0163デフォルトの名無しさん2005/07/25(月) 18:13:39
汎用の64bitレジスタより、mmの方が速い様な希ガス。
＠Athlon64 cgｺｱ
0164デフォルトの名無しさん2005/07/25(月) 18:22:30
AthlonってMMXは汎用レジスタと違う実行ユニットなの？
0165デフォルトの名無しさん2005/07/25(月) 19:30:23
>>163
それより古いC0コアのOpteronでは、mm(64bit)も汎用も変わんないよ。

x64のmasmってmmx命令にも対応しているのねｗ
0166デフォルトの名無しさん2005/07/25(月) 19:44:40
>>165
そのmasm、ちょっと萌えるな。
0167デフォルトの名無しさん2005/07/25(月) 20:04:46
>>165
うちのml64.exeは使えないぞ
↓というエラーが出る。

ml64.test.asm(5) : error A2222: x87 and MMX instructions disallowed; legacy FP state
not saved in Win64
0168デフォルトの名無しさん2005/07/25(月) 20:19:06
psdkの人は残念。
vs2005 beta2のml64ならMMX対応。
0169デフォルトの名無しさん2005/07/25(月) 21:06:51
MMレジスタを32本にしてF32vec2型とF64vec1型サポート汁
0170デフォルトの名無しさん2005/07/25(月) 21:13:14
IA64なら汎用レジスタは128本だぞ
0171デフォルトの名無しさん2005/07/25(月) 21:15:35
過去の資産をおろそかにするCPUは市場では歓迎されない
01721462005/07/25(月) 21:42:48
>>152
SIMD化は簡単でした。
分岐がなく、パックしてるデータ間は独立しているし、似たような演算ばかりなので。

MD5くらいだと、コンパイラのスケジューリングでも十分です。
他の人がアセンブラで実装したのと比べても遜色ないどころか、速いと思います。
アセンブラで書いてたらやってられないようなコードも楽勝なんで。

※ただし、コンパイルに異様に時間がかかりますが・・・。

>>162
Pentium4です。

ソースコードは非公開ですが、
http://www.geocities.jp/ny2scan/nyTripper.html
のnyTripperMD5bench10.zipで比較できます。
SSE2とMMXと整数レジスタの混合比を変えて総当たりして、
そのCPUでもっとも速い組み合わせを見つけ出します。

これの出力の
X-X-X
というが、
左から、SSE2、MMX、整数レジスタ(EAX等)の並列数です。
たとえば2-0-2の場合、SSE2で32bitx4 x2、整数レジスタで32bit x1で、9並列での計算になります。

>>170
128本を好き勝手に使えるわけじゃないから。
0173デフォルトの名無しさん2005/07/25(月) 23:23:55
ってより…
メモリモデルのタイニー、スモール、コンパクト、ラージの話に近いんじゃないのかね。
あの時よりも、メモリの増大量が全く追いつかない訳だから、64bit化って意味だと時間は当然掛かるでしょ。
レジスタ数が増える分の向上はそれなりに大きいからx64化自体は急速に進むだろうけれども。
0174デフォルトの名無しさん2005/07/25(月) 23:44:01
アドレス空間が広いのでファイルをマップするような場合はとても楽。
今の64bitを往時の32bitに例えると、今の32bitが往時はバンクメモリやらEMSやら。
データベースや全文検索など今後は個人や小規模オフィスでも需要が確実にある
応用に格段に有利だし、移行を進めるマーケットのパワーも往時より遥かに
強いので今更32bitにこだわるのはただのバカ。

>>173
レジスタ数なんて瑣末なことはほとんどx64の普及の要因とはなっていないよ。
そんなのは64bit化のついでに変わる様々なことのごく一端でしかない。
0175デフォルトの名無しさん2005/07/25(月) 23:49:01
いくらメモリ空間が膨大にあっても、
ファイルを丸ごとメモリマップした場合、
プログラムからOSへヒントをちゃんと与える仕組みがあって、
適切にヒントを与えないと、かなりパフォーマンス的に厳しいものがある。
0176デフォルトの名無しさん2005/07/25(月) 23:57:14
というのではわからない人もいるか。

実メモリの数倍のサイズのファイルを丸ごとメモリマップして、
先頭→末尾→先頭と、メモリを舐めた時に、何が起こるのか、
よく観察してみると、何が言いたいのかわかると思う。
0177デフォルトの名無しさん2005/07/26(火) 01:34:25
>先頭→末尾→先頭と、メモリを舐めた時に
ライトするならヘッドが結構動くだろうけど、そもそもそういった使い方はしないんじゃないかな？
ディスクのいじめ方を知るにはいいと思うけど。
0178デフォルトの名無しさん2005/07/26(火) 01:43:33
OS的には先読みするかと、どのページを残すかというアルゴリズムの問題だから
64bitだからといって大きく変わるわけではない。どうせ残せるページの数は実メモリ
のほうで決まるからね。OS的にはむしろ自由度が上がるという感じ。
0179デフォルトの名無しさん2005/07/26(火) 01:47:53
いくらメモリが使えても、MMXが使えないんでは無意味。
0180デフォルトの名無しさん2005/07/26(火) 02:04:45
>179
なるほど、んじゃ何使うね？
0181デフォルトの名無しさん2005/07/26(火) 02:23:21
広い空間が不要でMMXが使いたいのなら32bitコード使ってりゃいいじゃん。
0182デフォルトの名無しさん2005/07/26(火) 13:21:38
仕事で64bitに対応させざるを得ないこともあるんだろう。
0183デフォルトの名無しさん2005/07/26(火) 13:36:06
仕事で金貰えるんならMMXが使えないくらい我慢しろ。
0184デフォルトの名無しさん2005/07/26(火) 14:52:38
64ビットにしたら速くなるんでしょ?

というアホな客のために対応せざるをえないこともある。
んで、速くならなくて怒られる。
速くならないですよって最初に言ったじゃないですか、
とかいっても、それを信じないような客は覚えてないし、
責任も取らない。
0185デフォルトの名無しさん2005/07/26(火) 15:13:29
ところで、64ビットではx87が一切使えないって話だけど、
超越関数はどうやって実現してるんだろ？
SSEにfsincosみたいのあったっけ？
0186デフォルトの名無しさん2005/07/26(火) 15:36:14
おれはほんとに64bitが必要になるまで32bitで行く。
64bit演算が必要なくらいじゃロングモード使う必要ない。
32bit以上の計算がいるなら浮動小数で十分な場合が
ほとんどだし、__int64もある。
malloc(2GB)が必要にならない限り…
0187デフォルトの名無しさん2005/07/26(火) 15:48:33
>>186
じゃ、このスレには用はないね。さようなら。
0188デフォルトの名無しさん2005/07/26(火) 15:51:19
……あーすまん、それはウソだ。
0189デフォルトの名無しさん2005/07/26(火) 15:57:35
>>185
某OS以外では使える
0190デフォルトの名無しさん2005/07/26(火) 18:13:13
>>172
オレももういちどXMMのコード見直してみるか。
とはいえロングモードでインラインアセンブラは欲しい
0191デフォルトの名無しさん2005/07/26(火) 18:17:29
>>185
そら反復法だべ
0192デフォルトの名無しさん2005/07/26(火) 18:26:30
>>161
＞単純にレジスタが大きいから小回りが効かない。
これ、ネックになってる気がする。
0193デフォルトの名無しさん2005/07/26(火) 18:45:43
>>191
64bitではプログラムで超越関数を実現してるのか。恐れ入った。
もうさ、それでは絶対にx87より速くなりっこないから。
0194デフォルトの名無しさん2005/07/26(火) 18:50:56
>>193
そんなこたぁない。
0195デフォルトの名無しさん2005/07/26(火) 18:51:56
RISC的な考え方なのかもしれない。

どうせ複雑な処理はマイクロコードで展開するわけで、
だったらコンパイラにやらせりゃいいじゃん、という。
0196デフォルトの名無しさん2005/07/26(火) 19:03:43
32bitな某コンパイラも、超越関数はソフトウェアだな
0197デフォルトの名無しさん2005/07/26(火) 19:58:27
なんで妙な勘違いするんだろうね。
0198デフォルトの名無しさん2005/07/26(火) 20:05:42
一昔前のマイクロコードだと超越関数は反復(CORDICとかSTLとか)だったけど
精度保証がいらないなら級数展開が断然速いんじゃないかな。

64Bitの話題から脱線しまくっております。
0199デフォルトの名無しさん2005/07/26(火) 20:14:02
>>196
詳しく。
MSCは直接x87を呼んでいるようだけど。
0200デフォルトの名無しさん2005/07/26(火) 20:35:45
プログラミングって、インラインアセンブラがあるからこそ
高尚なものになりえてると思うんだ。
0201デフォルトの名無しさん2005/07/26(火) 20:55:47
>>198
反復ってNewton法みたく収束反復のことでは?
0202デフォルトの名無しさん2005/07/26(火) 23:29:41
>>200
ネタですか？
0203デフォルトの名無しさん2005/07/27(水) 00:24:23
>>171
思うにハードが十分普及して枯れてきてからが、ハードの演算ユニット実装数に依存しない
APICアーキテクチャの本領発揮かと。

>>172
やっぱりnyTripperの人が来てたのか。MD5を並列とか言ってたからそんな気がしてた。
# てか俺もトリップ関連のソフト作ってるんだけどさ（ぼそ
そのうちPentium M最適化もおながいしますね。命令のレイテンシ短めだから、依存関係の
引き伸ばしはあんま必要なく、むしろレジスタを節約してL/S頻度を落としたほうがよさげでｓ。

で、そのPenM、たぶんクロックあたりのMMX性能は最強の部類に入るのにSSE2はサッパリ駄目ですな。
XMM μOPｓフュージョン実装待ちかな。

>>196
たしかPowerPC 970向けの最適化がそんな感じ。




ATL/WTLをWin64向けにビルドしても結構バグで落ちるらしいけど
大丈夫かいのう
0204デフォルトの名無しさん2005/07/27(水) 00:25:52
淫乱アセンブラ使いたいならgccでいいじゃん
0205デフォルトの名無しさん2005/07/27(水) 00:26:36
>>171
思うにハードが十分普及して枯れてきてからが、ハードの演算ユニット実装数に依存しない
APICアーキテクチャの本領発揮かと。

>>172
やっぱりnyTripperの人が来てたのか。MD5を並列とか言ってたからそんな気がしてた。
# てか俺もトリップ関連のソフト作ってるんだけどさ（ぼそ
そのうちPentium M最適化もおながいしますね。命令のレイテンシ短めだから、依存関係の
引き伸ばしはあんま必要なく、むしろレジスタを節約してL/S頻度を落としたほうがよさげでｓ。

で、そのPenM、たぶんクロックあたりのMMX性能は最強の部類に入るのにSSE2はサッパリ駄目ですな。
XMM μOPｓフュージョン実装待ちかな。

>>196
たしかPowerPC 970向けの最適化がそんな感じ。




ATL/WTLをWin64向けにビルドしても結構バグで落ちるらしいけど
大丈夫かいのう
0206デフォルトの名無しさん2005/07/27(水) 00:29:54
>>171
思うにハードが十分普及して枯れてきてからが、ハードの演算ユニット実装数に依存しない
APICアーキテクチャの本領発揮かと。

>>172
やっぱりnyTripperの人が来てたのか。MD5を並列とか言ってたからそんな気がしてた。
# てか俺もトリップ関連のソフト作ってるんだけどさ（ぼそ
そのうちPentium M最適化もおながいしますね。命令のレイテンシ短めだから、依存関係の
引き伸ばしはあんま必要なく、むしろレジスタを節約してL/S頻度を落としたほうがよさげでｓ。

で、そのPenM、たぶんクロックあたりのMMX性能は最強の部類に入るのにSSE2はサッパリ駄目ですな。
XMM μOPｓフュージョン実装待ちかな。

>>196
たしかPowerPC 970向けの最適化がそんな感じ。




ATL/WTLをWin64向けにビルドしても結構バグで落ちるらしいけど
大丈夫かいのう
0207デフォルトの名無しさん2005/07/27(水) 00:41:17
落ち着けよ
0208デフォルトの名無しさん2005/07/27(水) 00:53:09
ごめん、なんかサーバの調子が悪くて連投になってもうた
0209デフォルトの名無しさん2005/07/27(水) 01:07:44
>>199
ICCのP4向け最適化がそんな感じだったかと。
0210デフォルトの名無しさん2005/07/27(水) 01:29:16
std::swap(p1, p2); で xchgに展開してくれるのが真の最適化コンパイラかと思う。
Intelコンパイラは酷すぎ。C++ライブラリクラスのメソッドのインライン化が全く利いてくれない。
SIMDだけなら最強だけど・・・
0211デフォルトの名無しさん2005/07/27(水) 01:43:10
xchgってかなり遅いんじゃなかったっけ？普通のロード/ストアに比べて。
そもそもバスロックかかるし。
0212デフォルトの名無しさん2005/07/27(水) 01:56:23
バスロックはかからないよ。

たいていはlock prefix付けてバスをロックして使うけどさ。
0213デフォルトの名無しさん2005/07/27(水) 02:29:22
レジスタ値の交換には有効でしょ。

Pen4はメモリ−レジスタが半端なく時間かかる
0214デフォルトの名無しさん2005/07/27(水) 03:14:43
>>212-213
えーと、インテルのマニュアルを読んだことはありますか？
0215デフォルトの名無しさん2005/07/27(水) 03:16:19
というか、インラインアセンブラだの最適化だのほざいてるのって
結局この程度の連中が殆どなんだよね。
0216デフォルトの名無しさん2005/07/27(水) 03:31:13
>>215
そういうお前は「この程度」以下なわけだな。
0217デフォルトの名無しさん2005/07/27(水) 11:12:30
つーか210は突っ込み所満載だからネタだろ？
0218デフォルトの名無しさん2005/07/27(水) 11:52:33
結局インラインアセンブラなんて使わずに、コンパイラに任せた方が大抵早くなるってこったなｗ
つーか、最近のコンパイラの最適化を侮っちゃいけない。
あれに勝てるアセンブリコード書ける人間なんてそういないんだし・・・
高速化のためにインラインアセンブラ使わせてくれってやつは、自分の実力把握してないんじゃね？

いや、別に馬鹿にしてるんじゃないよ。ただ何度も言うが最近のコンパイラに勝てる人間なんてそういないんだから…

0219デフォルトの名無しさん2005/07/27(水) 12:01:33
xchg

デスティネーション・オペランド（第1 オペランド）の内容をソース・オペランド（第
2 オペランド）の内容と交換する。オペランドには、2 個の汎用レジスタまたは1 つの
レジスタと1 つのメモリ・ロケーションを使用できる。メモリ・オペランドが参照さ
れていると、LOCKプリフィックスの有無、あるいはIOPL の値に関係なく、プロセッ
サのロッキング・プロトコルが交換操作が持続している間自動的にインプリメントさ
れる
0220デフォルトの名無しさん2005/07/27(水) 12:32:05
夏だな
うぜー
0221デフォルトの名無しさん2005/07/27(水) 12:35:13
Athlon64だと、XCHGは16クロックもかかる。（L1ヒットで）

mov rax, a
mov rbx, b
mov b, rax
mov a, rbx
の方がずっと速いと思う。
0222デフォルトの名無しさん2005/07/27(水) 12:37:25
>>218
コンパイラが吐かない命令を埋め込むときに使ったな。
ビットスキャン(場合によっては速い)とか
スピンロックとか。

あ。MMXモナー
0223デフォルトの名無しさん2005/07/27(水) 13:41:05
MMX使ってる原始人はもうこのスレ来るなよ
0224デフォルトの名無しさん2005/07/27(水) 14:00:03
Win64限定じゃあるまいし
0225デフォルトの名無しさん2005/07/27(水) 16:07:07
>>210
レジスタが空いてないときに交換するなら便利かもしれんが、
そもそも自分でアセンブラ書くときにxchg使ったことないな。


>>213
Pen4ってLoadは普通に速いし、Storeはライトスルーだけど
その対策として384byteのストアバッファがあるから、交換目的には問題ないと思う。
0226デフォルトの名無しさん2005/07/27(水) 23:53:10
>>221
レジスタ同士の値交換したい場合は？

まあ別に値さえ同じじゃなければ
xor *ax, *bx
xor *bx, *bx
xor *bx, *ax

でもいいんだけどさ。
0227デフォルトの名無しさん2005/07/27(水) 23:53:53
こうや・・・間違えたorz

xor *ax, *bx
xor *bx, *ax
xor *ax, *bx
0228デフォルトの名無しさん2005/07/27(水) 23:57:09
http://www.dd.iij4u.or.jp/~okuyamak/Information/xor_fixed_swapping.html
0229デフォルトの名無しさん2005/07/28(木) 00:20:45
いまさら奥山教祖かよ、、、
0230デフォルトの名無しさん2005/07/28(木) 00:52:50
少なくとも現代のCPUならテンポラリレジスタ使って普通に書いたほうが
ずっと速いぞ。64bitならレジスタも増えるし。
0231デフォルトの名無しさん2005/07/28(木) 20:12:03
x86やx64のxchg命令は速度よりアトミックな交換ができるという点が重要なわけで
0232デフォルトの名無しさん2005/07/29(金) 00:42:57
/O3や/Oxでコンパイルしてもstd::swapをわざわざ関数コールするICCのアホさ加減こそ突っ込みどころじゃなかろうかと
0233デフォルトの名無しさん2005/07/29(金) 01:44:10
>>232
関数なんてコールしていないじゃないか。
嘘つき野郎
0234デフォルトの名無しさん2005/07/30(土) 00:08:29
嘘も方便
0235デフォルトの名無しさん2005/08/02(火) 12:45:15
、 ｌ ‖＿ ＞:=‐ ￣￣「　ｌ| l　 　 } ､　　ヽ 　　んっ　んんっ…
ヽ　､i`─ '´　___　　　｜ ｌl　⌒;　j　 、 　 ヽ
　＼ヽ　r,ﾆ､‐‐'‐'　u　.ｌ　ｌl 　 '_ノ　　 ､　 　 ヽ　
　　 ｀ ＼"＼):､　　　 ｜ ｌ|　　｀､　ヽ　 ､　　　ヽ
　　　 　 ヽ　 ゞ'＾ 　 　 !　lｌ　　　｀､　ヽ　　､　 　 ヽ
　　　　　丿　 　.:::.　　｜ l|　　　　 ＼　ヽ、　､　　 ヽ
　　　　 丶､_　 　 　 　 |　l|/ｌヽ　　　｀＞=‐- ミヽ 　 ｀、
　 　 　 　 　 ｀⌒ヽ_　　|　ｌ| |　ﾊ　 ／´　　　　 ｀ヽ　　 ､
　　ﾁｭﾊﾟ　　/　　/.　｀´|　ｌ| | l / 〃　　　　　　　　｀、　 ､
　ﾁｭﾊﾟ　　/ 　　/ 　 　 |　ｌ| | l' 〃　　　　 　 　 　 　
このレスを見た人はコピペでもいいので
10分以内に3つのスレへ貼り付けてください。
そうすれば１４日後好きな人から告白されるわ宝くじは当たるわ
出世しまくるわ体の悪い所全部治るわでえらい事です



0236デフォルトの名無しさん2005/08/06(土) 19:35:56
32ビット実行形式から64ビットモジュールを呼び出す方法は存在しないのか?
0237デフォルトの名無しさん2005/08/06(土) 19:42:45
ShellExecuteかsystemあたりでパラメータ渡して起動するだけなら原理上できそうだけど
それに何のメリットがあるのか
0238デフォルトの名無しさん2005/08/06(土) 19:43:09
ないわきゃない。API呼び出しは結局すべて64bitのntdllに転送されてるんだから。
でも公開されてない。
0239デフォルトの名無しさん2005/08/06(土) 19:48:18
out-of-process COMって手もあるね。結局はプロセス間通信だが。
0240デフォルトの名無しさん2005/08/07(日) 02:58:35
まあ32bit/64bitの区切り単位がプロセスなんだからプロセス間通信になるのは
仕方ないよね。COMでも自前で適当なstubを書いてもいい。
そのあたりを自動生成するツールなんてもう誰か書いてそうな気もするけど、ないの?
0241デフォルトの名無しさん2005/08/07(日) 03:04:01
で、その橋渡しをするのが怒涛熱湯ですよ

本屋を当たる限りWin64の情報が全く無いんだけど、全部CLRに移行させる気なのかね。
基本命令セットすら知らない。
mmintrin.hで書いたMMX向けコードをx64向けにコンパイルしたらｘ64汎用レジスタベースに展開されてしまった。
パックド演算特有の処理をどう展開するのかはまだ試してないが。
0242デフォルトの名無しさん2005/08/07(日) 03:17:58
基本的には*mmintrin.hで書いておけばx86でもx64にもIA64にも対応する並列化コードが書けることだけはわかった。
それにしてもItaniumのコード素晴らしすぎる。惚れた！ここまでレジスタがリッチだとなんでもできんのね。
一般向けには売らないのかしら。。。
0243デフォルトの名無しさん2005/08/07(日) 03:23:31
Intelは一般向けもIA64に移行させる夢を描いていましたが
市場にそっぽを向かれてAMD64で止めを刺されますた
0244デフォルトの名無しさん2005/08/07(日) 03:36:43
唯一Powerに対抗できるプロセッサだし方向性が間違ってたわけじゃないとおもうけど
ダイナミックトランスレーションで「同クロックのNetBurst並みの性能」じゃちょっとどうしようもないかもね。
同クロックのPentium M並みならかなりイイが
0245デフォルトの名無しさん2005/08/07(日) 03:37:29
>>242
つ ttp://page9.auctions.yahoo.co.jp/jp/auction/k23304285

いまんとこ5万円だ。
0246デフォルトの名無しさん2005/08/07(日) 03:39:31
やっぱLinuxしかないのか。
0247デフォルトの名無しさん2005/08/07(日) 03:52:57
単にOSなしってだけで、WindowsはMSDNでダウンロードすればいいんですよ。
0248デフォルトの名無しさん2005/09/03(土) 02:16:52
64bitアプリ開発の参考になるサイトない？
0249デフォルトの名無しさん2005/09/03(土) 06:28:41
OSは?
0250デフォルトの名無しさん2005/09/03(土) 17:54:56
64bit版WinXP
02512492005/09/03(土) 20:59:01
>>250
ならば、マイクロソフトのサイトやMSDNを見たほうが早いよ。
0252デフォルトの名無しさん2005/09/04(日) 01:49:31
開発環境の設定の仕方とか載ってるかな？
このサイトを参考にして設定したんだけど、複雑になってしまい環境を変更が簡単にできない…

http://www.02.246.ne.jp/~torutk/cxx/vc/vctoolkit2003.html
http://pcweb.mycom.co.jp/special/2005/compiler/009.html

今のところ支障はないみたいだけど…もっと簡単な設定方法ないかな？


■ このスレッドは過去ログ倉庫に格納されています