【IA64】64bitプログラミング総合スレ【[x86-64】

無いので建ててみました。
32bitコードから、64bitコードへ移行する際の質問などなど
言語、OS問わずここでやりましょう。

関連スレ
【AMD64】64ﾋﾞｯﾄﾌﾟﾛｸﾞﾗﾐﾝｸﾞ【EM64T】
http://pc5.2ch.net/test/read.cgi/tech/1098018478/

乙。ようやくまともな６４ビットのスレが立ったな。

【[x86-64】
の "[" は何？ｗ

エスケープシーケンス

SPARCv9は?

http://www.sparc.org/standards.html

すれ立てるまでもない質問板で質問させていただいたのですが、このスレがたったので
こちらの方がふさわしいと思い再度投稿します。

32bitマシンで使っていたCのコードを64bitマシンで使えるようにしようと思っています。
その中でseekについて質問です。
32bit用ではseek(file名、値(移動する場所)、SEEK_CUR)とやっていたのですが、
64bitではそれが使えずにlf64というものを使わなければいけません。
WEBで検索したりもしたのですが、どうも用法が間違っているのかコンパイルできません。
もしlf64についてよくご存知の方がいらっしゃいましたら必要なヘッダファイルや用法など
教えていただけないでしょうか？よろしくお願いいたします。
OSはSolaris8です。

ここってむしろアセンブラ使ってる人か、Windowsプログラマ
向けのスレじゃないのかな。UNIXスレの方が適切だと思うけど。
UNIXの世界だと1990年代なかばから64bitマシンが普及しだした
ので、いまでは当たり前の機能だし、スレのタイトルには
x86_64 と ia64 はあるけど UltraSPARC はないし。
(Solaris 8 ってことは x86_64 じゃなくて UltraSPARCだよな。)
それに、その質問は実は 64bit マシンを使う時の質問じゃなくて
ファイルサイズとして 64bit を使いたい場合の質問なんだが。
(32bit モードでも、これから説明するやり方ならファイルサイズ
として 64bit を使える。)

まあいいや。

まず、そもそも seek() なんて関数ないだろ。
使ってたのは fseek(3) なのか lseek(2) なのかどちら？

解決方法は2通りある。

1. ファイルサイズ／オフセットを示す型として off64_t を
　使う。関数は fseek64(3) ないし lseek64(2) を使う。
　この方法の場合、コンパイラのオプションに以下を指定すればよい。
　-D_LARGEFILE64_SOURCE `getconf LFS64_CFLAGS` `getconf LFS64_LDFLAGS` `getconf LFS64_LIBS`
2. ソースコードは基本的には書き換えない。ただし、
　ファイルサイズ／オフセットの型として int や
　long を使っていた場合、それらを off_t に書き換える
　必要がある。
　この方法の場合、コンパイラのオプションに以下を指定すればよい。
　`getconf LFS_CFLAGS` `getconf LFS_LDFLAGS` `getconf LFS_LIBS`

詳しい仕様は下記にある。
ttp://www.unix.org/version2/whatsnew/lfs20mar.html
次からはUNIXスレに行くように。

>>9-11
>>8 本人じゃないけど、どうもありがとう。

>>9-11
使っている関数はfseek(3)でした。
アドバイス感謝いたします。がんばってみます。
次からはUNIXスレにいきます。

　￣￣￣￣￣￣○￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　O 。
　　　　　　　　　　　　　　　　 , ─ヽ
＿＿＿＿＿＿＿＿　　　　/,/＼ヾ＼ 　　／￣￣￣￣￣￣￣￣￣
|＿＿|＿＿|＿＿|＿　　 __（（´∀｀＼　）＜　というお話だったのサ
|＿|＿＿|＿＿|＿＿　／ノへゝ/''' 　)ヽ　　＼＿＿＿＿＿＿＿＿＿
||＿＿|　　　　　　　 | | ＼´-｀）　/　丿/
|＿|＿|　从.从从　　| ＼__￣￣⊂|丿/
|＿＿|| 从人人从.　|　/＼＿＿/::::::|||
|＿|＿|／//ヽヾ＼　 /　　　::::::::::::ゝ/||
────────(~〜ヽ::::::::::::|／　　　　　　　　＝ 完 ＝

libcってどうやったら更新できますか？

>>15
libcを更新するプログラムを作りたいという話？

VC++の64bit版まだー ﾁﾝﾁﾝ

C#へどうぞ

Visual C++ 2005 っていつリリースなの？今年の夏ぐらい？

マイクロソフトに聞いてこい

もう出ないらしいよ

>>1
重複

【AMD64】64ﾋﾞｯﾄﾌﾟﾛｸﾞﾗﾐﾝｸﾞ【EM64T】
http://pc5.2ch.net/test/read.cgi/tech/1098018478/l50

.NET2003のライブラリが入ってるPlatform SDKもまだβ。
Visual C++ 2005はそれより後。

同じ64ビットでも、IntelとAMDじゃ全然中身が違うようですが、
どっちが64ビットの主役になっていくんでしょう？
IntelはIA-64で中身(レジスタとか)をがらっと変え、32ビットや16ビットの実行時には、
いちいちモードを切り替えているそうですが、
AMDは従来のx86CPUをそのまま拡張した方法をとったとききます。
現状ではAMDの方が優勢っぽいですが、詳しい人いませんか？

重複誘導

【AMD64】64ﾋﾞｯﾄﾌﾟﾛｸﾞﾗﾐﾝｸﾞ【EM64T】
http://pc5.2ch.net/test/read.cgi/tech/1098018478/l50

今少し調べてみたんですが、どうやら勘違いしていたみたいですね。
IA-64が使われているのはXeonシリーズだけで、
Pentium/CeleronシリーズはIA-32eという、ほとんどAMD-64の名前を変えただけのような
アーキテクチャが使われているそうですね。

誘導厨氏ね。
スレタイに半角使ってるスレなんか認められねーんだよ。

>>26
えーと、釣り？

Xeon も IA-32e (つまり amd64 と同じ) だよ。
IA-64 は Itanium 系だけ。

Itaniumはかつてのi860と同じ香りがしていたのだが、やはり・・
ってどっちが本すれなんだよ。はっきりしてくれ〜

結論。ia64もx64もスレはいらない。
アセンブラスレとWin32、UNIXの専用スレで十分。

IA-64とx64、普通にプログラムを書く分には、違いないだろ。

IA-64とx64を分けるよりも、ターゲットのOSを分けてスレを立てたほうがいい。

>>1はMACヲタ

GR00がRAXと同じ意味なの？

x86-64って、名前の通りx86に64bitのレジスタと命令をちょっと付け加えた形だからなぁ・・・
わざわざ、別スレでする必要もないような・・・。

とか、思ってたけど、何かいざ64bit向けにオプティマイズしたコードを書こうとすると、やっぱ別スレは必要だと思った。

Linuxにsh64っていう名前のコードが入ってるんだけど、
これって実際に使われてるの？

どこのファイル？

linux/arch/sh64

別に32bitがなくなるわけでもない。
ポインタも今まで通り32bitで扱える。
何も恐れることはない。

>>39
何も恐れることはない。

64bitに恐怖するスレはここですか？

さすがに>>38は痛いだろ。
「64bitOS上で動く32bitアプリケーションを開発すること」を
「64bitプログラミング」とは言わない。

64bit環境(LP64,LLP64等)で、ポインタが32bitな環境は無い。
もちろん、LLP64なWin64も。

Windowsはラクチンだね。ポインタしか変わらん。

>>43
MS-DOSや、Window3.1の頃に比べると、隔世したねぇー
にゃーとか、ふぁぁああとか、説明無しに、にゃー使うときは、
ふぁーを使うときは、なんて言われて、絞め殺してやろうかと
思ったよ。

WindowsはNT3.5の時点で既に64bit意識してたしねえ。
ゲイシは94年ぐらいに「5年以内にメインフレームのOSとしても
NTが使われるようになる」と宣伝してたなそういえば。

まあx86系以外のCPUのWindowsもあったわけだし。

>>44
いや、その頃は、8086だったから。CPUが糞だったから。

あーでもプロテクトモードのWin3.1ってのがあったような記憶も・・・・
俺は使ってないからよくわからん。

また昔話が始まるのか

IA-64って主流になるのだろうか
無くなりそうなきがする

コンスーマ向けのIA-64 windowsは作らないからなあ

>>50
分野で生き残るって感じだと思う。
必要な環境では、x86互換命令の拡張命令程度であるx86-64では足りない事もあるだろうし。
俺だって、未だにMIPS系使ってたりするから…。

>>45
実際99年には既にほとんどのCOBOLシステムは
NT上のエミュレータ上で動いていたし、今もそう。

>>51
ﾝﾆｰ系列以外で コンスーマ って言い方するところはどこだっけ?

ところで XP Home x64 って出ないんだっけ?

MS、64ビット版Windowsを4月より提供開始へ
Windows責任者のJim Allchinは、Intel Developer Forumで講演を行い、
64ビット版Windowsのデスクトップバージョンは4月初旬に、
サーババージョンは4月末に登場すると述べた。 （CNET Japan）
http://headlines.yahoo.co.jp/hl?a=20050302-00000007-cnet-sci

いよいよ来ますな。まあ今回は突然Win64でアプリケーションを書くよう
変更を迫られてるわけでもないし、古いアプリケーションについても
64bitOS上で動作するようテストしなくてはならないというわけじゃないけど。
7,8年ぐらいかけてゆっくりと64bit環境になっていくのかな。

だから.Netにしろって言ってるんだろうな

問題はデバイスドライバでしょ。
32bit版は動かないし、.Netにするわけにもいかないし。

6〜7年プログラミングの現場から離れて
完全64bit化が達成されてから戻るのが正解

テストが大変そうね。

4GBを越えた場合に正しく動作すること、なんていうのは、
それなりのデータを与えて処理させないといけないので、
テストが自動運転でも時間がかかるよね。

質問です。
EM64T対応のCPU使ってるんですが、アセンブラ使えば32bitのOSでも64bit化されたアプリケーション作れますか？

それはクロスコンパイルのことかね？

もし、「インラインアセンブラで64bitレジスタが使えるか」という意味なら、無理。

>>59
アセンブラで書いてベースを4GB以上のところに置くとかできないのかな。
ていうか64ビットでもセグメントってまだ残ってるの？

無理

まぁ、とりあえず4GBほど無駄にメモリを確保してから始めればいいのかもな。

え、そういう問題かなあ・・

タスクスイッチでのレジスタ退避の問題だね。
OSXなんか10.3からはG5では64bitレジスタも退避するから
計算に64bitレジスタを使うくらいだったらできる。
ただしページングとかのメモリ管理は32bitのままだから
64bitアドレッシングとかは一切できないから中途半端だけど。
Tigerからは完全64bit対応になるらしいが。

↑
x86の64bitモードを全く知らない奴が
知ったかぶりしようとするとこうなるという良い見本。

周りが見えてませんから。それがマカークオリティ。

>>67
RAXを使うだけならリアルモードからでも出来ますが何か？

これだもんね・・・

まあ拡張レジスタ使って計算するだけならタスクスイッチで退避させるだけで対応できるわな。
64bitに限らずSSEでもOS側のサポートが必要だったのはそこなわけだし。

DOSで32bitレジスタを使用する時と違って
巷に「64bitレジスタを使ったサンプル」が見あたらないのは、
REXプリフィックスが、64bitモード以外では別の命令(具体的には16/32bitレジスタのinc/dec)と解釈され
事実上64bit演算が不可能なためなのだが、
>>69はどうやってリアルモードからRAXを操作するというのかね？

それと話の流れ的には、必要なのは「リアルモードでの操作」ではなく
「32bitOS上での操作」だから。

そりゃ、自力でCRxをセットアップできる環境なら、何でも出来るわな。
もちろん、32bitOS上でも、ドライバを用意すれば出来るだろうけどさ。

マカーもマニュアルぐらいは読んでね。水なしで読んでね♪

>>72
OSが対応しないと出来ないと書いたのだが
叩くことに必至でその程度も読み取れないのかね？

本当にバカだね。
自分で>>69になんて書いたか、もう一度読み直してみてごらん。

>>75
それ別人だから。
>>66には今のOSに手を入れないと無理って書いただけだから。

レジスタの待避が必要なこと(OSの対応が必要なこと)と
16/32bitモードで64bit演算が出来ないこと
この２つには、何の因果関係もない。

後者の事を全く知らずに「OSが対応すれば出来る」などと書くから
>>67のようなレスが返る。
そして必死に>>69のような反応をして、さらなる醜態をさらす。

>>76
で、>>66はどれに対してのレス？
少なくとも、>>60の質問に対する>>61のレスは、
「32bitモードでは64bit演算は出来ない」という意味だよ。
「OSの対応」「レジスタの待避」の問題じゃない。

「OSが対応しても、32bitモードで動作するプロセスで64bit演算は出来ない」
もし、それを知りながら>>66を書いているのなら、ピント外れもいいとこ。

要するに
Powerアーキテクチャ >>>>>>>>>>>>>>>>>>>> x86-64
ってことでよろしいか

逆説的に、>>66がx86の64bit動作に関する知識が無いことは明らかで
それに対する>>67-68のレスは、極めて的確だった

というお話でした。

祝！戦勝！！
アホマカ晒しage

皆様ごめんなさい。どうすれば許してもらえますか？（涙目

>>82
マックを捨ててAthlon64マシンを自作してリアルモードからRAXを操作してみたら許してやらないこともない。

>>69=>>83

茶目のつもりか知らんがかなりイタいな
>>67=>>68
>>72=>>73

えーと、61=67=72=77=78だけど、
マカーをバカにしてるのは別の人だよ。
まあ、>>85が必死なのはわかったけど。

>>72
＞REXプリフィックスが、64bitモード以外では別の命令(具体的には16/32bitレジスタのinc/dec)と解釈され
＞事実上64bit演算が不可能なためなのだが、
＞>>69はどうやってリアルモードからRAXを操作するというのかね？
マカではありませんが大変勉強になりました。
今後ともご指導、ご鞭撻を賜りますよう、よろしくお願い申し上げます。

>>84
俺じゃねえってヴォケ

>>87と>>88の変節ぶりにﾜﾛﾀ。
開き直りが肝心なのか。

もういいから喪前ら糞して寝ろ

遅めの昼飯を食い終わったところだが？

　　　　　　　　　　　　↓糞マカ
　　　　　　　　　　　　　　）
　　　　　　　　　　　　　（
　　　 　　　　　,,　　　　　　　　）　　　　　　）
　　　　 　　　　ﾞﾐ;;;;;,_　　　　　　　　　　　（
　　　　 　　　　　ミ;;;;;;;;､;:..,,.,,,,,
　　　　　　　　　　i;i;i;i; '',',;^′..ヽ
　　　　　　　　　　ﾞゞy､､;:..､）　　｝
　　　　　　　　　　　.¨.､,_,,､_,,r_,ノ′
　　　　 　　　　/;:;":;.:;";i; '',',;;;_~;;;′.ヽ
　　　　　　　　ﾞ{y､､;:...:,:(｀Ａ´).:.､;:.,._､｝
　　　　　　　　".¨ｰ=v ''‐ .:v､,,､_,r_,ノ′
　　　　　　　/;i;i; '',',;;;_~⌒¨;;;;;;;;ヾ.ﾐﾞ´ﾞ^′..ヽ　
　　　　　　 ﾞ{y､､;:...:,:.:.､;､;:.:,:.:.　._　　.､）　　､｝
　　　　　　　".¨ｰ=v ''‐ .:v､冫_._ .､,_,,､_,,r_,ノ′
　　　　　　/i;i; '',',;;;_~υ⌒¨;;;;;;;;ヾ.ﾐﾞ´ﾞ^′.ｿ.ヽ
　　　　　　ﾞ{y､､;:..ゞ.:,:.:.､;:.ﾐ.:,:.:.　._υﾟo,,'.､）　　､｝
　　　　　　ヾ,,..;::;;;::,;,::;):;:;:; .:v､冫_._ .､,_,,､_,,r_,ノ′

つーか、基本的なことなんだけど、

自分で試してもいないことを書くな

周りが見えてませんから。それがバカークオリティ。

>>66は>>79を言うためのマカーの釣りでしたとさ。

ということにしたいのですね？

手のひらを返して大漁とか言い出すのはマカーの常套手段

まあ、x86の命令セット等がボロボロなのは今に始まった事じゃないし
殆どの人がその点は認めてるわけで
>>79の言うことはもっともだとは思う。

ただ、「何を今更？」というだけで。

美しさだけで言えば、最初から64bit前提で作られたIA64が綺麗なんじゃなかろうか。
x86はツギハギだしさぁ

いまだー100ｹﾞﾄ■⊂(ﾟДﾟ,,⊂⌒｀つ≡≡≡ｽﾞｻﾞｰ

longモードでなければ、RAXは使えません。
>>69はバカ

馬鹿(マカ)

>>99
インテルもそう思ってIA-64だったのだろうが、AMDにしてやられて
後追いをるはめに。RISCブームのころに結局x86が勝ち残ったのの再現。
前回とはインテルの役回りが違ってるけどね。

ｵﾁｹﾂ

え、x86って現実的で美しいと思うよ。
R0とか番号振られるより
AX アキュームレーターとかわかりやすいじゃん。

( ´,_ゝ`)ﾌﾟｯ
そんなのニーモニックの問題だろうに・・・

>>99
IA-64は、パフォーマンスを出すために、ごちゃごちゃ付いてて、あんまり綺麗じゃない。

綺麗なのは、パフォーマンスよりも回路規模を小さくすることが優先された、昔のCPUだなぁ。

>>105
>>106
んじゃさ、ソース上でAXとCXを全部入れ換えてみ。

多くのRISC系のR0は例外としても、番号ではなく英文字なのには、それなりの理由があるわけで。

スキャン防止のために三次元マスクかけた回路は綺麗？

>>108
( ´,_ゝ`)ﾌﾟｯ
何のために？

A,B,C,D,E,H,Lは4004/8008からの名残りだよ

ところで、綺麗の基準ってなに？

Cell の SPE のアセンブリがどんなものか気になる。どっかに資料ない
かなあ。

>>111
AFBCDEHL

>>101
>>87

2000DDKでAMD64向けにビルドしようとしても
amd64mk.incが無いってでてコンパイルできねー！！

おっとXPDDKだった

>>110
まぁとにかくやってみろよ。
入れ換えてアセンブルしてみればわかるからさ。

A アキュムレータ
B ベース
C カウンタ
D データ

使う人がなんとなく使い分けてるだけではなく、
レジスタ決め打ちの命令があるんだよ。

>>119
当時は命令が直交していないって68系の人たちからだいぶいじめられた。

WinXP x64 Editionで、v1433にしたらローカル カーネルデバッガが
使えなくなってしまいました。他の方はどうでしょ？

6809もAとBで微妙に扱いが違ってた

>>118
自分でやれよ

x86はプリフィックスとかアドレッシングモードに苦労の跡が見えるね。
もう限界だろう

x512ぐらいまでがんばるよ

>>125
がんばれよwww

>>120
実際、コンパイラの最適化の障害になるからね。

死ぬまでにx128は見れるだろうか

AMD128（10nm、量子演算対応モデル）
Quantron 15000000000000+

あと2ヶ月くらいでx64 Windowsリリースですが、
C++ Builderって64bitコンパイラ出す気ないでしょ

何か問題でも？

ポトペターが困る

困るわけが無いじゃないか

EXE作る分には別に32ビットのままでいい。
そんな大きなメモリを扱うようなアプリを書かないから。

問題はDLL。
64ビットのEXEから使いたいよ〜って言われたら困る。

>>130
すぐには出んかもしれんが、「そろそろ金になる」と思ったら出すのでわ？
C++Builder自体、32bitになってから相当遅れて出てきたし。

64bitのDelphiが出れば、可能性は大いにある。だってコンポーネントおんなじ
だもんね。

確かDelphiって、IDEは当然Delphi製なんだけど
コンパイラが、BCCで作られていたはず。
って事は、(ソース的には当然互換性はあるだろうけど)
まず、C/C++コンパイラが無いと64bit版Delphiは出せない。

もちろん、MS製コンパイラでもDelphiコンパイラは作れるだろうけど
コンパイラベンダーのBorlandが、
他社製コンパイラでコンパイルしたバイナリを製品に含めるのは
いくらなんでもプライドが許さないだろう。

で、結局、64bit版Delphiは、
(商品にするかは別としても)64bit版C/C++コンパイラを作った後になると思われる。

>>136
そうなると、まず32bitのC++コンパイラで64bitDelphiを作り上げて、その後
ブートストラップ的に64bitC++コンパイラでも作るんかもしれんね。

コンパイラ自体は32bitでもいいわけだし。吐くコードさえ64bitになってれば。
つまりクロスコンパイラが一度出来てしまえば、すぐに64bit版C++はできそうな
希ガス。

ところでBCCってSTLportを見捨ててDimkumwareになったらしいね。STLport
本家がいつまで立ってもBCC5.6.4でコンパイルできるSTLport4.6.2を出さない
から悪いんだろうけど、何か嫌な感じ。

Borlandってやる気感じられない。なぜいまだに64Bitコンパイラの予定すらないのだろう？
Microsoftは送れているが予定はある。

まぁ投入できる開発費が違うから。

マイクロソフトは開発言語メーカーとしても巨大だが、自社内での需要も巨大だし。

MSは.net2005で64bit対応じゃね？

なんでやねん

> って事は、(ソース的には当然互換性はあるだろうけど)
> まず、C/C++コンパイラが無いと64bit版Delphiは出せない。

そんなことはない。
32bit 版 C/C++ コンパイラを使って、64bit のコードを
吐ける 64bit版 Delphi を作れるから。(コンパイラ自体は
32bit アプリだが、コンパイラが吐くオブジェクトは 64bit
になる)
まあ、64bit 版 C/C++ コンパイラを優先するだろうという
予測自体はそれなりに妥当だけとは思うけど。

そういや、昔のBorland C++は、Win32アプリをDOS上でコンパイルしてたような希ガス。

Win64(?)になった場合DWORDは32bitのままなのかね？
64bitにすんなり移植できるようなプログラムマナーのようなものきぼんぬ。
WindowsでC言語の場合です。

>>144
DWORDはDWORD32とDWORD64という2つの型が追加される。(DWORD_PTRも数えれば3つ増える事になる)
俺は気に入らない。DWORDという言葉には既に32Bitの意が込められていると思うから。
それよりもQWORD作れよ、と言いたい。

Win64移行のためにVCならポインタと整数とのキャストは〜_PTR型を使わないと警告が出るはず。
〜_PTR型はポインタ型のサイズをそのまま反映した整数型。
(ちなみにW/LPARAMもUINT/LONG_PTRからのtypedefに変更されている)

そこらへん、ここのA6にも書いてある。
http://www.microsoft.com/japan/msdn/library/ja/jpdnw2ksrv/htm/AppSpecServ11.asp?frame=true

そういえば、VCTKで64bit移植性の警告みたいなオプションを付けたら
/W4で何も言わない、自分では64bit(Unix)への移植性も考慮しているつもりなコードに
滅茶苦茶警告が並んであせった覚えが。

/W64か
おれもいろいろ直しまくったけど。

64ビットでコンパイルすれば、自動的に2^32以上を扱えるプログラムになるかっていうと、
そんなに甘くはないんだよね。

たしかMASMで倍精度浮動少数とMMXはQWORDだった覚えがあったのだけど
DWORD64ってなんだよ・・・

まあとりあえず漏れはAPI使わない汎用のコード書くときは
マクロで切り分けて__int8〜__int64みたいなコンパイラ依存の整数型を適当にtypedefした
ヘッダファイルをインクルードして使っているが

あと、SSE*のDQWORDもどうかと思ったけどな。OWORDだろ、と。

C99 なら int8_t/int16_t/int32_t/int64_t がC言語標準としてあるし、
ポインタを納められる整数型もintptr_tがあるから、これらを使えば
わざわざ自分で定義する必要はないと思う。
C89への移植を気にする場合は、これらの型定義を自分で提供する方向で。

Windowsだけで動けばいいならMS標準の型使ってた方がいいとは
思うんだけど、ネーミングセンスがなあ…

ちなみにstdint.hを独自に作るときには__w64を使えばINT_PTRなどに相当する型が作れる。
(/W64でも警告が出なくなる)

http://msdn.microsoft.com/library/en-us/vclang/html/vclrf__w64.asp

そういやBeOSの64bit版は、64bitCPUで使うと２CPUとして認識するようになるらしいぞ。
32bitCPU２個で64bitだ！とか言ってたヤツの逆だなｗ
やっぱ64bitのレジスタを２つにわけるのかな？

>>153
ﾜﾛﾀ
ソースは?

クローズド・ソースです！！！

ttp://www.itmedia.co.jp/enterprise/articles/0503/26/news001_2.html

>驚いたのは、64ビットCPUへの対応だ。同氏は「64ビットCPUは、32ビットのデュアルCPUとして認識する」という。

おいおい、マジかよｗ
どっかのゲーム機の逆だなｗ

>>155
ｻﾝｸｽ

・・・ﾎﾟｶｰﾝ

質問です。
32bitのDLLを64bitのアプリケーションから利用することは可能ですか？
私の開発環境はEM64Tです。

よろしくお願いします。

ちょっと調べれば、あるいは
ちょっと考えれば
わかりそうなもんだけど。

>>158
逆は無理だが一応できるはず。
少なくとも、何かの記事で見た。

利用する関数の引数に64bit混在の場合とかスレッドを作る場合のスレッド間通信とか細かい部分はしらね

その「何かの記事」とは、10年ほど前の16/32環境のものだろう。

あと、「私の開発環境は」と書きながらOSを書かない辺りがさすが。
たとえ「DLL」という呼称から推測が可能だとしても。

64bit化が難しい場合は
COMにしてexeのサーバをおったてるのも手
MSもこれを推奨…

プロセス間通信してもいいけど、
シリアライズコードを手で書くぐらいならCOMったほうがいいのかも

外部ライブラリでもクラスライブラリでもなくDLLなのだから、DLLなんでしょう。

おいおい、WIN64アプリからWin32のDLLの利用は可能だぞ？

>>164
できません。

Out-of-processコンポーネンとして利用できるとMS自身が公言している。

>>158
OSはなんでしょう

>>164
少なくとも、「簡単に」出来るのなら
64bit版WinXPに、32bit版IEが付属するなどという事態にはなりません。
これは、Flush等のプラグインが動かせない事が理由ですので。

>>166
それの意味わかってる?

>>162で激しく既出なんだけどな。

難しい簡単の差はあるものの、実装できないと言うわけではないから
可能と言えば可能だろう。

いや、単に「利用」と言ったら、通常はインポートライブラリなり
LoadLibraryなりdlopenなりして使うことをさすだろ。

>>164 のいう利用の定義によるな。
それが>>162にあるようなブリッジを介することも含んでいる、
と後付けで拡大解釈してあげれば >>164 は汚名挽回だな。

汚名を挽回するのか……。

汚名挽回の起源はジェリドかと思っていたが
ちばあきおのキャプテン内で使われているのを最近読んだ。

DCOMのアウトプロセスサーバは、あんまり良い思い出ないな・・・。

もうすぐWindowsXP x64が出ますな。
こういうときに.NETアプリは便利だなぁ・・・
コード書き換え不要でそのまま64bitネイティブアプリ化するし・・・

>>173へえ、そんな昔から銀英伝からかと思ってた

>>175
中間言語をJITコンパイルするのは、ネイティブとは言わない!

VC2005はいつになるやら

五月出るらしいが。

幸運な事にbit幅に依存するプログラムを書いたことがありません

んなアホな

5月に出るのはPSDKだろ

PSDKって、OSよりも先にfixしてリリースされて来たとおもうけど。

まだβでしょ。x64のは。

ここはwindows専用ですか？

>>1

AMDのACMライブラリのWin用の64bit版ってまだ出てない？
Linuxのみ？

>>180
えっ？ intが16ビットになったら困るコード書いたこと無いの？
int変数に32768(unsignedなら65536)以上の値を入れたこと無いの？

今Winsockでプログラムを組んでるのですが
64bitアプリからは32bitDLLは呼べないんですよね？
と言うことは、64bit用のWinsockで再コンパイルし直さないといけないのでしょうか？
また、64bitのWinsockはもう公開されてますか？

> 64bitアプリからは32bitDLLは呼べないんですよね？
呼べます。

終了〜。

64bit用C++Builderはいつ頃出るのでしょうか？

>>191
米Borlandのニュースグループで尋ねてみては?

>>190
また大嘘かよｗ
>>164と同じやつか？
質問者騙して楽しい？

>>173 どうでもいいけど。
30年位前の消防向け国語辞典冒頭の読み物にあった。

>>189
普通に64ビットでコンパイル・ビルドすればOK。
意識しなくても自動的に64ビット版のDLLを使ってくれる。

WinSockはOSのコンポーネントだからOSに含まれてる。
ヘッダ等はPSDKを。

>>190
インプロセスでは呼べないぞ。

Win9xのLoadLibrary16みたいな隠しAPIはないのだろうか。

下手するとまた裁判沙汰になるからなあ

今回はサンクレイヤーで処理してくれないのかね

64bit版のWinsockって高速化してたりするんだろうか？
32bit以上の値のコピーを1度に出来るとかで、色々速くなってそうな気がするんだけど・・・

メモリコピーを速くしたければ、SSE2使うという手が。

GbE転送ベンチでもしてみないことには分からんのとちゃうかなー

byte benchmark では、x86_64 の方が明らかに速いみたいよ。
メモリフットプリントが増えるのはかえって不利な要素の筈
だけど、レジスタが多いのが効いているんじゃないかという
希ガス。

NICチップとのデータ転送がネックだったらあんまり関係ないような。
IntelのとかだとNICチップ上でいろいろ計算してくれるし...

さて、そろそろX64版WindowsXPが出るわけだけど
現状64bitアプリを開発できるVC++系の環境ってない？
2005は、なんかもう落とせなくなってるし・・・

gccがPE32+扱えないからなぁ・・・

じゃあ、現状無料で手に入る64bitネイティブコードをはき出すコンパイラは無し？
・・・そりゃ、普及しないわけだ・・・

一応PlatformSDKがあるが・・・
しかし、これ落としてもMFC使えないんじゃなぁ・・
VS 2003.NET使ってるが、2005が出たら速攻乗り換えなければならん・・・。

PSDKのコンパイラって、MFCコンパイルできないの?

>>207
まだ出てもいないのに、
普及しないわけだと結論だすのもどうかと思うが。
ということにしたいだけなのかな？

現段階で試験的にもっと出回っててもおかしくないのに普及してないってことだろ。

winXP x64のv1433では、kd.exeは使えないんですか？

＞The system does not support local kernel debugging
＞Local kernel debugging requires Windows XP, Admini
＞privileges, and is not supported by WOW64.
＞Only a single local kernel debugging session can r
＞Debuggee initialization failed, HRESULT 0x80004001

といエラーメッセージが出てきます。v1289では動いたのに。

MSDNでVS 2005beta2出てるよ。

おまいらは、普通に32ビットアプリを書いていればよし。
何が理由で64bitでビルドするの？

そこに64bitがあるからだろ

215がいいこと言った

えーと64bitだと符号なしでどの位の整数が表せるんだっけ

10エクサぐらい

零から壱千八百四十四京六千七百四十四兆七百参十七億九百五十五万壱千六百壱拾五まで

32ビットだとオーバーフローを気にしながらコーディングするが、
64ビットだと、事実上無限大だと思って気にしなくなって、
あとで悲惨なことになりそうだな・・・。

つまり１バイトが６４ﾋﾞｯﾄになるの？

そんなエサで俺様が(ry

ディスクのサイズはとっくの昔に4Gじゃ足りなくなってるし、
メモリもそろそろ4Gじゃ足りないからでそ。

純粋にメモリ空間足りないから。。。
Windowsプロセスでユーザが使えるの2GBにも満たないし、もう窮屈だよ

初心者ほど高価な道具を欲しがる。

64bit環境は別に高価ではないが？
手軽に64bitを試せるんだから各々好きにやればいいｼﾞｬﾏｲｶ

>>224
1プロセス2GBで足りなくなるって、すごいプログラム書いてるんですね。

漏れなんて、マルチメディア系のファイルを頭から尻尾までメモリマップでもしなければ、足りなくならない。
そして、あまりにそれがパフォーマンス的に無駄で、早々にちまちま読み書きするように直すのでした。

あーでも、各種DLLがぶくぶくに太って、LoadLibraryしただけで埋まる、なんて時代が来るのかもな。

Windowsのx64 Editionはコンテキストスイッチの際に
FPU レジスタを保存しないって本当ですか？

AMD64のマニュアルでは64bitモードでも
x87,MMX,3DNowが使えると書いてあるようですが…

64bitモードではSSE使えよ

インラインアセンブラでx87を使っているWin32アプリを64bitに移植する場合、
x87をSSE2で書き換えなければならないのかと思って聞いてみた次第。

>Windowsのx64 Editionはコンテキストスイッチの際に
>FPU レジスタを保存しないって本当ですか？

つか、これのソースは？

ごめんなんでもない。>>231はなかったことに・・・

>>230
移植しなきゃいいじゃん。何もしないで問題解決。素晴らしい。

64ﾋﾞｯﾄ化！　64ﾋﾞｯﾄ化！　
さっさと64ﾋﾞｯﾄ化！　
しばくぞ！

x64のLONGモードは、x87をサポートしてない、ってどこかで読んだけど。

>>230
インラインアセンブラでx87使うって、珍しいね。

MMXもね。Intel C++もVC++もそうじゃないの。

いちおう何故か__m64型はあるけど

x87がネックなのはいいとして、
SIMDでもないものまでSIMDで計算するっていうのも豪快だよね。

double2個の計算を1個ずつ2回にわけてやる実装のCPUへの嫌がらせにもなるね。

ところでlong doubleはどうするの?

AMD64のマニュアルの293-294ページには64bitモードでも再コンパイルすればx87が使える
と書いてあるようですが、

ttp://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24592.pdf

↓ここでは

ttp://techreport.com/reviews/2005q1/64-bits/index.x?pg=2

> WinXP x64 doesn't carry over the registers for the FPU
> and MMX during context switches in 64-bit mode.

と書いてあるのでWindows x64でx87は駄目なのかと思いますた。

>>234
fsincosとかコンパイラがあまり吐いてくれない命令を使ってまふ。

>>236
XMMレジスタ使ってスカラー演算するだけじゃないの？
ADDSS とか ADDSD みたいな

AMD64の古いコアだと、LONGモードでもx87レジスタはコンテキスト
スイッチの際退避されるみたい。
OSの仕様上保障はされていないけどね。

>>239
FPUレジスタが退避されるのはWOW64上で32bitアプリ(16bitアプリも)を
動かしたときだけかと思われ。
レジスタの退避はOSの仕事なのでコアの新旧は関係ないでしょ。

Windows XP Professional x64 Edition 発売記念あげヽ(`Д´)ﾉ

>>239
うちはC0コアだけど、確認しました。
これはfast fxsave/fxstoreのあるなしの関係かな？

確認に使ったプログラムです。
これを2つ、それぞれ違う数値をコマンドラインに入れて起動します。

void main(int argc, char *argv[])
{
double a, b;

a = atof(argv[1]);
x87_load(&a);
while (1)
{
Sleep(1000);
x87_store(&b);
printf("%f", b);
}
}

.code

x87_load proc
fldqword ptr [rcx]
fldqword ptr [rcx]
fldqword ptr [rcx]
fldqword ptr [rcx]
fldqword ptr [rcx]
fldqword ptr [rcx]
fldqword ptr [rcx]
fldqword ptr [rcx]
ret
x87_load endp

x87_store proc
fstqword ptr [rcx]
ret
x87_store endp

end

>>242
勘違いしていないか？
fast fxsave/fstorは、XMMレジスタについて保存復元を「しない」
ものだよ（LONGモードかつRING0でのはなしね）

>>245
あらーｗ
242-244は忘れてください。

>>243-244を実行してみたけど、x87ステートも保存しているよな。
なぜ？ xp x64の製品版はどうなんだろ。

誰かXP x64買ったか？

ｷﾆｽﾙﾅ!!

おまえらとりあえずPDF読めば？

>>250
読んだ上で言っています。

>>247
プログラマが反抗したい年頃だったから。

XP x64にインストールしたVS2005β2で64bitプログラムを実行してみたところ、
レジスタウィンドウにはGPR,Flag,XMMしか表示されませんですた。
(x87,MMX,3DNowは淡色表示になっていて選択できない状態)

>>253
これ使えば
http://www.microsoft.com/whdc/DevTools/Debugging

>>254
ｻﾝｸｽ子
あとで試してみます

>>253
VS2005のコンパイラはインラインアセンブラ使える？
ddk付属のx64版clやIntelC++だと使えなくなっているんだけど。

>>256
駄目ですた。>インラインアセンブラ

VSのドキュメントにも

> Inline assembly is not supported on the Itanium and x64 processors.

と書いてますた。

WinXP X64購入記念にVC++2005ベータでWinsock使おうと思ったらないって言われたので
プラットフォームSDKを落としてこようと思って
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/
にアクセスしたら、32bitマシン(32bitIE)で来いと言われた・・・orz

まだ64bitのSDKはないの？

あれ？32bitのIEでもだめだわ・・・
どうしよう・・・・。

VS2005β2に入っているPSDKならWinSock使えるけど？

なんでWinsockないの?

PSDKにヘッダとインポートライブラリついてないの?

ちゃんとIA64のディレクトリにWS2_32.libがあるぞ。

ソースコードコンパチなんだから、とりあえずIA64で開発したら?

本当だ
俺もVC++2005で何か作ろうと思ったら
Winsock2.hやwindows.hがないって言われた。
標準装備じゃないの？

PlatformSDKに統一するとか言ってた気がする
VC++自身には含まれなくなったんじゃないかなあ

>>258
Windows Server 2003 SP1 Platform SDK
http://www.microsoft.com/downloads/details.aspx?familyid=EBA0128F-A770-45F1-86F3-7AB010B398A3&displaylang=en
http://www.microsoft.com/downloads/details.aspx?familyid=D8EECD75-1FC4-49E5-BC66-9DA2B03D9B92&displaylang=en
http://www.microsoft.com/downloads/details.aspx?familyid=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en

統一できてないじゃん・・

>>265
新しいml64ではx87命令が使えなくなってますな。

XP X64買ってせっかくなんで、HelloWorldやってみようと思ったら・・・
64bitアプリの書き方がわからない・・・orz

VC++2005と>>265のを落としてきて
PSDKのVC++への登録バッチを実行したんですけど
その後、普通にプロジェクト作って64bitバイナリを吐き出すオプションの方法がわからないです。

リンクオプションで、machine typeをAMD64選択してコンパイルすると
.\release\stdafx.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
こんなエラーが・・・。

VS2005 beta2ってMSDN入っていなくてもDL出来るの？
なんかCD購入（CDはタダだけど送料がかかる）画面にいっちゃうん
だけど。

>>269
Express以外はDLできない。お布施がいやなら雑誌にでも載るの待ちましょう。
注文したほうが安そうだけど。

>>268
VCが対応してないからな。
一般公開のだと、Win32しか選べないと思う。
リンクの設定だけ、それにしても無理

俺もX64プログラムのmake方法がわからん。
正直まとまった資料が無いんだよな。
多分ここがX64ネイティブアプリが増えない最大の理由のような・・・

コマンドラインでHello Worldも作れないんか？

Cマガジン2004年10月号に64ビットプログラミングの特集があって
VisualStudio.NET/.NET2003/6.0のいずれかとPlatformSDKの組み合わせか
VisualStudio2005βを使うって載ってるから使えそうなんだけど、駄目そう？
環境設定方法が載ってるから試したいんだけど、時間がない。。。

関係ありそうなところを写してみる。
プロパティの[C/C++]、[全般]、[デバッグ情報の形式]を[プログラム データベース (/Zi)]。
プロパティの[リンカ]、[コマンドライン]、[追加のオプション]に[/machine:AMD64]。
うまくいきます？

>>275
それでやってみましたけど
.\Release\stdafx.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
と出ますね。
VC++2005エクスプレスBeta2と>>265の組み合わせです。

>>269
注文した。DDKの時は配送料$15だったのに、今回は$20。ﾅｼﾞｪ?

>>276
書くだけじゃなんなんで、VS2003でやってみました。そして駄目でした。
Cマガに書いてあった内容も、
http://www.amd64dev.com/kaihatu/document/30887.html
と同じで特別なことは書いてないみたいで。すまんです。

Makefileくらい書いたらいいじゃん。

>>276
/machine:amd64をﾘﾝｶ ｵﾌﾟｼｮﾝにつけても駄目？
うちはVC6.0でうまくいったけど。

>>280
275で書いてあるじゃんｗ

18446744073709551616

時間ができたんで、今日改めてやってみたらコンパイルできました。
方法は278のリンク先の内容プラス、bufferoverflowU.libをリンクしたくらい。

DirectX SDK入れようと思うんですけど
WinXP X64用のSDKって出てますか？
32bitのでOK?

SDLをx64向けにmakeしようとしたら
インラインアセンブラ使ってるおかげでエラー吐くね。。。

う〜む、なんでインラインアセンブラ外したんだ？

前後の最適化で邪魔になるから

まぁ、でも何も選択肢を減らす事もないよなぁ…
これで無駄に移植作業が大変になるんだし・・・。
SDLに関してはそのうち本家でマージされるか、待てないならasmファイルにインライン部分だけ退避してリンクするとか・・・

淫乱部分がないと、VM書いたりスタックいぢりたいとき大変じゃねー？

SDLのインラインアセンブラはCPUID検出用かぁ・・・
コンパイラ標準のに差し替えれればすぐに出来るんじゃないかな

http://www.amd64dev.com/kaihatu/document/30887.html
ここの方法だと、既にあるプロジェクト毎に開いてRelease64を追加しますけど、
あらかじめRelease64を普通のReleaseのように選択出来るように設定する事は出来ないんでしょうか？
プロジェクト変えるたびに設定しなおすのが大変です。

CPUIDなんて直に書くなよ。

__cpuid

どぞ〜

>>289
VSのインストールディレクトリ探し回ると、デフォルトのプロジェクトファイルがあるから
そいつにRelease64を追加すればOK
ただし、こいつはプロジェクトファイル自体に書き込まれる情報なので、先に作成したプロジェクトで選択することは勿論出来ない。

FAQっぽいんだけど、
32ビットと64ビットを判別して、それぞれのEXEをキックしなおすの、どうやってます?

それとも、インストーラで片方のexeしか入れない?

32bitのexeの中に２つのバイナリを格納しておく。

>>293
PEでMach-OのFATみたいなことできるの？

ローダー自作でもしない限り無理じゃないか？
Winは再配置できないし、

最初にロードされる部分が32ビットなら、ずっと32ビットなんじゃないか?
32ビットから64ビットに移行するAPIがあるならともかく。

実行ファイルを作り出して、プロセスを起動。

むぅ・・・
コンソールやライブラリは64bitでコンパイル出来たけど
MFCはダメなのかな？

プロジェクト 'mfctest64'、構成 'Release64|Win32' の中間ファイルおよび出力ファイルを削除しています。
コンパイルしています...
stdafx.cpp
mfctest64Dlg.cpp
C:\Program Files\Microsoft Platform SDK\Include\mfc\AFXV_W32.H(120) : warning C4005: '_WIN32_WINDOWS' : macro redefinition
c:\Documents and Settings\Administrator\My Documents\Visual Studio Projects\mfctest64\stdafx.h(22) : see previous definition of '_WIN32_WINDOWS'
mfctest64.cpp
C:\Program Files\Microsoft Platform SDK\Include\mfc\AFXV_W32.H(120) : warning C4005: '_WIN32_WINDOWS' : macro redefinition
c:\Documents and Settings\Administrator\My Documents\Visual Studio Projects\mfctest64\stdafx.h(22) : see previous definition of '_WIN32_WINDOWS'
Generating Code...
C:\Program Files\Microsoft Platform SDK\Include\mfc\AFXV_W32.H(120) : warning C4005: '_WIN32_WINDOWS' : macro redefinition
c:\Documents and Settings\Administrator\My Documents\Visual Studio Projects\mfctest64\stdafx.h(22) : see previous definition of '_WIN32_WINDOWS'
リソースをコンパイルしています...
リンクしています...
libcmt.lib(crt0.obj) : error LNK2019: unresolved external symbol main referenced in function mainCRTStartup
C:\Documents and Settings\Administrator\My Documents\Visual Studio Projects\mfctest64\Release64/mfctest64.exe : fatal error LNK1120: 1 unresolved externals

ビルドログは "file://c:\Documents and Settings\Administrator\My Documents\Visual Studio Projects\mfctest64\Release64\BuildLog.htm" に保存されました。
mfctest64 - エラー 2、警告 3

>>298
＞プロジェクト 'mfctest64'、構成 'Release64|Win32' の中間ファイルおよび出力ファイルを削除しています。
　　　　　　　　　　　　　　　　　　　　　　　　　　　~~~~~
( ﾟ,_･･ﾟ)ﾌﾞﾌﾞｯ

>>298
リンクに失敗してるだけじゃん。
あともう一息だね！

>>298,300
＞warning C4005: '_WIN32_WINDOWS' : macro redefinition

この警告が出る理由を考えてみれば？

そんなの理由なんてないよ！
あともう一息だね！

理由があるから警告が出るんだよ。

おまえに生きてる理由なんてあるのか？

>>298=300=302=304
必死だな。w
お前が64bitプログラミングに挑戦するのは
珍子の皮が剥けてからでいいと思うよ。
m9(^Д^)ﾌﾟｷﾞｬ―――ｯ

理由が無くても生きていける！

まぁ、一番的外れなのは>>299だけどな。

>>299
そこはコンソールアプリケーションを64bit化した時もなってたので大丈夫だと思います。
単なる名前ですし・・、コンソールはちゃんと64bitバイナリになってましたし。

>>300-301
ありがとうございます。
そこのワーニングの意味を調べてみます。

>>308

>>299が指摘しているのはプロジェクト構成が32bit(Win32)に
なっているってことではないかと思われ。

MFCアプリを64bitでビルドすると 「構成 'Release|x64' 」のようになると思うが。

まぁ、一番馬鹿なのは>>307だけどな。

>>309
VS2003+PSDKな組み合わせだとX64の項目無いからね。
前にちゃんとコンソールで64bitバイナリ吐けたなら、多分そこの設定は間違ってないかと

・WIN64マクロが定義されていない(WIN32マクロのまま)
・MFCの64bitインポートライブラリにリンクしていない

ってのが原因じゃないのかな？

VC6だけど、WIN64マクロにしなくてもうまくビルドできますよ。
ライブラリのディレクトリの設定がまずいのでは？

ｺﾝﾊﾟｲﾗｵﾌﾟｼｮﾝ
/nologo /MTd /Zi /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_MBCS"
/Fp"Debug/aaa.pch" /Yu"stdafx.h" /Fo"Debug/" /Fd"Debug/" /FD /c
ﾘﾝｶｵﾌﾟｼｮﾝ
bufferoverflowu.lib /nologo /subsystem:windows /incremental:yes /pdb:"Debug/aaa.pdb"
/debug /machine:IX86 /out:"Debug/aaa.exe" /machine:amd64

これで、ｴﾗｰ、警告なし。WinDbgでデバッグも出来ます。

>>313
いや、MFCアプリケーションのことを言っている訳で。

>>314
MFCですよ。

>>315
誰もそんな事は聞いてない
帰りたまえ

>>313
MFCのReleaseビルドはうまくいくんですが、Debugビルドだと
実行時にMFC42D.DLLがないというダイアログが出てきてしまいます。
どうやってデバッグしているんですか？

愛と勇気で

>>317
ｽﾀﾃｨｯｸﾗｲﾌﾞﾗﾘをリンクするようにすればいいとおもいます。
VC6だったら、プロジェクトの設定の一般タブでMFCのｽﾀﾃｨｯｸﾗｲﾌﾞﾗﾘを使用を
選択します。

Microsoft Platform SDK\NoRedist\Win64\AMD64にMFC42d.dll他があるのですが
それを使うとうちでは保護例外が出てうまくいかないです。

う〜む、すいません。
どうしてもMFCだけmake出来ないんですが
IDEの設定はこんな感じです。
何かありましたら指摘お願いします。

ttp://sylphys.ddo.jp/upld2nd/pc/img-box/img20050501141621.jpg

Visual Studio 2005 Beta 2 を使いましょう。

　　　　　　----- 終了 -----

なんか変なのが住み着いたな。
2005じゃ配布出来ないだろう。

>>320
設定はそれで良いと思うけど、参照の項目が変じゃないか？

>>322
Beta2からGo-Liveライセンスが適用されるようだが？

ttp://www.microsoft.com/japan/msdn/vstudio/2005/golive/default.aspx

Visual Studio 2005 Beta 2は今すぐだとMSDN入ってないと入手できないからねー。
申し込みでのCD送付は6月予定だし、CD付属雑誌の発売も早くて5月中旬だったかな？
どのみち、アホはスルーで。

なんか265のPSDKのISOインストールしたんだけど、それからというもの
Windows起動時に毎回Setup Wizardが出てくるようになったんだけど、自分だけ？
スタートアップフォルダも、レジストリのRunにも登録されてなさそうなんだけど…。

実はインストールしたと思いこんでいるだけで
Setupをまだしてないとか

>>320
その設定で>>298のエラー出るのは変
なんか、コンパイラオプション間違ってないか？
変なもんリンクしたとか・・・

公開されているpsdkのmfcは、バージョン4.2にしか対応していないんじゃないの？
psdkのライブラリ見ていたらそんな感じがしたんだけど。

http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/vccore/html/vcconmfcvisualcversionnumbers.asp

x64版Windows向けのCgコンパイラって出ないのかな？
nVIDIAってAMD64推進派っぽいし、もう直ぐでそうだけど・・・
Linux版は確かあったよね？

hgjklkl

すいません、リンクをクリックしたら色が変わりますが、
あの色を変えないようにするスタイルシートを教えて下さい。
ほんっとどんな単語で検索していくら探しても見つからないんです。

>>331
板違いだ。W3C逝け間抜け。

#include <windows.h>
#include <stdio.h>

WORD addr1[] = {0, 0, 0x0033};
__int64 a = 0;

__declspec(naked) void aaa(void)
{
_asm
{
movebx, offset a
movecx, offset addr2
}
//movr8, 1
_asm _emit 0x49 _asm _emit 0xc7 _asm _emit 0xc0
_asm _emit 0x01 _asm _emit 0x00 _asm _emit 0x00 _asm _emit 0x00
//negr8
_asm _emit 0x49 _asm _emit 0xf7 _asm _emit 0xd8
//mov[rbx], r08
_asm _emit 0x4c _asm _emit 0x89 _asm _emit 0x03
_asm retf

}

int main(void)
{
*(DWORD *)addr1 = aaa;

printf("a = %I64d\n", a);

_asm
{
call fword ptr addr1
}

printf("a = %I64d\n", a);

return 0;
}

↑WOW64上のWin32から64bitモードに切り替えることが
出来るみたいなんだけど、何かに使えない？

>>335
スペースが削られているところがあって、なんじゃらほいとおもったけど。
何も役に立たないんじゃないの？

MFCの64bit化まだ〜？
このスレでも既出だけどVS2003で使えなくて困ってる。
2005買えって事なのかな？

俺もMFC使えんと話にならんから64bit化は遊びでもやってない。
MFCの64bitソースはあるのに使えないとかMSは何考えてるんだ？2005買わせるための作戦か？

32ビットアプリも動くんだから
わざわざ64ビットで作る必要もない。

そんな事言ってると、Win98時代くらいまでだったら、16bitアプリも動くんだから、わざわざ32bitアプリを作る必要もない
って言ってるのと変わらんて。
64bit上で動かす限り、ネイティブなアプリケーションを開発しようとするのは自然なこと。

そもそも、ここが64bitプログラミングスレだと分かってて書いてるのか？

64ビットアプリから
Win32API を使うことはできますか？

>>340
Windowsの16ビットと32ビットは、天と地ほどの差があるんですけど・・・。

それに比べて、32ビットと64ビットは、
普通にコーディングしていれば、
速度と確保できるメモリの大きさくらいの違いしかないよな。

少なくとも、このスレ的には
x86の64bitモードの、レジスタ増加による優位性は明らかですが。

もちろん、たかが10数%程度の速度上昇を伴う程度ですけど。

>>343
プリエンプティブなOSで、その増えたレジスタの待避に時間がかかり、
かえって遅くなる事もある。x86は近頃のCPUにしては設計が古い
のでレジスタが少なく、コンテキスト切り替えに有利だった。

それにしてもFPUを使えなくして、SSE命令を強制的に使わせよう
とする糞OSは何とかして欲しい。

レジスタが増えたことによるメモリアクセスの減少数に比べたら、
コンテキストスイッチうんぬんなんて、まったく問題にならないと思うけど。

>>345
32bitアプリを動かすならコンテキストスイッチングのオーバーヘッドは問題に
なるかもしれんが、64bitアプリなら初めから関係ないね。というか、仮想32
みたいなモードを使っているのなら、32bitでも遅くならないはず。

あんな古臭い糞FPUはｲﾗﾈ

64bitプログラミング総合スレ

>>344
たまにその手の知ったか発言をするアフォが痛い
その程度のコンテキスト切り替えオーバーヘッドが問題になるってどんなCPUだ

とりあえず、遅くなるって言ってるヤツは実際に適当な32bitのソースを64bitに変換してmakeしてみなよ。
理論云々言っても、実際に殆どの場合速くなるんだからしょうがない。
自前のエンコード・デコードのルーチンを試しに64bit化したら、単にコンパイルしただけなのに偉い事になった。

>>350
どんなコーデックだい? 整数主体? 実数主体?
教えて呉呉

とりあえずzlibは２倍程度のパフォーマンスだと
どこかで見たような。

Cygwin-binutilsあたりが64ビット対応になるのを待ってたが
(Current追いかけても)まだ対応する気配がないので
諦めてMS純正のSDK入手することにしよう…

>>344
それはどういうOSで?

Windowsだと、パフォーマンスカウンタにコンテキストスイッチの回数が出てるけど、
大した回数じゃなかったような希ガス。

1秒間に数万回。

32ビットレジスタを128本退避したって、512バイト x 数万 = 10〜15MB/secだよ。

>>354
HP-UNIX(ハイパープリエンプティブ・UNIX)。
一秒に一億回のコンテキストスイッチング。

して、それはx86で動いてるの？
さらに、x86-64でも動かす予定があるの？

>>344
> x86は近頃のCPUにしては設計が古いのでレジスタが少なく、
> コンテキスト切り替えに有利だった。

そうでもない。レジスタ数は少ないが、アドレス空間切替時に
TLB を全て flush する必要がある点は、その後にデザインされた
RISC CPU や Itanium より不利。
実際、最も新しく設計された Itanium があれだけ大量のレジスタ
を積んでるところを見ると、x86_64 程度のレジスタの増加は、
いまどきたいしたオーバーヘッドではないと思われ。

> それにしてもFPUを使えなくして、SSE命令を強制的に使わせよう
> とする糞OSは何とかして欲しい。

FPU がスタックマシン的命令セットになっていることが、
x86 の浮動少数点演算の性能の足を引っ張ってることは周知の
事実。

>>356
>>355は明らかにネタ

>>352
あのzlibはAMDが配布したもので、疑惑があるらしい。
http://www.x86-secret.com/index.php?option=newsd&nid=837

64ビットでプログラミングしてみたが、あまり変わらん・・・・
当たり前かｗ

__int64をサポートした32ビット環境を使ってると、代わり映えはしないね。

>>357
Itaniumのレジスタは、実質的には32本です。
レジスタというよりは、スタック専用キャッシュみたいなものです。

>>355
聞いたことないOSだな。

>>358
ttp://www.zlib.net/zlib122.zipのソースからminigzipとzlibをコンパイル。
minigzip -9で260MBのファイルを圧縮。その時間（3回やって1番いいタイム）を計測。
実行環境はWinXP x64 + Op246 + Atlas10K5

・VC6.0 SP6のcl(Version 12.00.8804 for 80x86)
　最適化ｵﾌﾟｼｮﾝ -O2　35秒
　ｵﾌﾟｼｮﾝ ﾅｼ　73秒

・icl(32-bit applications, Version 8.1 Build 20050405Z)
　ｵﾌﾟｼｮﾝ -Qipo -O3 -QxW　32秒

・psdk April 2005のcl(Version 14.00.40310.41 for AMD64)
　ｵﾌﾟｼｮﾝ -O2　36秒

・icl(Intel(R) EM64T-based applications, Version 8.1　Build 20050406）
　ｵﾌﾟｼｮﾝ -Qipo -O3 -QxW　31秒

> Itaniumのレジスタは、実質的には32本です。
> レジスタというよりは、スタック専用キャッシュみたいなものです。

そうだけど、コンテキストスイッチの際には、使ってる分は
退避する必要があるので、最大128個の64ビットレジスタを
セーブすることになる可能性があるよ。つまり最悪IA32の
32倍のメモリ帯域を汎用レジスタのセーブのために必要とする
可能性がある。
レジスタウィンドウを全く消費してないなんてことを、まず
ありえないけど、もしそうだとしても、32本はx86_64の倍だし。

UNIX系OS上でのベンチマークだけど、ここ見ると同じマシンで、
x86_64の方がIA32よりも、たいがい速い。
ttp://www.nagoya.bug.gr.jp/~oshima/netbsd/bytebench/index.html
たまに遅いのがあるけど。

あと、どうもgccだとNetBurstはてんで遅いっぽいね。

gccにAMDのスタッフが参加してるので、gccはAMD寄りに最適化されてる。
インテルコンパイラはIntel向けに最適化されてるとは言え、AMDのCPUも含めて殆どの場合速い結果を出す。

個人的にはgccもインテルの人に参加してもらいたかった。

> gccにAMDのスタッフが参加してる

x86_64への移植に関して援助しただけで、コアの部分に
はタッチしてないでしょ。
gcc って、そもそも最適化はイマイチだし。

こういう差がでる本当の理由は、NetBurstがクロック命の
設計になってるため、分岐その他のペナルティが大きすぎ、
コンパイラが頑張らないと性能が出ないせいだと思うな。
Athlon 64 の方は最適化で頑張らなくてもそこそこの
性能が出るので、こういうことになる。実際、gcc でも
Pentium-M だと、クロック比でいい性能出るしね。

>>361
EM64T-based applications, Version 8.1で、-QxWなしをｷﾎﾞﾝ

I社の人からx86->x64の性能向上の理由として関数引数がスタックから
レジスタ渡しになった事が原因の一つと聞いたことがある。

あんだけあれば普通の呼び出しは全部レジスタに乗るよなあ

>>335
まったくでたらめな使い方だけど、どうやらWOW64上のアプリでも
コンテキストスイッチの際、拡張レジスタを保存してくれるみたい。

AviUtilのプラグインを高速化できそうな気がする。
本体が64bit化してくれればそれに越したことはないけど。

>>365
けど、Intelコンパイラだと、Netburstでも速くなって
その上AMDのCPUでも、更に速くなるんだぞ。
根本的にgccの設計が悪いんだと思うねぇ・・・

すんません。
VS2005 + .NET Framework SDKの64bitで.NETアプリの64bit化をしようと思ったんだけど
普通にパス通すと、PSDK 64bit版のcl.exeが不正終了しません？
何ででしょうか・・・
誰か.NETアプリの64bit化に成功した人居ませんか？

>>362
コンテキストスイッチは重くなるけど、

全レジスタを退避したとして、
65bit x 127本 + 82bit x 126本 + 1bit x 63 + 64bit x 128(?)本 + 64bit x 9本 + 38bit + 6bit
= 27,462bit = 約3.4KB

コンテキストスイッチがDB等で多目として秒間10万回なら約340MB/secですか。デカい。

とはいえ、本来はスタックに書き込む分が遅延していると考えれば、
パイプラインが止まる時間だけが問題なわけだけど、強力なキャッシュで速やかに・・・なのかな。

gccはさすがに時代遅れだと思う。

多くのCPUに容易に対応できる点は非常にありがたいけど、
コンパイラも含めてCPU性能を考えコンパイラの比重を増やすという流れには合わない。

NetBurstはまだいいほうよ。
gccが出力するIA-64のバイナリなんて、悲惨どころの騒ぎじゃないからね。

>>372
DBで秒間10万回コンテキストスイッチってあまりないような。
ハイエンドDBは、非同期APIを使ってシングルスレッドで
組んであるので、コンテキストスイッチはむしろ少なめでは？
それに大量にコンテキストスイッチするようなアプリでは、
関数呼びだしのレベルも低いだろうし、浮動少数点演算なんて
そもそも使わないから、全レジスタ退避はさすがにないよ。

>>370
つまりIntelコンパイラは最適化が効いてるってことでしょ。
NetBurstとかAthlon 64とかといった、マイクロアーキテクチャ
に依存した最適化どころじゃなくて、マイクロアーキテクチャに
依存しないようなレベルの最適化でも、gccは劣ってるってこと。
そういう場合でもAthlon 64ならそこそこの性能は出るんだけど、
NetBurstは本当に駄目駄目になるみたいね。
byte benchmark のうち、Dhrystoneあたり(古い)ならWindows上
でも動くんだけど、VC++だと、どんな傾向になるんだろう。

>>374
15年くらいまえ(m68kの頃)だと、gccは神の最適化と呼ばれてた
こともあったんだけどねえ。その後の最適化エンジンの改良が
遅れてるのが痛い。gccの開発者もその辺は分かっててなんとか
しようとはしてるみたいだけどね。

>>362
コンテクスト・スイッチもさりながら、
例外処理やunwind-protectのための状態退避のコストが大きくなりそうな気が
するんだけどどうだろう。

>>372
コンテキストスイッチの際って、生真面目に全物理レジスタを待避すんの？
そもそも、ソフトウェアから物理レジスタにアクセスできんの？

>>366
QxWありなしとでは、ほとんど変わりませんでしたよ。

gccが遅いのは、クロスコンパイルを可能にするために、特定のCPUに
チューンしてないからだという記事をどこかで読んだ。gcc4.0.0のリリース時
にgnuの人がどこかで語ってた記憶がある。

>>372
あ、もしかして、それはIteniumの話をしてたの？
x64の話かとおもって377を書いたわけだけど。

レジスタ・ウィンドゥを装備して、コンテクスト・スイッチング時の転送量を
極力減らしているCPUも多いな。

>>381
待て待て。レジスタウインドは、コンテキストスイッチングの為にある
わけじゃないぞ。よく考えてみろ。

>>369
64bitコード内では問題ないんだけど、Compatibleモードに戻してから
APIやCRTのエピローグルーチンを実行すると、保護例外が発生する。
何が問題なんだろ？ちゃんと動いてる？

>>383
R8-R15を使っているなら、使う前にそれらを退避しないといけませんよ。
拡張レジスタはWOW64で使われていますから。

>>374
DBってコンテキストスイッチ少ないのか・・・。
同期処理の塊で、ロック競合でパフォーマンス落ちまくるって聞いたもんで。
ってそれはDB上のオブジェクトのロックの話か・・・頭がこんがらがってました。

>>380
IA-64です。

数えてみてびっくりですよ、レジスタだけで3.4KBもあるなんて化け物。
486のキャッシュは4KBだったわけで、それが今ではレジスタ扱い。

しかし実際にはドンガメ・・・orz

今は
8086の全主記憶分がL2に載り、Z80の全主記憶分がL1に載り
ビデオメモリがWindowsが楽々動作する量になっている
そんな時代ですよ。

>>386
それでも遅いと不満を鳴らす俺がここにいる。
Windowsそのものが重すぎるんだなきっと。

>>384
Thx.
うまくいった。

>>388
いますぐ試せないから聞いてしまうけど
この手法って32ビットWindowsでも有効なの?

>>389
>>335

>>388
64bitコード部分は>>333のようにハンドアセンブルしているの？

つーか、大丈夫なのかい？　こんなことして。

>>391
yasm使えばいい。x64命令に対応かつWin32なオブジェクトを吐いてくれる。

大丈夫かどうかなんか分かるない。
偶然動いているだけかもしれないし。

試すまでもなく、ドキュメントを読みあさってみたら、
REXの上位32ビットの値がいろんな場面で壊れうることがわかったので、
いつぞや誰かがカーネルモードでやったように、
資源を独占しないとできなさそうだということがわかった。

WOW64上でできるのであれば、x64 Windows をインスコしてもらう
必要があるけど、どうにかR8以上を扱い、かつ64ビット演算ができる


…という解釈でいいの? まだ試せる状態にないよ…

WOW64限定ということは、x64 Edition限定ってことしょ？
こんな怪しい方法で64bitコード実行するより、普通にWin64で作ればいいじゃん。

>>393
xmm8〜も使えるよ。xmmレジスタについては特に制限はないみたい。

>>394
その通りだけど、Win32アプリのプラグイン等の高速化に使えるのではないかと。
簡単なAviutlのフィルタプラグインを作ってみたよ。

Windowsで64bitのソフトを作りたいのですが、何が必要ですか？

やる気

熱気

>>396
64bitモード時、アラート状態でAPCが発生しても大丈夫なの？
あと↑でAPI呼び出しは当然無理だよね？

>>334
どうでもいいけど
＞*(DWORD *)addr1 = aaa;
これは無理だr

>>400
拡張子cppで保存しているからじゃないの？
VC6だったら警告は出るけど、コンパイルリンクは出来る。

それよりもaddr2がない。書き忘れか？

>>400-401
のプログラムだと、1度目は0、2度目のモード変更後では-1になる。

>>399
SleepEx()など呼んで制御がシステムに移っている間アラートになるわけででしょ？
特に問題はないと思う。

timerSetEvent()はどうですかね？
64bitコード実行中にちょうどコールバックが呼ばれるようにして

>>404
他のスレッドに影響はないので問題はないと思う。
実際やってみたけど、不具合はなかったよ。

size_tのサイズって何を基準に決めるの？
4byteままでいいじゃん

それじゃ4G以上のサイズ表現できねぇじゃん

べつにいいじゃん

サイズ固定でいいならそもそもsize_tを使う必要がない

smbclientで4G以上のファイルが送れませんでした
氏ね

質問です。
VC++にx86-64のコンパイラを含んだPSDKを入れて組んだコード内の構造体のサイズはどのようになるのでしょうか？
今までどおり4の倍数なのでしょうか？

構造体内のアライメントの話?

それならコンパライのオプションや#pragma packで変わるよ。

int型は64ビットになるのですか？

プラットフォームとコンパイラによります。

>>413
とりあえずVCではintもlongも32ビットのまま。
INT_PTRの類は64ビット化される。
long longなどもそのまま64ビット。

知ったか様が降臨しました！！！

>>416
おいでませ〜

知ったか様、知ったか様、
いらっしゃりましたらおいでください・・

>>416
えっ？どこどこ？
>>412 の
>コンパライのオプション
これ？

紺払い

doubleについてはどうですか？やはり32ビットのままなのでしょうか？

floatについてはどうですか？やはり64ビットのままなのでしょうか？

>>421-422
それぐらいsizeof()で調べようよ・・・

わからないなら黙っていて下さい。

shortについてはどうですか？やはり16ビットのままなのでしょうか？

VCではそうだよ。

floatが64ビットって何やねん

C言語の変数は型によってビット長が特に決まっていないから
64bitのfloatがあってもおかしくはない。

CRAYがshortもfloatも64bitと昔聞いたことがある

doubleが32ビットには突っ込まないのな。
floatが64ってのはあのボケを見て書いたんだと理解したんだが

doubleが32ビットでもおかしくないが
sizeof(double) >= sizoef(float)は決まっている

>>421と>>422は別個のネタだろ

でもぶっちゃけ、IEEE754が圧倒的に多い。
そしたら、float = 32ビット、 double = 64ビットになるでしょ。

intやlongのサイズが違うかもしれないのとは、遭遇頻度が全然違うと思う。
とはいえ、sizeofを使わずにハードコーディングしたり、キャストするのはお薦めしない。

64bit環境で試すコンパイラ - アセンブルコードに見るその実力
大原雄介
http://pcweb.mycom.co.jp/special/2005/compiler/

O原 gj! 続編書けや。

>>429
調べたら、charとlong double以外は全部64bitだったｗ

>>434
性能向上比のグラフとか、いろいろ間違っているんじゃないか？

>>434
アホだ・・・

ヒートシンクの横にファンを置いただけじゃダメに決まってる。
ちゃんと風洞つけて、ヒートシンクの隙間を空気が流れるようにしなきゃ。

ところで、MSDNのライセンスに、ベンチマーク結果を公開するな、というようなことが書かれてたと思うのだが・・・。

というか、あんな記事を一般人に見せて何の役に立つのか。

ベンチマーク禁止はベータ版やサーバ系ではなかったかな?

winuser.hの
#ifdef _WIN64

#undef GWL_WNDPROC
#undef GWL_HINSTANCE
#undef GWL_HWNDPARENT
#undef GWL_USERDATA

#endif /* _WIN64 */

#ifdef _WIN64

#undef GCL_MENUNAME
#undef GCL_HBRBACKGROUND
#undef GCL_HCURSOR
#undef GCL_HICON
#undef GCL_HMODULE
#undef GCL_WNDPROC
#undef GCL_HICONSM

#endif /* _WIN64 */

この辺めっちゃ困るよ。
(HINSTANCE)GetWindowLong(SDL_Window, GWL_HINSTANCE),
とか既存のWin32アプリのリコンパイルで障害でまくり・・・
なんで、こんな事してるんだろ？これじゃWin64にコンパイルしなおせないジャン。。。

>>440
だってハンドルやポインタは64ビット。
GetWindowLongで32ビットに切り詰めた値を返されても困るでしょ。

なるほど・・・
そういえばそうだな。
GetWindowLongPtr 使えって事か・・・

しかし GetWindowLongPtr の Win32 での定義が腐ってるので
結局 #ifdef で分岐しなくてはならない罠。
最新の Platform SDK では修正されてたりしますか?

AtlWin.hかなんかでインライン関数として書かれている。

ネイティブのmp3プレーヤー作ろうと思ったが、MCIコマンドがうまく動いてくれない。
おかしいなあと思ってデバイス一覧取得してみたら・・
　mpegvideo　が無かった　orz

同じソースをwin32でコンパイル後デバイス一覧取得すると mpegvideoが出てくるし
コマンド送るとちゃんと動作する・・
ってことは単純に64bitのmpegvideデバイスが無いってことかな？？？

x64のmpegvideoデバイス・・どこかに無いかなあ

MCIデバイスドライバも32ビットDLLだからそりゃx64のexeからは使えないわな
MCIはlegacyだからDirectMusicとか使えってことかな

かなりの互換性問題は、
EXEとDLLはビット数を同じにしなければならない
で説明できちゃうんだよね・・・。

というか、64bit 環境でも MCI まだ実装してる事実に驚いた。

そのためのCOMですよ

Directshow SDK をダウンロードしてきて動かしてみたけど、
やっぱり64bitネイティブだと mp3再生ができない　　orz

32bitだったら問題なく再生できるので、64bitデバイスが出るまで待つしかないのか・・

グローバルフックがたるい

Windows Media Playerも32ビット版だけか。
(64ビット版があったとしてもCodecが全然なくて役に立たないだろうけど)
本気で64ビットアプリからはmp3鳴らせないみたいだねえ

作れ

>>453
下のMP3ソースコードを64bitでコンパイルしたが漏れの実力では動かせなかった orz

ttp://www5c.biglobe.ne.jp/~atsu/mp3/mp3.htm

>>454
これつかったら？

http://www.fmod.org/

>>455
だめだ
warning LNK4248: 未解決の typeref トークン (0100001A) ('FMUSIC_MODULE') です。
というエラーが出る。
どうしていいかわかんねー

環境：vs2005Β2＋Win64　+fmod64vc.lib

#include "fmod.h"

private: System::Void buttonPlay_Click(System::Object^ sender, System::EventArgs^ e) {
FMUSIC_MODULE *mod = NULL;
}
　コードはこれだけなんだけど・・

マネージ?

SDLの64bit版が出ないので、色々やり難いなぁ・・・
インラインアセンブラが廃止になったので移植がやりにくいんだろうけど・・・
俺外部にアセンブラ出すのやった事ないし・・・

マネージド コードに64bitと32bitで違いあったっけ?

ttp://www.exconn.net/Blogs/team01/archive/2005/06/01/481.aspx

v2.0 の Managed Resource でも x86, x64, IA64 それぞれの Managed Program 中に入っている Managed Resource には互換性がありません。

>>456
サンプルもコンパイルできないの？
sampleにある.dspファイルからVSを立ち上げて、プラットフォームをx64
リンクするモジュールをfmodvc.libからfmod64vc.libに変えるだけで
問題なくコンパイルできる。

こっちは英語版のVC2005 Beta2だけど。

>>461
情報ありがとう。
日本語版で試して見た。ワーニングを無視して
リンクモジュールの変更/DLLを配下にコピーでちゃんと動いた。

タスクマネージャーで確認して見たが、ちゃんとx64で動いている。
どうもありがとう。

配下とか押下とかアベンドとかそういう単語をそろそろ捨てないか?

アベンドは便利だから残して欲しい

アベンド2回で某超巨大企業T出入り禁止と聞いて1日も早く
脱出したかったオレは何とか2回起こす方法を
考えたがクライアント側担当ではどうあがいてもムリと悟って(ry

http://pcweb.mycom.co.jp/special/2005/compiler/

>>466
>>434

>>445
なんかsysWOW64だけじゃなくてsystem32にもmciqtz32.dllがあるなあ。
Dependency Walkerで覗いてみたけど間違いなく64ビットバイナリみたい。
MPEGVideoとして登録さえすれば使えるのかな?
つーかmci*.drvまであるが16ビットサポートを廃止したのにいったい何に使うんだ

mciqtzにはmp3デコーダ含んでいないし。

/noexecute=OptIn(XP x64のデフォルト)だと64ビットアプリまで保護から外れる
みたいだけどそういう仕様なの?
/noexecute=OptOutのとき64ビットアプリを例外に追加することはできないのに。

AMD64版のPlatform SDKについてくるDependency Walkerがファイルシステム
リダイレクションを考慮してなくて、32ビットのDLLをまともに表示できない。
もう1GB使ってx86版のSDKも入れろとおっしゃいますかそうですか

つ[NTFSの圧縮属性]

FPU使えないとしたら、指数関数や三角関数はどうやって計算するんだろう。
計算するコードを用意しないといけないの？
FPUにあってSSEにない機能がけっこうあるからな。

>>473
pgr

マックにＩＮＴＥＬのＣＰＵが乗るということで、
ＩＡ−６４について調べています。
情報源などありましたら、よろしくお願いします。

x87のFSINCOSとかスループット130とかだし
内部的にはテイラー展開してんのかな？

>>475
Mac に載るのは IA32 だよ。つまり、最初のバージョンは32bitに逆戻りする。
そのうち x86_64 にも対応して 64bit 化するだろうけど。
IA64 (Itanium) は載らんだろ。

>>477
意外とItanium2載せて、多量消費効果により、Itanium2の値段が下がったりな。
Windowsではx86-64が主流なのでもう遅いけど。

Mac程度の台数じゃなあ。

>>476 CORDIC、sincosなんて典型的

じゃあ64bitアプリでsinとか使うときは必ず長いコードを書く（コピペする）の？
速度的にはよくてもアセンブラできれいに書けないなあ。

>>481
マクロアセンブラって知ってる？ｗ

あー、そういえば、MacこそIA64向けの絶好の市場かもな
どちらにせよ互換性の問題は発生するわけだから、どうせならIA64にしてしまっても問題ないわけで・・・
けど、乗るのはPenM系みたいだからIA64を乗せるのは大変だろうけどｗ
Pen4系だったら、内部は殆どソフトウェアで簡単に仕様変更が出来るらしいけどね。

まさかとは思うが、マック用に新たなチップを起こすとか考えてる？

>>483
IA64って本当に速いのかなぁ。実は失敗作だったりしない？

現状はスピードをカバーするために無理矢理大きな物量（キャッシュ容量など）を
注ぎ込んでいる気がするんだけど。IA32と同じような規模のCPUを作っても性能
出ないんじゃないかなぁ。

>>485
コンパイラとＸ86互換の問題が有るんでぇ、それさえ解決したら早いよ。
てか、インテルはＩｔｕｎｉｕｍから、下位互換を全て抹消するべきだよ。
持ってても意味無いし。

>>485
単純に以前の32bitを切り捨てるくらいの勢いで作ったけど
互換性についての市場の要望があまりに強かったから、とりあえずx86エミュレーター積んどこう
くらいのノリでやったら、過去の資産が鈍足になっちまっただけで、64bitネイティブだと普通に速い。

とにかく、Ｉｎｔｅｌさんはマック用に最高のＣＰＵを作ってもらいたいね。
ウィンが真っ青になるぐらいの（笑）

自分で自分の首を絞めろとｗ

なんつーかPentium Proの二の舞

>>487
普通に速いと言ってもFPだけで、シングルスレッドの
整数演算性能だと、P4 や Athlon 64 より遅いよ。

Mac が x86 に移ったのは、PowerPC系でノートPCに
使えるCPUがないせいだから、IA64はありえないだろう
ね。ノート用IA64なんて、いくらインテルが酔狂でも
作らないだろう。

＞整数演算性能だと、P4 や Athlon 64 より遅いよ。

まず64bitと32bitでどう比較したのかしらんが
Itaniumは整数演算が速くて、浮動小数点演算が遅いのだよ？(そのつもりで設計されてる)
多分得意分野を逆に記憶してるか、32bitエミュレーションでの比較を勘違いしてないか？

マックに使うときまでには解消しているはずですよね〜☆

>>492
なんか勘違いしてるのは君の方だと思うけど。

純粋なCPU性能のベンチマークとして、たぶん一番信用されている
SPEC の CINT2000 (整数性能) と CFP2000 (浮動小数点性能) を
http://www.spec.org/cpu2000/results/
から引用してみようか。値は PEAK 値の方ね。

CINT CFP  CPU
1854 1878 Athlon 64 FX-55
1815 1984 Pentium 4 3.8GHz/L2 2MB
1590 2712 Itanium 2 1.6GHz/9MB

ほらね。Itanium 2 は整数で遅くて、浮動小数点で速いでしょ。
実際、もし浮動小数点で Pentium 4 の方が速かったら、
ハイパーフォマンス・コンピューティング用クラスタの CPU に
Itanium が使われるわけがない。HPC クラスタは、浮動小数点
性能が命なんだから、値段が高くて遅かったら Itanium なんて
使わないよ。

Itanium2だからじゃないの？
Itaniumはブランチ演算3個、整数演算4個、浮動小数点演算2個の構成だから、整数演算に重点が置かれてるとおもうけど・・

ま、どにらにせよItaniumがどうであろうと、それがIA64の特徴にはならないと思うけどね。

> Itanium2だからじゃないの？

いいや。Itanium はクロックが低すぎて、Itanium 2 よりさらに遅いよ。
(後から出た Itanium 2 の方が性能がいいのは当たり前)
いくら演算器が沢山あっても、クロックが遅ければ勝てんよ。
Itanium の登場から現在までで、整数演算性能で IA64 が IA32 を
上回ったことは、一度もない。

もし嘘だと思うなら、上の SPEC のページに、1999年Q4 ごとの
時系列での結果もあるから、確認してみたら？

> ま、どにらにせよItaniumがどうであろうと、それがIA64の特徴には
> ならないと思うけどね。

IA64 を実装した CPU は Itanium と Itanium 2 しかないんだから、
この 2 つが IA32 より遅いのなら、それが現時点での IA64 の特徴だよ。

IA64 という命令セット自体に、IA32 より遅くなる要素がないという
意味なら、君の意見は正しいが、それを言ったら、POWER も SPARC も
PA-RISC も MIPS も Alpha も、全て原理的には IA32 よりは速くなるよ。
でも、現実には実装に大量の金を投入できる IA32 が現時点では一番
速いし、だからこそ Mac が (命令セット自体ならむしろ IA32 よりも
高速化の可能性が高い) PowerPC から IA32 に乗り換えるんだろう。

>>494
クロックが違いすぎるぅーーーーーー
もちろん板ちゃんのクロックが引きあがらない問題はあるけども。
SPECだと、PEN４の得意分野だし。

IA64は命令セットの話で
CPUの能力そのものに影響しないわけじゃないけど（そりゃ固定長かどうかとか命令数の量とか重要だけど）
Itaniumのクロックや演算器の数などのCPU自体の演算性能とは何の関係も無いと思われ。

英語が日本語より簡潔だからと言って、日本人より英語圏の人間の方が優れてる事とは関係が薄い事と同じ。
もしこの場に日本語を話す優れたエンジニア2人と、英語を話す普通のエンジニア一人が居たとして
この場には英語を話す人は一人なのだから、それが英語の特徴だ　とかなり無茶な事を言ってるのと同じだと思うが・・・

495が勘違いしてるのは、演算器の数だけを数えてる
点じゃないかな。

ここでは、Athlon 64 や Pentium 4 との相対的な
性能差を問題にしてるんだから、クロックの比、
演算器自体の性能の比などを考慮しないと話になら
ない。それに、いくら演算器が沢山あっても、その
演算器にデータを投入できるだけの命令レベル並列
度がなければ、演算器は遊ぶだけで意味がない。

浮動小数点演算の場合、トランジスタを投入すれば
するほど演算器の性能は上がり、演算に要する
クロック数を短縮できるし、実際、Itanium 2 の
浮動小数点演算器は、Athlon 64 や Pentium 4 より
優秀なんだろう。

これに対し、整数演算は乗除算などの一部の例外を
除き、ほぼ全て1クロックで実行できるので、
Athlon 64 や Pentium 4 と Itanium の間に、整数
演算器の性能差はないだろう。

Itanium 2 1.6GHz が Pentium 4 3.8GHz と同等の
整数演算性能を出すためには、3.8/1.6 ≒ 2.38 倍、
IPC で勝っている必要がある。だが、たとえ EPIC
でも、現時点で 2.38 倍の IPC を達成できてない
ってことだね。

まず64bitと32bitでどう比較したのかしらんが
Itaniumは整数演算が速くて、浮動小数点演算が遅いのだよ？(そのつもりで設計されてる)
多分得意分野を逆に記憶してるか、32bitエミュレーションでの比較を勘違いしてないか？

というか、マックには最強のCPUを搭載してほしいんですけど。

要望だけなら、誰でもできるわな。

>>500
設計がどうだろうと、実測で Pen4 や Athlon 64 に負けてるだろ。
整数演算で Pen4 や Athlon 64 よりいい結果を出すベンチマーク結果を示してみろよ。

負けてるって、浮動小数点演算能力は無視かよｗ
整数だと数パーセント負けてるが、浮動小数点なら倍勝ってるんだぞ。

投入している物量（特にキャッシュ容量）を考えると物足りない性能
なのは確かだと思うなぁ。＞IA64

割算もちゃんとできないのか。面白い奴だな。
>>494 のベンチで Pentium 4 と比べてみようか。

> 整数だと数パーセント負けてるが

1590/1815=0.88
整数で負けてるのは数パーセントじゃなくて、12% だね。

> 浮動小数点なら倍勝ってるんだぞ。

2712/1984=1.37
倍勝ってるんじゃなくて、37%勝ってるだけだね。

Pen4 を使った PC と Itanium を使ったマシンの価格差は37%どころ
じゃないから、価格性能比で見ると、浮動小数点でも負けてますな。

Macな人が、Ituniumを貶そうとしてるの？
Ituniumは良くも悪くも（悪くの部分が大きくなってるけど）実験中だからねー。
Ituniumの現在スペックを持って糞というのは、言えるけど言っても仕方ない
事で。

1.8GHZのクロックで、何が出来て何が出来なくて、これをどうすればどうなる？
てな議論が欲しいCPUなのでねー。

Itunium って何よ？

>>507
>Macな人が、Ituniumを貶そうとしてるの？

何でそうなるんだよ…
ｲﾀが好きなら、スペルくらいちゃんと書いてやれ

ずいぶんと「実験中」が長いよね。正直期待していたのだが・・・・

その成果がマックに！
ということで期待大！！！

ﾏｸユーザを騙るのは止めてくれ

>>510
中に浮いちゃったよぉおね。

残念だけど、駄目かもって感じ。

クロック 1.6GHz しかないのに、Pen4 3.8 GHz と、まあ同等の
性能が出てるわけだから、これでクロックが Pen4 並とはいか
なくても、せめて Athlon 64 なみに速くなればねえ…

やっぱり大量生産を見込んで大量にお金をつぎこまない限り、
クロックは上げられないのか。 (´･ω･`) ｼｮﾎﾞｰﾝ

>>508
iTunes に最適化されたプロセッサ。

CPU が統一されるのは良い事だ
不幸なのは、それが x86 という事……

おもちゃみたいなPowerPCに統一されても、どもならんし
PowerやItanium2は、話にならんしなあ

appleはPentium Mあたりが欲しいだけだろ

インテルさんは、最高のＣＰＵをアップルに提供すると約束したんでしょ。
だからアップルは採用したの。
ＰｅｎｔｉｕｍＭだかなんだから知らないけど、最高であることは
間違いないわけだし、心配しなくていいんじゃないかな。
ウィンな人たちが悔しがっても、し〜らないっと。

最高のCPUをAppleにだけ供給するとか
Mac板でも、そういうありえん妄想してる奴が多いな
もうすっかりintel insideに順応してしまったようで
ウォッチしててもつまらなくなってしまったｗ

そして、何故か関係ないAMDがたたかれまくりだ

なんつー信仰心だ

今回の件で、MacOSがWindowsベースになっても
ハードとソフトの見た目がMacなら信者はついていくと確信したね

>>522
別に信者じゃないけど、ハードとソフトの見た目がMacなら結構良いじゃん
と思ってしまいました。ｗ

そうだろ、そうだろ
そしてその次の段階は、OSの完全なWindows化
ハードの見た目だけMacになる

なんてな

>>524
なんで >>522 から劣化してんだよw

ついでにプログラマからの見た目もMacになると、ちょっと嬉しい。
.NETからCocoaが呼べるとかね。（爆）

何故っていわれても、そもそもMacはどんどん劣化してるじゃん・・・

WINE が使えるのが嬉しい様な、嬉しくない様な

Macの将来について語るスレはここですか?
>>528
VirtualPCと違って同じデスクトップで動作する可能性があるわけか

マックは６４ビットですし。

質問させて下さい。

http://pcweb.mycom.co.jp/articles/2004/06/23/win64/

↑に、64bitでは32bitアプリでも4GBのメモリを使える
(但しコンパイルの必要あり)と書いてあるのですが、
これは新しいAPIが増えていたりするのでしょうか？

VirtualAllocで仮想メモリを取るテストプログラムをx64 Editionで
実行しても、せいぜい2GBで、2GBの取れない空間が残ります。
取得出来る方法が分かる人いらっしゃったら教えてくださいm(__)m

>>531
VCのリンカで/LARGEADDRESSAWAREを指定する必要がある。
ちなみにこれは元々32bit Windowsでboot.iniの/3GB指定と組み合わせてユーザー仮想アドレス空間を3GBに広げるための物だった。

http://www.marbacka.net/asm64/arkiv/64bit_addressing.html
ここも参考になると思う。

>>532-533
色々調べて/LARGEADDRESSAWAREと/3GBまでは辿りついた所でした。
Thanksです!!
また分からない事があったら質問させてください。

↓で128bitプログラミングのことも話題にしてくれ
http://pc8.2ch.net/test/read.cgi/pcnews/1117523052/

>>535
それだけは勘弁してくれ

PS2のEmotion Engineを128bitCPUと強弁してみる

IA32はi432と同じ運命をたどるのかの?

↑
IA32じゃなくてIA64の間違い

これか。

http://en.wikipedia.org/wiki/Intel_iAPX_432

http://en.wikipedia.org/wiki/Intel_i860
http://en.wikipedia.org/wiki/Intel_i960

ここら辺見てると、Intel の裏街道が垣間見えますね。
そして Itanium の将来も……。

Intel も tagged bit とか H/W GC とか、面白そうな事を
やってたんだね。勿体ないなぁ。

AMDもAm2900とかAm29000とか、面白そうな物はあったみたい。
いろいろ研究の結果、一番はやってるIA32を踏襲するが吉と判断したのでせう。

VisualStudio2005 BetaでMFC使っている人いますか？

ターゲットを32bitにしても、なんかクラスの一部が微妙に64bit化
されているみたいなんですが、これって仕様なんですかね？
それとも設定が悪いのかな...。
32bitの時にLONGだったメンバがLONGLONGになっていたりして
微妙にWarningが出るんですよ...。

あとソースの文字列部分で、特定の漢字が入っているとエスケープ
シーケンスと間違って処理されているみたいで、定数が次の行に
続いているぞｺﾞﾙｧと怒られる...＿|￣|○

コンパイル通すだけで一日がかりだ...＿|￣|.....○

managed codeになってるだけとか

結局415kbで済みますた。
http://www.dependencywalker.com/

次はSDK ToolsじゃないけどProcess Explorerのx86版うｐきぼんぬとか
言ってみるテスト
(現在のバージョンで32ビットプロセスのDLLを覗いても、wow64*.dllとか
64ビット版ntdllなどの例外的にマップされてる64ビットDLLしか見えない)

つーか64ビットプロセスが32ビットモジュールを列挙するにはどうしたら
いいんですか? やはり32ビットプロセス立ててプロセス間通信ですか?
32ビット側のntdllにはNtWow64*とかいう怪しげな関数があって64ビット側の
情報も取得できそうな感じなのに。

XP x64 にて、32bitアプリから 64bitアプリのウインドウハンドルは
扱えますか？

他のアプリのウインドウに描画したりメッセージをSendしたり
したいのです。

>>542
それは x64 とか 64bitコンパイラとは別の問題？

こんなのとか、VC6,7から違いありますね。MFCだけの問題じゃないけど。
http://pc8.2ch.net/test/read.cgi/tech/1113305966/150

＞あとソースの文字列部分で、特定の漢字が入っているとエスケープ
＞シーケンスと間違って処理されているみたいで、定数が次の行に

Beta2になって多少マシになったけど、まだ文字化けする

Win32以外のサブシステム以外は絶滅したって聞いてたのに
レジストリにはこっそりposixの指定だけあるのな
SFUを移植する予定があるんだろうか

>>546
Thanks!
VC6.0からの移行だったんだけど、MFCは.netで随分変わったみたいね。
とりあえずx64でコンパイルが通って、実行出来ますた。
32bit版と比べて、1割程度高速になりますた。

>>546
＞32bit版と比べて、1割程度高速になりますた。

１割かあ…。で、x64は_asmできないんでしょ？　SIMD使ってる
ところとか全部Cの代替ルーチンになっちゃうから、この分だと
当面32bitの方が速そうなんだよなあ…

>>549
>>546 →　>>548

インラインだと最適化が阻害される場合もあるし
速度重視ならアセンブラに分離した方がいいよ
クラス扱うのが面倒だが

>>551
＞インラインだと最適化が阻害される場合もあるし

Cのローカル変数名を使えるのは何者にも替えがたい…

＞速度重視ならアセンブラに分離した方がいいよ

それとインラインで明らかに差があるアプリのタイプって例えば
どういうの？

おれの使い方ではインライン（しかも最内側のループ部分だけ_asm）で
１５０％から２００％、モノによってはもっと、その関数のパフォーマンス
あがるんだわ…

それはともかく、分離させればアセンブラで開発可能なの？

>>552
>Cのローカル変数名を使えるのは何者にも替えがたい…
だね。

現状は、MASMを使ってアセンブラ部分を分離すればアセンブラも使える。
ただし、必ずプロシージャコールになっちゃうし、Cの変数は一切見えない。
ついでにMMXとx87の命令は使えないらしい(アセンブルはできるし例外も出ない)。
とりあえず引数はスタックじゃなくて、4つまではレジスタ経由になるから、
32bitの頃より多少はオーバヘッドが少なくてすむけど、inline asmに比べると
やっぱcall分のクロックがどうしても無駄になっちゃうね。

>>553
＞(アセンブルはできるし例外も出ない)。

ごめん意味わかんねっす。アセンブルできて例外も出ないって、
要はMMXが事実上動くってこと？　メーカーやOSが保証して無
いだけなん？

>>554
Windowsがプロセス・スレッド切り替えのときにFPU/MMXレジスタの退避を行わないから事実上使えない。

>>555
了解…

ということはCPUは64bitモードでもMMXが動くんだ…
64bit版LinuxとかだとMMXはOKなのかな？

Win64で_asm駄目MMX駄目だと、ホントにCで組まれた
ぬるいコードしか速くならんのじゃないかね

SSE非対応のOSでもSSEが使えるようなもんだ
立場が逆になっただけで

>>557
意味がわかりませぬ

MMXはFPUと共有(少なくともソフトウェアからはそう見える)だからコンテキストを保存
するためにOSが特別に対応する必要はなかったけど
SSEは対応してないとコンテキストを保存できないんじゃないの?

x64で sizeof(HWND)って、４？　８？

ハンドル類は全部8。
WOW64の都合があるから実際には32ビットで表せる数を超えるハンドルが
同時に作られることはないけど

>>561
ありがと

64bitアプリのハンドルの下位半分を 32bitアプリに渡して
32bitアプリが受け取ったハンドルを操作しても大丈夫？

今まで32bit同士のアプリでやってたのだけど、一方だけ64bit化
したい場合があるかもしれないのです。

勝手にやっちゃまずいだろ・・・

>>563
＞勝手にやっちゃまずいだろ・・・
操作する方もされる方も、自分のアプリです

じゃあ両方64bitにすれば、というのは時間その他の面で
ちょっと簡単じゃないので、おいおいということで。

64bit版でインラインアセンブラを使えなくした意図は何？

たぶんコンパイラの最適化のためではないかと思う。

>>565
激しくわからん。
同じVS2005でも32bit版は使えるわけで、何故使えなくしたのかｻﾊﾟｰﾘ。

そいや、IntelとAMDで64bitの性能差ってあるのかな？
試してみるには、金がかかる...orz

インテル、MSどっちのコンパイラも_asm駄目なんでしょ？
なんか企みはありそうだ。まあ、インテルのコンパイラは
VC互換を売り文句にしてるからかも知れんけど。

MSの.NETを推し進めたい一貫かね。一般人にはネイティブ
のコードなんか触らせねーよ、と

Ｍ＄はクソだな。ＧＣＣマンセー。

C++もついに実行時コンパイルの時代に・・・！

汎用レジスタ16本、XMMレジスタ16本もあれば、普通にコンパイラの最適化に任せておいても
それなりに速度でると思う。
8本が少なすぎた。１６本もあってしかもアウトオブオーダ実行可能だから、そんなに気合入れて最適化
する必要ないと思う。




ところで*mmintrin.hは使えるんだろ？

>>569
そこでmingwのx64版が欲しいんですよ。gccならばりばりインライン可だからね。

>>567
AMDのが速いだろ。構造的に。

IA32用のコードはそのまま別の意味で通るから危険と言えば危険だからある意味正解だとは思うけど
オプションで有効化可能にすればいいんだから確かに怪しいな

Intel IA64との敷居をなくしAMD64下位互換の立場から脱却したい
MS Intel依存から脱却したい 無理矢理.Netに移行させたい

こんな所か

汎用レジスタベースならAMD、XMMレジスタベースならIntelのほうが速かった。

まあ普通にデータ大量に扱う場合はSSE使うわけだが。

>>571
＞8本が少なすぎた。１６本もあってしかもアウトオブオーダ実行可能だから、そんなに気合入れて最適化
＞する必要ないと思う。

インテルコンパイラの自動ベクタライズがほとんど当てにならないと
聞いています。（誰か反例歓迎）

まだまだ局所的な手動最適化にコンパイラの最適化は及ばない
と思う。

Cのコード（コンパイラ最適化あり）に対して、手動でSIMDと
スレッド並列化を書いた場合、３GHｚのマシンが4.5〜５GHｚ
相当で働くこともある。

自動最適化でこれ以上に有利な状況はお目にかかったことが無い。

64bitでコンパイルしなおしたら１割速くなったというのはどこかに書いてあったが、
５割１０割速くなるってのは実体験した人いないでしょ？　IA32でも_asm使えば
現実にそれが起こる。

コンパイラには、人間ができない広域最適化やガイドオプティマイズで
がんばってほしい（もちろん局所最適化もだけど）

そんなに速くしてどうするってのは、議論の腰が折れちゃうので無しね

SIMDに関しては、組み込み関数が
しっかり最適化をしてくれるなら
これの為にアセンブラを使う意義はあまりないと思う。

>>577
VCの組み込み関数ってある？　インテルだけ？

あと、_asmでのSIMD使用と組み込み関数でのSIMD使用を十分
比較した上でほぼ差は無い、とおっしゃっているなら意見として
は貴重。

でも、下手な手動パイプライニングはコンパイラには勝てないけど、
気合入れまくった手動パイプライニングまで含めてSIMDを扱えば、
やはりコンパイラより速いよ。人間がやるとデータの意味と命令の
流れを記述に対して極限まで冗長性を削って加味できるから、
（CPUのアウトオブオーダーがあったとしても）もう一皮むける
というのがオレの感触。

とはいえそろそろスレ違いだな

http://pc8.2ch.net/test/read.cgi/tech/1103609337/218

__asmで1700clk、インライン関数で1700〜2300clk。
単純な処理なので元々人間有利なコード。
簡単すぎる処理なので何ともいえないが。

どっちにしろ、可読性とスピードのトレードオフ。
個人的にはインライン廃止で不便なことこの上ない。

コンパイラの出力も参考にできるし
好きなだけ時間かけられるなら
コンパイラに負けるはずはない
手間かける価値があるかだけが問題

>>579
確かに簡単だ…
オレとしては単純だと人間不利だと思ってるが違う？

＞個人的にはインライン廃止で不便なことこの上ない。
そうだね

>>580
＞手間かける価値があるかだけが問題
もちろん、今後数年はそれで食うためのコードだから手塩にかけるのだ

＞もちろん、今後数年はそれで食うためのコードだから手塩にかけるのだ
ターゲットが決まってるんなら、これもありだけどねぇ。
VC++2005ってことは、ターゲットがないってのと同義だしねぇ。

>>579
http://pc8.2ch.net/test/read.cgi/tech/1103609337/218
_mm_add_pd これが組み込み関数だと思うけど、こういうのって
一般的にパラメータにローカル変数名を受け取るよね？

それをレジスタに割り当てしっぱなしにしてくれたりするんだろうか。

件の例は、速くしようと組み込み関数を涙ぐましい努力でこねくり
回しているように見えるが、ありがちだなあ…

>>581
違うだろう。
あれしきのコードなら、頭の中でアセンブラの最適コードが組める。
人間が理論値を出せばコンパイラに勝ち目はない。
しかも、>>579ではコンパイラが凡ミスして遅くなっている。

コンパイラの最適化は人間の思考がついて行かないコードでも「遅くならない」。

>>583
そこには書いてないけど、組み込み関数で1700clkを出したコードでは、
ループの中ではレジスタに割り当てっぱなしだった。

>>582
＞ターゲットが決まってるんなら、これもありだけどねぇ。
インテルとAMDくらいだったら二つ用意して実行時に切り替える
くらいやってる人多くね？

SIMDじゃないけどトランスメタで早くなるようにアセンブラコードを
Pen系と分けたこともあるなあ。パーシャルストール回避コードが
メタでは勿体無かった。

なんか盛り上がってるな。
>>574
同意。
inline asmが使えなくなったのは、IA64互換がらみかなと踏んでみた。
.net使えｺﾞﾙｧというMSの企みやもしれん。




まぁ半年前までMSの社員だった漏れが言うのもなんだが。

>>584
おっしゃることも分かるけど、やっぱ実感としては、もうちょい
大きいコードで人間は有利だと思う。コンパイラには分からない
プログラムの意味が加味できるから。

＞人間の思考がついて行かないコードでも「遅くならない」
そうそう、人間が最適化するねらい目は、それよりも少し小さくて、
579ほど単純じゃないコード。これが結構いっぱいあると思うがどうか。

おまけに「遅くならない」といっても、それは最速ではないわけだ。
人間の思考がついて行かないのは、最適化に割く時間を伸ばす
ことで徐々にカバーしていける

大域最適化のようなもはや、やる気もおきないような広いレベル
だとコンパイラがんばれということになる。

>>588
＞コンパイラには分からない プログラムの意味が加味できるから。
同意。これはでかい。
アセンブラはCや組み込み関数より圧倒的に表現力が高い。

後半も正しいと思うが、そんなに長い時間を割けるの？
いや、個人的にはアセ最適化大好きだけど。

>>553
6つでは？
CX,DX,7,8,9,10

↑CX,DX,8,9,10,11の間違い

手で最適化するのに意味のあるコードを書く人がどれくらいいるのか・・・

>>576
VCは「こいつアホか」って思うコード吐くときはあるけど、Intelはスタックフレームの使い方結構うまいと思うよ。
SIMD組み込み関数／クラスを使った明示的ベクトライズでいいじゃん。
これなら並大抵のハンドオプティマイズじゃ追いつかない。

んでもってVC++はSIMD関数使ってもスタックフレームの吐き方がウンコ。
Pentium 4でL1キャッシュミス頻発させたことがある。

レジスタさえ足りてればだいぶ良くなるコードだとは思ったが、そのへんはどうなのかな。

>>593
＞並大抵のハンドオプティマイズじゃ追いつかない。
具体例キボン。
人間がアセンブラ書いても負けるとは思えないよ。

いや、皆がどの程度のコードをターゲットに話をしているのか
気になったのだ。程度問題だと思うので。

常に人間がチェックできるほどヒマだったらいいんだけどねえ

アセンブラマニア多いなーこのスレ。
同志がｲﾊﾟｰｲ。

まあ、汎用レジスタが16個になるのは効くだろう。
espやebpは変にいじれないし、mul、div、カウンタに食われるから、
実質３倍くらいに増えた感触じゃないかな。

>>595
盛り上がってるのでスレ違いだと思いつつ最適化の話題。

手塩にかけられるタイプのアプリケーションって、結構あると思う。

オーサリングツール系でバージョンアップしてナンタラ2,3,4,5〜
って出すようなやつの基本部分は大抵担当者の自己満足的
最適化が入ってよくなることが多いんじゃね？

フラッシュとかの言語系などもそう。上に乗っかるアプリで日銭稼ぎ
つつ、エンジン部分はきわめて息が長いから、限界はあるにせよ
徐々によくしていける。

ゲームなんかでエンジンは共通にしているようなやり方のメーカー
もそれができるね。

で、根幹のエンジン部分だとSIMDが大活躍するわけだ。だから
インラインasm復活ｷﾎﾞﾝﾇ

>>587
＞IA64互換
そんな使わんもんのために…それこそ.NETでいいと思う。
IA64とアプリをソースレベルで互換性とっても、MSとしては
どっちにしろIntelだ。ということは、今回の_asm禁止はintelの
陰謀かあ？？

え、商用アプリの話だったの？

個人のオナニー話だとばっかり。

>>599
境界はきわめて曖昧＆６００

>>597
漏れはRISC系のレジスタの多さにちょっと目がクラクラしそうになったことがある。

SIMDヲタにとってはPowerPCは夢のマシンだな。
アポーはIntel移行だけど。

>>594
具体的にはいえないけど、C言語で１サイクル400〜500ステップくらいのループを、
MMX/SSE2で並列化、とか。

レジスタ変数の割り当てだけでも手作業じゃやってらんない。
扱う変数の数がレジスタ数越えるとどうしてもコンパイラの手動最適化にでも頼らないとやってけない。
SIMD関数はロード・ストアをほとんどコンパイラ任せにでき、実演算は明示できるから割と便利だよ。
文字通りの高級アセンブラ。



MSのSIMD関数はっきり逝って使えない。ウンコ。
IntelもMSには大して最適化の技術提供してないんだなと思った。じゃないと自社製コンパイラ売れないからね。

MSPゴ依存AAを禁止されて等幅だけでAAを組まなくてはならなくなった
AA職人が愚痴り合うスレはここですか?

まんもすっぴー♪ゴ依存アナル遊びを禁止されて等幅だけでアン肝アソボットを組まなくてはならなくなった
アースホールアヌス職人が愚痴り合うスレはここですか?

>>603
５００ステップくらいだったらがんばれ！

コンパイラがいかに賢くロードストアしようとも、それを上回るように
網の目をくぐるがごとく綱渡り的にレジスタを使い間々して、メモリ
使用の頻度をさらに下げるのだ。

それと、経験的にSIMDって、演算というよりロードストアでアクロ
バットすることにより速くするもんだと思う。アンパックとシャッフル
を技巧的に組み合わせてうまくやったときには、絶対コンパイラ
には出せない性能がたたき出せる。

＞IntelもMSには大して最適化の技術提供してないんだなと思った

でもあんまりインテルのコンパイラに変えたいと思わないんだよね。
単精度小数演算には強いらしいんだけど（SSEをうまく使ってるの
はここか？）

>>606
いや、整数論理演算ベースでも、ICCでSIMD関数使ったときのあのスケジューリングはとてもまねできない。

アンパックとかシャッフルはもちろん自分で明示的に使うんだけど、それプラス命令スケジューリング
の自動化だからね。

＞ICCでSIMD関数使ったときのあのスケジューリングはとてもまねできない。
なるほど、もしかしたら俺の知らないインテルコンパイラでの
優位性というのはそこなのかもしれんね。

所詮VC互換の使い方から抜けきらないようでは性能で無いと
いうことか…

でもインテルのサイトの提灯記事って、VCをICに変えただけで
幸せになってみたいな書き方なんだよなあ

>>603
なるほど、Intelのコンパイラが優れているということか。
そして変数の数がレジスタより多くなった場合は確かにやりにくい。
正直500ステップはやりたくないよ。実際バグ入りそうだし。

>>606
なんて燃えるレスだ。表現がすばらしい。


コンパイラの吐いた芸術的なコードを見てみたいなあ。

>>609
＞正直500ステップはやりたくないよ。
うーん。もっと長いのぼこぼこやってるんだわ（_asmで1000ステップ
2000ステップ）。そんなファイルが何個もある。スケジューリングは
根性の手動。もちろん全部見渡すなんてできないから、小ブロック
に分けて追いきれる範囲でやるんだが。

>>607殿の話を見る限り、もしかしたらそれを組み込み関数で
置き換えたらもう一皮向けるのかな。

mmレジスタだけじゃなくて、一般レジスタも合わせてみつ編して
織り込むように記述していって悦に入っているのだが、それを上回
れるんかあ〜orz

速くなるならそれでもいいのだが、exeのでかさがトレードするかどうか
微妙だよ。VC→ICへの移行は。

このスレ読んで思ったが、64bit化を担当している人は、
漏れと同じくバリバリアセンブラ書く人たちなんだなー。

>>611
つーかスレ違い（笑）

インテルコンパイラのスレに行ったほうがいいのかも知らんが、
あっちではなんか盛り上がらなかった

64bitプログラミングネタに戻りましょうね

Win32からx64コードを呼び出すネタに興味があるのですが
x64コード部分はハンドアセンブルで作るしかないのでしょうか？

だれか >>562 に答えてくれお願いします

マイクロソフトに聞けよ・・・

>>615
たぶん「駄目」だと思う。

>>617
ありがと

駄目か…では他のアプリのウインドウにSendMessageしたいときは
相手が64bitだったら送る側の32bitアプリはどうしたらいいんでしょう？
（もしくは逆のケースでも）

>>618
32bitアプリからは64bitアプリは不可視なんじゃないかなぁ

>>618
その場合はOSが受け渡す前に変換してくれるから何も考える必要ない
UnicodeウィンドウがANSIウィンドウに文字列含むメッセージ送信しても
問題ないのと同じ

なお、答えられない人、「MSに聞け」、などの低脳な人はお断りです。

>>619
32ビットアプリからも64ビットのウィンドウは普通に列挙できるし
32ビットのハンドル値を持ってるよ
だからこそ>>561で言ったような制限が必要なわけだし
できないのは64ビットアプリにグローバルフックを仕掛けること
(32ビットDLLがロードできないから)

> 32ビットのハンドル値を持ってるよ
32ビットのハンドル値を持ってるように見えると言った方が誤解を招かないか

>>610
MMXを使っているようだが、64bit化するときはSSEにしないといけない。
簡単に変換できる？

つーかアセンブラでMMX使っていたプログラムは移行が大変かもな。
SSEはメモリアクセスにアライメントが要求されるし。

なんかできそうな雰囲気もありますね。x64機手に入れるときが
来たら、相互にハンドル交換でアクセスできるか試してみます。

やろうとしてることと関連してるんだけどまったく別なような質問。
64bitIEと32bitIEが同じページにアクセスして、ActiveXを object
タグで配置指定した場合、64bitのocxと32bitのocxをうまいこと
とっていかせる方法ってありますか？

>>624
Win64がそのうちMMXがOKに…ならんよなあ。
CPUとしては使えるような感触が上読んでるとあるが。

mmレジスタをxmmレジスタに変えるんでもアライメン問題
おきる？ MMX->SSEはほぼ変換きかないから、やるんなら
MMX->SSE2(というかXMMX)だよね。

>>625
不完全ながらUserAgentで判別はできるが変えている人も少なくないし実用になるかな

ActiveXにはNTのマルチアーキテクチャ対応の機構
(x86ではx86用のバイナリ、AlphaではAlpha用バイナリみたいな)がいちおうあるから
それがIA64/x64用にも拡張されていれば理論上は可能なはず
もっともx64用のActiveXコントロールすら見たことないから
本当に使えるのかどうか不明
64bit版のIEじゃダウンロードセンターの正規ユーザー認証もできないし
Windows Updateも32bitのIEで出直せと言われるし

>>626
あ、もちろんSSE2整数のことだよ。ゴメン。
アライメントは、movq → movdqu（movdqaはダメ）なら問題ないが、

paddd mm0,[eax] → paddd xmm0,[eax]
これだと16byte alignがないと例外発生。

movdqu xmm1,[eax] / addd xmm0,xmm1
としなければならず、面倒だし、命令数が増えて遅くなる。

>>627
おっしゃるのはサーバー側で切り替えるということ？

うーむ、IEのほうでobject64とか新タグ規定して、64bitIEは
そっちを優先して見に行くような機構があればいいのに、
と思った次第。

>>628
ActiveX作るときって単にMFCっぽいプロジェクトからビルドする
だけなんだど、そのマルチアーキテクチャって、どの変でプログ
ラマが意識することなの？

>>614
>>392

>>629
＞paddd mm0,[eax] → paddd xmm0,[eax]
このケースってどうしてもレジスタが足りないときにしかやらないから、
レジスタ増えた分で補えば何とかなりそうかな。

演算の読み込み元のストリームバッファがmmxレジスタのイメージ
で並んでるのって結構メモリの無駄が多いから、読み込みは大抵
movd -> unpackなんだよねえ、オレのケースでは。幸いかな

>>632
オペコードマップ自体違うから無理じゃないかなぁ

>>631
漏れは使ったことないくせに知ったかぶってるだけだから分からん
このへん見てテキトーに判断してくれ
http://msdn.microsoft.com/workshop/delivery/download/overview/inf.asp
つーかその昔はエミュレーションでx86のActiveX使えたのかよ
なんか納得いかんな
http://pc.watch.impress.co.jp/docs/article/960919/nt40us.htm

>>634
use64セグメントではamd64
use32/use16セグメントではx86のオペコードを吐くんでしょ

>>635
返事ありがと。
あーinfで複数のファイルをcabにして配布するってのがあったなあ

おれのはocxを直に配置だから、そこんとこ変えりゃあいいんだ。
……ﾏﾝﾄﾞｸｾ orz

>>636
セレクタさえ作れればWow64からは可能だろうけどWin32からは無理だと思う

>>638
392のすぐ後でWOW64限定という話が出てるから
それは前提だと思ってた

>>632
その付近全部読んでいたはずなんだけど、読み飛ばしていたorz
Thx.

インラインアセンブラ禁止は
x86廃棄のいい機会。

廃棄してもいいこたあないよ。

レジスタたくさんあるCPUのアセンブラとか結構組んだけど、
面白さはどっちも同じだ。

いや面白がってどうするﾊﾊﾊ

今回は、インラインアセンブラの禁止、そしてx87&MMX命令の禁止と
二つ重なってるんだよね。
32bitではインラインアセンブラ使えるし、WOW64ではx87もMMXも使える。
何故nativeの64bitで両方禁止したんだか...結局はMSの策略なのかな？

appleもIntelに乗り換えるわけだし、x86は今後も消えないと思うが...。

ヒント：PARROT

x87とMMXは、将来x86から消す予定なんじゃないのか？
これに関してはいいタイミングで禁止したと思うけど。

インラインは知らん。

AMDのロードマップで、「今後AMD64にFPUサポートを追加」ってのがあったと思ったけど。

ハードウェア的にはすでにサポートはあるでしょ。Win64がサポートしていないだけで。
16ビットサポートと同じ。

じゃあ近い将来にx87がなくなることはないんだ。

その前に人類は地球を食い尽くすよ

すげーなx87

x87がすごいのかよ

Win64でいきなり87を潰すのもなんだかなー・・・・
SSE命令に移行させたい気持ちはわかるんだが、過去との互換性を最大限に
保とうってのがx86の利点じゃなかったのかよ。

ま、Intelはそれを守ってきたが、AMDがx86-64で命令コード変えて、互換性
を無くしてしまったが。ここまで市場が大きくなれば、少しぐらい勝手な事をして
も売れ行きは鈍らないと読んだんだろうな。

本当の理由は、オペコードに隙間がなさ過ぎて、命令の拡張が困難になった
ので、INCやらDEC命令を潰したんだっけ。そしてREXプリフィックスにした。

それはいいとして、32ビットモードでは87が動き、64ビットネイティブでは動かない
という奇妙な状態が出現している。しかもインラインアセンブリが不可とは。
大丈夫なんかね？

>>652
え？　x87動かないの？　上見るとWin64がコンテキストセーブの
対象から外しただけのようなこと書いてあるが。

もしかしてx87(MMX)レジスタ物理部分を64bit汎用レジスタ新設の
スペースに回したとか。

SSEではなくx87やMMXを敢えて使いたい理由って過去の遺産以外に何かあるの？
どうせバイナリ互換のなくなるx64は過去を捨てる良いチャンスだと思うのだが。

>>654
通常のCコード（整数演算）をSIMD化するとき
MMX化する
SSE化する
SSE2化する（XMMX）

これを比べると、一番効果あるのって経験上MMX化なんだよね。
オレと同じ感触持ってる人いない？

`AMD64 Architecture Programmer's Manual Volume 5' を見てみると、
LONGモードでもx87使えると明記してあるね。

NetBSD/amd64はコンテキストスイッチでx87レジスタをちゃんと保存し
てるみたいだし、やっぱりMicrosoftの陰謀なのか。

>>656
そいつはわかってる。WinXP64が、ネイティブモードで意図的にx87をサポート
してない事が問題なんだ。

>>655
PentiumMではMMXが速いことが多い。
SSEは128bitだが、内部で64bit*2の処理に分解されるので遅いのだ。

ただ、Pentium4では圧倒的にSSE/2が速いし、
これから出る64bit対応MeromでもSSEが速くなっているだろう。

現状ではMMXが速くても、ターゲットとなる64bitCPUでは
SSEが速いので、さして問題にはならないと思う。

今が変わる時期だとは思ってる。

x64でレジスタが増えたといっても多い方ではないし
64bitデータの退避先として悪くないと思うんだが

>>658
＞ただ、Pentium4では圧倒的にSSE/2が速いし、
圧倒的というほど速くない。SSE/2で補強された命令
を使ってさらにMMXを速く動かすというのがオレの実感

>>660
消極的イクナイ

で、ここで愚痴って何か変わるのかね？

MSがそうすると決めたんだから
その流儀に従うか、そうでなければMSを離れるかしかないよ。

ここはぐちぐち言う場なのではなのかね？

ちなみにオレはMSにはさほど悪感情はもって無いよ

64ビットのプログラミングモデルで、MMXが推奨されていないのは痛い。
XMMで完全代用できないんだよなー、レジスタこそ増えてるけど
L/S とか演算器の負担が増えて遅くなっちまう。

世論がたくさん望めば巨人が動くこともある

MMXレジスタが8本のままってのが悲しかったが、
論理演算だったら64ビットGPR使えばいいのか。

とりあえず、インラインアセンブラ復活の声は結構あるはず・・・
けど、そんなことはMSだって実行する前からわかってたわけだから、動いてくれないよなぁ・・・
戦略上何気に重要そうだし・・・

ICC9.1からEM64Tのインラインアセンブラをサポートすると
IDF 2005で言ってた。
Itanium2ではkernelモードでx87をサポートしていないので
全てのインラインアセンブラ削除だと。

>>667
VCがインラインサポートしないなら、それを理由にICに
乗り換えるのもありかな。

>>669
>>667 → >>668も

>>668
意図がよくわからん。Itanium2とx87とインラインアセンブリに何の関係が？？

Itanium2ではSSE/SSE2しかサポートしていないので、
既存のMMX、x87インラインアセンブラは使えません。
SSE2関数呼出しを使ってくださいという事でつ。

Itaniumの浮動小数点演算命令がx87互換だった、ということ？
(自分はIA-64に関する知識はぜんぜんないです…)

688見て思ったが、VCのインライン廃止は
x87やMMXがインラインで入った過去のコードを引き継がせないため？

・・・でもそれなら単に該当命令があるときエラー吐けばいいだけか。

>>668
なんでx87をサポートしていないと、全てのインラインアセンブラが
禁止になるのか？

まあ、Itaniumなんか使わないからどうでもいいが

>>674
MMXはインラインあたりまえだが、x87をインラインで書く香具師いる？

インラインアセンブリ記述をサポートしなくなっただけで
asm モジュールのリンクは問題ないんだろ?

>>676
俺は趣味でだけ。
80bit精度が欲しいときとか、アセンブラで簡単にsin使いたいときとか。

>>677
それはOKだろう。
でもインラインの手軽さ・便利さが惜しい。

最近のAMD64版masmでは、x87命令に対応しなくなったな。
server2003 DDK付属のものは対応していたのに。

>>675
誤解を招く書き方でスマんかった。
EM64T→MMX、x87インラインアセンブラのみ禁止。
IA-64→インラインアセンブラ全て禁止。
Itanium2の場合EPICといって、できるだけ並列実行できる様にコンパイラが
スケジューリングを行なうのでインラインアセンブラ全て禁止なんだと思う。

gcc 使えば IA64 でもインラインアセンブラ使えるでしょ。
実際、ここいらではバリバリ使ってる。
ttp://lxr.linux.no/source/include/asm-ia64/gcc_intrin.h

Linuxはよく知らないですけど、bugの修正の為に使ってるんでは。

Linux 知らなくても IA64 知ってれば見れば分かると思うけど…
バグ修正じゃなくて、高速化のために使ってるんだよ。
いちいちアセンブラ部分を関数に分けて関数コールとかしてたら
遅いでしょ。

・・・バカ?

インラインアセンブラ禁止ネタ飽きた

だれかネタ投下キボン

>>686
Microsoft自身からネタ提供をやめるように仕向けたも同然なので、
このスレは間もなく潰れます。

64bitプログラミング＝インラインアセンブラで64bitレジスタをいじる
だよね。うん。俺もそう思う。
というわけで終了。

逆に俺は
「64bit CPU 使ってまでアセンブラでちまちまやるのかよ。
　いい加減そんな枝葉の部分はコンパイラに任せちまえよ」
と思ってしまうわけだが。

32bitのインラインアセンブラのプログラムに64bitのコンパイラの
出力が勝てるならそれでもいいよ

おまいら動画のデコードでもしてるんですか

インラインアセンブラで最適化できないなら
それはプログラミングと認められないよ

>淫乱な熟女が
まで読んだ

gcc 使えばいいじゃん。と言ってみる。

gccはインラインアセンブラじゃない部分の最適化が(ryですから
全部アセンブラで書くしかないのでは

全部アセンブラで書くくらいなら、コンパイラにアセンブラ出力させれば良いんでないの
ケースバイケースかもしれんが...

>>696
空気嫁

Cのコードの中にアセンブラで書けることがプログラミング・ツールの要件
なんだよ。

>>695
gcc 4.0 は結構頑張ってるよ。なんて言ってみる。

>>697
えらく狭い要件だな。

はぁ？プログラミング・ツールが利用方法を制限してどうする？
インラインアセンブラが使えないＣコンパイラなんて聞いたことない。
ＭＳは今すぐ方針転換すべき。

インラインアセンブラが使えないＣコンパイラって昔は結構あったな

>>697
流れ嫁

OSが独占されているからといって開発環境まで独占させる必要はない。
MSが駄目なら他社に期待すればいいだけだろう。

なんか理由があったからそうしたに決まってるだろ。
MSにしたがってれば間違いないんだよこの業界は。

OSサポートがないと拡張命令は使えないんだろ
つかインラインアセンブラが使えないってのは、FP/MMXの話だろ

OSがレジスタの待避をしてくれないとしたら？

汎用レジスタからMM0-MM7にダイレクトに値を交換する命令って追加されてたっけ？

＞つかインラインアセンブラが使えないってのは、FP/MMXの話だろ
その書き方だと_asmはOKでfpu,MMX関連だけが駄目のように読める

IA64の場合はどう？
やっぱアセンブラで書かせろとか言うの？

>>708
Cがサポートしなくて（あるいはタコで）尚且つ効果的な命令があれば。
まあ実際のとこ民生用に普及しなければ触る機会は無いだろうな

>>708
空気嫁

CPUやOSに関わらず、インラインアセンブラは使えなければならない。
その必要性は歴史が証明している。

>>710
後学のためにどう「歴史が証明している」のか具体例を示して頂けまいか。

歴史＝このスレ

>>693
そこで読むのをやめる喪前はどうかしてる

>>713
熟女好きばかりでは無いという事だ

まぁ、特殊なドライバでちょっとだけ特権命令を使いたい場合なんかはインラインアセンブラが
便利だけどチューニング目的なら_asm{}の前と後に付くレジスタ退避・復帰もあるから
asmファイルで別コンパイルだな。

>>715
実際には復帰退避のコードってあまり生成されない気がする。
コンパイラが_asmをまたいだレジスタの継続使用をやらなくな
るだけで。

どっちにしろそういう場合、_asm{}の外は
速度的にどうでもいい部分だから外なんだし

んだんだ

まあ、_asmの外のこまごまが気になるというのは、インライン化する
範囲の設定を勘違いしている可能性大

関数丸ごとアセンブラモジュールにするのと_asm使うのはほとんど
効果は変わらないよね

それにしても、アセンブラスレや最適化スレよりもなぜにこっちで盛り上がるのか（笑）

>>716-717
何か勘違いしているようだが、パフォーマンス気にするなら頻繁に_asm{}を
出入りするようなコードは書かないはずだからファイル分割で良いだろうと言う意味。

頻繁の度合いによるよ。

ループの外側に_asmを置くような例で、その関数が如何に何千回
呼び指されようと、ループの内部が数十万回繰り返すなら、ファイ
ル分割＆モジュール全てアセンブラと差は無いと思う

720は何も分かっちゃいねえと思われ

>>721
いや、実際に性能にこだわるんだったらループ自体も含めinline asm化するしかないでしょ。
そうしないとinline asmによるコンパイラ最適化機能の抑制もあって旨くない。
まぁ俺の場合だとiccのvectorize等で十分だったりするから性能目的で_asm{}を使う事は
ほとんどないってのもある。正直、ドライバでコントロールレジスタ等が弄れない方が痛い。

>>722
お前がなにかわかっているようにも思えんがな。

>>723
721は「差はないと思う」と書いているが、おまいは差があると思うの？
俺は差がないと思う。

719にあるように_asmの範囲をちゃんと考えることが大事なのよ。

>>724
論点がずれている。インラインアセンブラが必須と考えているかどうかが問題。
差がないと思っているならインラインアセンブラは必要なしと考えている？

はあ？ループ自体を丸ごと_asm{}内に書いて
ループ前後の性能に影響しない部分をC++で書くから
コンパイラの最適化抑止なんかどうでもいいだろうが
アホか？

>>726
日本語が苦手な人なんですね。w

>>725
あなたがずれてるよ。
インラインの利点は性能じゃなくて便利さ。
差がなかったらインラインの方が簡単でいいでしょ。

短いコードならインラインのほうが楽だが
そうでないならマクロなどを使える方がいい

>>723
えーと、オレは
＞ループの外側に_asmを置くような例で、

と書いたんだが、（_asmがループの外）

＞いや、実際に性能にこだわるんだったらループ自体も含めinline asm化するしかないでしょ。
と読んでくれい。_asm使うときでも少なくとも最内側のループごと
アセンブラにする。そんなのあたりまえっす。

俺が言ってるのは、関数モジュール丸ごとファイルを分けて
フルアセンブラ化しても、_asmに比べてメリットは無視
できるほど小さいってこと。

みんなそうだべ？

>>726
そうそれ、言ってること正解。
でもまたーりしる

インラインアセンブラ必須ということでＦＡ？

用途によりけりでしょ ＞インラインアセンブラ

まあ俺は普段使わんからあってもなくてもどっちでも構わんけど。

>>732
なくてもかまわんが多数派だろ。

>>728
「必要 or 不必要」と「便利 or 不便」は別の話ではないのか？

インラインアセンブラなんて使わないからいらない

最適化開発者の99%はinline asmをなくしたいと思っている。

>>737
ソース

実際、コンパイラ作ってる人にとっては
インラインアセンブラは嫌なのかね？

でもまあアセンブラの方が速いのは事実だから
ないと不便ではある。

なんだ、VC++2005の64ビットモードは、インラインアセンブラ無しかよ。
糞だな。

みんながアセンブラ使いになったらコンパイラが売れなくなるから。

>>741
いや、それはその仮定自体ありえないｗ

誰かポインタが６４ビットになって幸せになった香具師はいないのか？

雑誌記事やこのスレへの書き込みを見ていると、
単純にリコンパイルしただけで１割程度の高速化が
見込めるようだが（32bit比）、なぜ速くなるのだろうか。

例えば以下のような単純な例でも速くなったりする？ 最適化は考えないとして
for(i=0; i<1000000000; i++){
x++;
}

インラインアセンブラが使われたコードは
最適化の対象にならない。

最適化とはようするに、意味が同じになるようにコードを
組替えることなんだから、インラインアセンブラという
なにをしているのか解釈できないコードがあると最適化は不可能になる。

>>744
>>203, >>343->>346, >>357, >>367-368

ページサイズが大きくなったのも貢献してるんじゃないかな

アンカーサンクス

ざっと見たけど説得力あるのは
＞レジスタ渡しになった事が原因の一つと聞いたことがある。
くらいかなあ。後はオレの知識不足から、他はホントに効果
あるのか判断できん要素ばかりだ。

mov eax,ebx

のスピードは32bitでもロングモードでも変わらんのでしょ？
あとは上でも散々不評なMMXレジスタのコンテキスト切り替え
の負荷軽減？　そんなもん体感できないと思う…

＞ページサイズが大きくなったのも貢献

スワップアウトが絡まない状況ではどうかしら？

ページサイズって書いたのは、仮想アドレス→物理アドレスの変換テーブルのリーチが
長くなるって事。これについてベンチマークを見た事が無いので、あまり関係無いかも
しれないけど。

レジスタの数が増えた事は大きなプラスだと思う。特にコンパイラ屋さんは嬉しいんじゃ
ないかな。特に、Java みたいな Runtime が大掛かりな言語なんかは。

＞レジスタの数が増えた事は大きなプラスだと思う。
なるほどそれは単純に説得力あるね

>>744
その例では同じ速さだと思う。

大きなメモリを使うアプリだったら、
単にOSのバージョンが違うという影響もあるだろうが。


引数のレジスタ渡し。
PentiumMは、スタックエンジンによって5%程性能が上がっているらしいので、
（push,pop,call,ret等のespを操作する命令に効く）
pushがmovで済んで引数つきretがなくなるだけでかなり速くなりそう。

逆に言うと、PentiumM（現状32bit）は64bit化すると
スタックエンジンの恩恵が薄れてしまうね。
Meromにもスタックエンジン載るのかな。


32bitで本当によく最適化されたプログラムは64bit化しても速くならないっぽ。

>>750
速さに関してはやはりそうだね。ならばメリットは主にサイズという
ことになると思うのだが、ポインタ64bitに関してはレス無しか。

mallocや.bssセクションに４GB以上の領域を平気で指定するような
プログラミングスタイルに移行すると思う？

16->32bitの時は平気で64KB以上のメモリを確保するようになったわけだが。

64KB以上のメモリは切実に欲しいけど、
4GBは一部のアプリでしか使わないからな。

俺も差し迫って4GBが欲しいわけじゃないので、
どうしてもポインタ64bitには興味がなくなってしまう。

動画編集とか声高に言われているけど、１バッファリニアで４GB越え
を確保したりするのかな？

ああいうアプリは合計して４GB越えなんだろうかと。組んだこと
無いのでよく知らんが、HDも活用するスタイルでの組み方は
廃れちゃうんかねえ。

＞どうしてもポインタ64bitには興味がなくなってしまう。
やっぱそうなんだよね。オレもですよ。

なんだか32bitは16bitほど簡単には消えない気がするなあ。
飽和したハード市場に、ネタに困ったメーカーが苦し紛れに
投入を急いで、メディアも記事のネタに困ってとりあえず足並
みそろえているだけの感が否めん。

このスレでこんなこと言ってｺﾞﾒﾝよ

アドレス空間が64bitになって嬉しいのは、ほんとに一部のアプリだけ
でしょ。データベースとか、動画関係とか。

それらにしたって、実際に4GB超のメモリを確保するんではなく、
FileMappingやmmap()で扱うんだろうなあ。

データベースってほとんどファイルに書き出されていて、
ソートで縦1行舐めたりするときにメモリ上に持ってくるって
イメージ。

データ全部メモリ上に物理的に置いてしまって高速化しようという
魂胆なのかな？

物理的にメモリ上に乗るかどうか別にして4G以上のファイル全体をとりあえず
mmapしちゃって、あとはリニアにアクセスできれば楽というのはあるな。
最近のデータベースとかはそういう作りが多い。
もちろんメモリとして見えるからといって無造作にアクセスするわけではなく、
効率上ページ境界とかある程度意識するけどね。

なるほどプログラムが（新規に起こすなら）楽になるという方向か。

たしかにファイルマッピングはある種の処理の書き方が、普通に
ファイル中をseekするよりも異様に簡潔になる場合があるね。

新規に作る場合は、「あ、32bitに収まんねえ」という小さな躓く石がなくなっていいね。
いづれ移行するので、今少しガマンすれば後は幸せになれるはず。

開発者が楽になるという方向はわかったが、パフォーマンスアップは無いのかな？

上の例だと実際にデータベースにアクセスするユーザーには64bit化のメリット
がわかりにくい。ファイルマッピング使ってプログラムが綺麗になってもなあ。

データベースの64bit化でもパフォーマンスアップがプッシュされていたように
思うけど（ソースは忘れたが何かの雑誌の64bit化特集記事立ち読み）もし
性能がよくなるならそれは何故なんだろうか

>>759
単純にレジスタ倍増と引数のレジスタ渡しのせいだとオモ。

メモリをちょこちょこ使うとか関数呼び出しが多いとかの、
「極限までの最適化はしてない」タイプのプログラムだと
相当に性能がブーストすると思われ。

その「相当」というのは上に出ている１割かな？

ゴメン。試したことはない。多分１割。

「相当」というのは、「無駄に関数呼び出しが多いプログラムだとかなり効くだろうな」
と思ったから。

いやね、アセンブラのありがたみが少〜し減ったなと思ったのよ。
少ないレジスタでメモリアクセスを極限まで減らした高速化も、
64bitだと潤沢なレジスタで簡単にできてしまう。
そういうプログラムに比べたら、最適化の甘いプログラムは
64bit化で「相当」高速化するだろうなと。

まあ雑談なんでとくに謝ることは無いぽ。好印象ではあるけど
おれも実際そう大規模のデータベースはいらないし、適当言ってるだけｗ

全部オンメモリという力技でないと、ファイルマップする様なもので
HDガリガリ言い出したら、レジスタ増の恩恵も減りそうだね

64bit化で、ビット幅２倍、リニアに指せる領域４０億倍なのに、
速度は0.1倍増のみか。時間は距離に比べて手ごわいね

ふと l = tc を思い出した（cは光速定数）　全然関係ないけどw

64bitの整数演算とかなら２倍以上速くなると思うけどねぇ。
んなもん、さほど使わんし。（趣味では素因数分解とかに使いたいけど）

並列性の抽出が難しいのはどこも一緒。

>765
固定小数点演算は、64bit整数が速ければ十分恩恵を受けられそう。

64bit幅の固定小数表現って用途としてどんなのがある？

>>767
64bitコードでのポインタ演算ｗ

固定小数点数のポインタ？

OS が 64bit 化されるのも嬉しいんじゃないかな。
今までアプリケーション側からは 4GB フルに使えなかった、
っつーか4GB を複数アプリと OS とで分け合ってた訳だから。

サーバサイドなら、Java のヒープを 2GB にして複数の VM を
起動とか、DB のキャッシュ領域に数 GB とか、メモリはあれば
あるだけ嬉しいよ。Opteron みたいなサーバ向けプロセッサには
必須なんじゃない?

現実のマシンとして物理メモリはどれだけつめるんだろう？

＞っつーか4GB を複数アプリと OS とで分け合ってた訳だから。
32bitＯＳって２ＧＢのアプリをいくつも起動できるんじゃないのか…？

できるよ。物理メモリの話じゃないの?

>>768
マジレスキボンヌ

＞できるよ。物理メモリの話じゃないの?
前後を読むとそういうニュアンスに読めなくもなくもないようなorz

>>764
現実問題として、同じデータ個数の場合、64bitデータを引っ張ってくるのは
32bitに比べて倍のバス帯域が必要な訳で…メモリ速度が…

メモリセルは現実的に速度向上が進んで無いし、かと言って
CPU内部キャッシュのバス帯域もなかなか…

PAE って使われてるの?

>>776
メモリ速度は落ちてるのか？例えば1バイト読むとき
char a = *p;
とするわけだが、64bitの方が遅い？

>>778
「1バイト読む」は変わらんけど、そのpの値はどこかのメモリから持っ
てこなきゃけいないわけで、それが遅いと思われ。

単純に
movzx eax , byte ptr [ebx]
と
movzx rax , byte ptr [rbx]

を比較したらどうかな？キャッシュなどは同条件で、bにはもう
ポインタが設定済みとして。（ニーモミックは適当かも）

アドレスデコーダはロングモードでは倍の幅データが流れるような
気がするんだが、そこに速度の差は現れないのかな？

ニーモミック→ニーモニック

>>780
少なくともAthlon 64は最初から広い内部アドレスバスで設計されてるから
L1へヒットしている限りは同じ速度だと思うよ。EM64Tは知らんが。

同じポインタでも２倍のメモリ食うし、
キャッシュヒット率が下がるのが懸念されるが
やっぱレジスタ増えるほうが効果高いんかなあ

64bitでコンパイルしなおして１割速くなったというのは既出のようだけど、
逆に遅くなったケースはあまり聞かないね。レジスタ倍増効果が
あるのかもしれん。

遅くなった香具師いないの？

>>782
おれがCPUの中の人だったら、32bitのときに遊んでるリソースを
どこかにまわしたいと思うかも。

Pentiumのときすでに内部バスは64bit幅だった気がした

>>786
外部データバス幅の話と混同してない？
内部バスっていろいろあるから、どのパスが64bitとか言わないと意味無いと思う。

SPECint2000では32bitより64bitの方が遅くなったりしてるね。
↓の64bitLinux上でのテストでも、Peak Tuningではいくつかのテストで
　-m32オプションを付けて32bitバイナリ出力してスコア伸ばしてるし。
http://www.spec.org/cpu2000/results/res2005q2/cpu2000-20050613-04262.html

Celeron Dに続いてSempronも64bit化されるね。
http://pc.watch.impress.co.jp/docs/2005/0706/amd.htm

64bitになったからって32bitで済むなら、32bitオペランド使うだろうし。
何が何でも64bit長のロード／ストア使わなきゃいけないということはない。
（x64の場合）

>>790
ポインタは何が何でも64bit強制でしょ？　上の一連、ポインタの
指す先の幅はまた別の話だと思う。それとも x64 で

movzx rax , byt ptr [ebx]
ってやっていいのかな？

下位4G以下ならいいんじゃない。
まぁ、ポインタの値はOSしだいだけど。

WOW64上で64bitモードに切り替えるってやつならOKだろうねｗ

>>792
linkで/LARGEADDRESSAWARE:NOｵﾌﾟｼｮﾝをつけると、プログラムイメージや
ロードされるDLLは、すべて2G以内に収まるよ。

もちろんAPIに渡すポインタは64bit長じゃないといけない。

インラインアセンブラが使えないからどうでもいい

ただたたきたいだけちゃうかと

>767
32bitだと、シフトしたりして計算してるうちに、どんどん桁が足りなくなるじゃん。

>>796
精度とかじゃなくて、どんなことに使えるか？　というネタ投下。
食いつき悪いところ見ると、あまりそういう使い方してる人いな
さそうですね

x64 で何が悲しくて固定小数…といったところかな

>>794
話を単純にするためにニーモニック風に書いてるけど、
ポインタの幅が倍になることによるバスレベル？の負荷増減
の話をしているんだと思う。アセンブラ限定の話題でも無いと思う

>>793
＞linkで/LARGEADDRESSAWARE:NOｵﾌﾟｼｮﾝをつける
もしかしてこれ付けるとuint32型へポインタを格納しても
事実上情報の欠落は無くなるということ？

お勧めはしないけどｲｲｺﾄｷｲﾀ

P5以降だったら内部は64bitなので、L1ヒットしている限り64bitでも遅くならない。
実際、MMXレジスタ同士ののmovqやpaddの負荷を見ても、32bitのmovやaddと同じだ。

CPUを64bitに対応させることでクロックが上がりにくくなるなどはあるかもしれないが、
同じCPUで32bitでなく64bitを使ったからといって性能に差が出ることはない。

mulやdivは、さすがに遅くなる。
Athlon64でのレイテンシは、imul：3→4、mul：3→5、idiv：42→74、div：39→71。
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF

L1ヒット率は、64bitのポインタは16KBに2048個も入るので
普段は問題ないだろう。

固定小数は、64bitならdoubleよりも精度があるわけで。
かけ算やシフトで半分犠牲にしてもfloat以上というのは魅力的。
・・・趣味の範囲に止まりそうですが。
つーか固定小数みたいなな速度優先だったら、SIMDのpacked 32bitでいい気も。
俺はMMXで水面のシミュを作った。

>>801
掛け算したときの上位桁をCレベルで手軽にケアできる？
アセンブラならｄｓｔが128ビットであつかえるから問題ないが…

＞俺はMMXで水面のシミュを作った。
なくなってムカついてる口ですね。蒸し返すようだけど、
倍精度の計算をSSE2でやるんなら、FPUを常に寝かせて
ずっとMMXとして扱えるじゃないか。

emms書く必要もなくなるなら非常に嬉しいんだが。

80bit浮動小数点を亡き者にしたいのかもしれないな
MMXは巻き添え

将来的にはMMXなくなってもいいと思うけどな。
SSE2整数がMMXより速くなるだろうから。

MMXとSSE2の両方あるのは、レジスタ数や名前空間の無駄。

>>804
＞MMXとSSE2の両方あるのは、レジスタ数や名前空間の無駄。

そんな事は君が決めることじゃない。

そう、俺が決める。

名前空間？？？

>>806
ニート風情が何を大言壮語叩いてやがる。

>>791
RIP相対32ビットで済む場合は32ビットじゃなかったっけ?

>>809
プログラムカウンタ相対の話してるの？　ジャンプ系統なら
リンカがより短い相対ジャンプに最適化してくれるんじゃないかな。

データを読み出すポインタの話とはまたちょっと違わね？

データも64ビットだとグローバル何とかってのがあるってどこかで
見た記憶があるんだけど。
IA-64だっけ?

>>810
x64では、データアクセスにrip相対アドレスを指定できる。

>>812
Cからだとグローバル変数のアクセスへはそのアドレッシング
モードが使えそうだね。

その場合Cのポインタ変数へアドレスを代入するとオフセット値の
32bitが入るのかな？

なんかCではそのアドレッシングは使われない気もするなあ

MSC AMD64版のアセンブラ出力見ると、グローバル変数のラベルは
32bitアドレスっぽい。

>>814
リンカかWin64の制限で静的にリンクされるオブジェクトの
合計は2GBって決まっていたような希ガス。

>>814
ロードされるアドレスを絶対番地で４GB超に設定できるのかな？

その場合でもオペコードのラベル部分はrip相対で32bit内に
収まるようになるなら >>815 のリンク制限はなにをかいわんや

>>815
ベースアドレスを4GB超で設定できるよ。
ただ、イメージサイズは2GBまで。これ以上はリンカでエラーが出る。

相対ripを使うから2GB制限なのか・・・な？

>>818
おれは適当言ってるだけなんだが、イメージサイズが２G越えたら、
端っこのオペコードがグローバル変数が置かれている
場所に届かなくならね？　グローバルを真ん中に置けば４G付近まで
いけるけど、そんなせこい工夫はしないだろう。

.bssセクションにchar data[4GB]とかやってもイメージサイズは小さいままだよね。
この場合もdataのラベルは32bitなんか？

そもそも命令とデータ部分が同じアドレス空間にマップされているのかな。
命令のゼロ番地とデータのゼロ番地って同じもの入ってる？

>>818 → >>817

>>818=819
自分で確認すりゃいいじゃん。

>>818
イメージというのは実行ファイル自体のことじゃなくて、それがメモリに展開された
ものだと思う。
↓のように未初期化領域を含めイメージが2GB以上になると、リンカで
　fatal error LNK1248: image size (8001E000) exceeds maximum allowable size (80000000)
というエラーが出る。

_BSS SEGMENT
　COMM a:BYTE:80000000h
_BSS ENDS

_TEXT SEGMENT
　main　PROC NEAR
　mov　eax, dword ptr a+78787878h
　ret
　main　ENDP
_TEXT ENDS

>>821
要は２GB以上はmallocしろということかぁ
ならグローバル変数にrip相対32bit持ってくるのは
妥当と思われるけど

mov　eax, dword ptr a+78787878h
これのソースオペランドののアドレッシングが明示しなくても
rip相対になるということ？

>>820
すまん環境が無いんだ。後学のためにぐだぐだ書いているんで、
目ざわりだったら読み飛ばしてくれぃ

>>822
了解です。
NGワードにするからコテハンをつけて頂けると有難いです。

>>816
できるよ。デバイスドライバは実際にその位置にロードされるし

あった。「グローバルポインタ」だ。
http://msdn.microsoft.com/msdnmag/issues/1100/hood/
やっぱIA-64の話だった

総合すると、グローバル変数のポインタを扱うとき、上位32bitは本質的には
遊んでるってことか。

> NGワードにするからコテハンをつけて頂けると有難いです。

なんて自分勝手なやつだ！！

> 目ざわりだったら読み飛ばしてくれぃ
と言ってるし…

>>756
それは間違いでしょ？
mmap() するとディスクアクセス、特に書きだしが OS まかせに
なるから、データベース側の都合を気にしてくれない。
だからカリカリにチューンしたデータベースの場合、mmap() は
決して使わず、自前でキャッシュ管理して、O_DIRECT モードで
preadv()/pwritev() している筈。
じゃあ、データベースの場合、なぜ 64bit が嬉しいかというと、
ちょっと負荷のかかるサーバだと、現実に4GB以上のメモリを積んで、
4GB 以上のキャッシュを扱いたくなるからの筈。もちろん、これまで
の 32bit OS でも一応 4GB 以上の物理メモリを1プロセスから使えた
わけだけど、OS を関与させた仮想アドレスの再マップとかが必要
だったわけで、何も考えずに 4GB 以上の仮想メモリ空間が使える
64bit OS に比べると、だいぶ効率が悪い。
もちろんプログラミングも昔の EMS みたいなものだから面倒だけど。

前半の、4G以上のファイル全体をとりあえず mmapしちゃって、
あとはリニアにアクセスできれば楽っていうのは同意。
でも、それはデータベースの話じゃない。

>>777
ほとんどのOSでサポートされてることでも分かる通り需要はある。
一般ユーザはもちろん使ってないけど、世の中はそういうユーザ
ばかりではない。
そういうユーザは、当然64bit OSの方が嬉しい。

int a;
int *p = &a;
int *q = malloc(sizeof(int));
int *r = new int;

ってやったら、p,q,r の上32ビットに何が入ってますか？

人類の夢と希望

>>830
0xfffff800

マジレスすると、OS、OS のバージョン、そのコード実行時に
既に確保されているスタックやヒープのサイズに依存するので
それらを限定せずに質問しても全く意味がない。

Windowsの話は知らないけど、Linux/gccだとメモリモデルの指定なんてのが
あるんだね。
-mcmodel={small,kernel,medium,large}
16bit時代を思い出して、ちょっとほろ苦い気分だ。ｗ

>>830
ついでに
void func(void) {}
void *s = (void*) func;
して、sの値も調べてみよう。

>>834
それって、Am29000 依存のオプションでしょ。Linux じゃなくて
組み込み用途のプロセッサ、それももうほとんど使われてないやつ
だよ。

>>834
それ（smallとか）指定するとポインタの大きさが32bitになったりするん？

>>836
いやいや、それがx86-64用オプションなんすよ
http://gcc.gnu.org/onlinedocs/gcc-4.0.1/gcc/i386-and-x86_002d64-Options.html
の一番下あたりね

>>837
コードサイズのオプションみたい。ポインタサイズは常に64bitね。

>>833
たとえばx64でlink時、/LARGEADDRESSAWARE:NOｵﾌﾟｼｮﾝ付けたら

ﾜﾗﾀ
-mcmodel=large
〜Currently GCC does not implement this model.

int64 で64bit一発整数命令使って intとポインタが32bitのプログラミングモデルｷﾎﾞﾝﾇ

MIPS にはそういうのがあったな。N32って呼ばれてた。
(64bit ポインタは N64)

16->32bit移行時には far とか nearとかいらなかったんだよ。
大半のアプリは16bitに収まらなかったんだから。

むしろ32->64bit移行時に64bitポインタがほしいアプリのため
だけにlargeポインタキーワードを作ってほしかった。

大半のアプリは32bitで収まるんだから。やること逆だよエライ人

>>840
動的に確保されるメモリも下位2GBのメモリ空間に割り当てられる模様。
そのオプション付けると、VirtualAllocで2GB超の仮想アドレスを指定すると
エラーになる。

>>844
OSの作りを無視してアホな要求するな。

ハァ？アホな要求？
インラインアセンブラマンセー！！！

>>845
ｲｲｺﾄｷｲﾀ、thx!

ってことは、事実上64bitアプリでint32bitとポインタ交換する
コードはOKってことか

>>848
オッケーオッケー（＾＾）
int32にポインタを格納するのが「ツウ」ってことになるかもネ！

インラインアセンブラは良くても
int32にポインタを格納するような
処理系依存は許しがたし

windbg 6.5.3.7きましたよ

>>849
勝手にやれば。後で困るのはおまいらだし。

>>850
アセンブラの方が処理系依存

>>853
OS依存を重視するかCPU依存を重視するかという問題だな。ｗ
漏れの周りだとOSはWindows/Linux/MacOSいろいろ転がってるが、
CPUのほうは近い将来AMD64/EM64Tに統一されそうな勢いだ。
だからOS依存のポインタキャストよりはアセンブラのほうがマシと言え
なくもない。（８割くらいは冗談で書いてるからマジで突っ込むなよ）

>>854
インテルマックは64ビットＯＳなの？

>>855
最初は32bitで出るみたいだね。まぁ「近い将来」の話だから大目に見てくれ。ｗ

>>854
俺もマジで、x86系列でアセンブラ表記が統一されて欲しいと思ってるよ

でもWin64のＭＭＸ禁止は許せないね。アライメンがお気楽なのがx86の
いいところだったのにＸＭＭＸで代用しろといわれてもちとなあ…

>>856
つかさ、あぽーは何でアプリの互換性にあれほど気を払わないんだ？
今後10年はインテルに託すそうだけど、10年たったらまた組み直しかよ…

そんなこっちゃいつまでたってもアプリベンダは本腰入れないね

コンパイラなど存在しないかのような発言だな

マックのアプリはそのときのＣＰＵ向けに最大限の最適化をかけますからね
再コンパイルで簡単に移植できるとは限らないのですよ

>>859
実行形式での互換性が大事

>>860
そこまで持ち出さなくても、、、

同じWinでもフレームワークやミドルウエアが違えばいくら
コンパイラがあっても簡単に移行できないでしょ

ましてやOSが変わるんならお手軽移行は絶望的…
簡単に移行できた例ってありますか？

あとユーザーの立場から

OSが変わると買ったアプリは間違いなくアボン　Winでも
うまくいかない例は少なくないが、ぜんぜん増しである。

ユーザーは買ったアプリをリコンパイルできない。たとえその
アプリがリコンパイルするだけで移行できる優れものでも。

メーカーのサポート切れだともう打つ手なし。

客の買い替え意欲を激しく削がないか？　商売として正しいとは
とても思えないよ

前のアプリを救うための環境は毎度提供してますけどね。＞アップル

なんでマカがでてくんだよ
うせろ

>>864
アップルの話を書いただけで「マカ」呼ばわりするキチガイ発見

マックがプログラマに嫌われてることが証明されましたね。

マカのおかげで男の自信を取り戻したオレにはアップル嫌いとは言いにくい。
でもアップル嫌い。

OS XのAPIって64bitに対応していないって本当？

>>863
はたして今回はどうかな？　ある意味楽しみでもある。傍観しているだけだが

今までもエミュレーション環境を提供していたのは知っているけど、
どれほど有用だったのかは疑問

もう詳細が記事になってるよ

記事のURL貼ってください

Intel に移行した理由はノートPC用の省電力CPUのためだと
いう報道は複数出てたよね。
ノートPC 用の CPU である Pentium-M は今のところ 64bit
には対応してないし、Pentium-M の次世代である Yonah も
64bit に対応してないと言われている。従って、少なくとも
ノートPC は 32bit オンリーであると予想されるわけ。

２年後だと微妙だな。64bitのノート用Meromが出る。
かと言ってYonahでは使えませんとも言えない時期だし。

今度のマックはx86,x64が動くのか？　できればexeそのまま行けるのｷﾎﾞﾝﾇ

Intel Mac については、IA-32でやるということが明言されている。x64
になる予定は(今のところ)ない。もちろんPE(.exe)でもない。

たのむからexe動かしてくれ。そのほうがマックのためだ

>>876
今でもVirtual PCで動くが。ｗ
来年以降のCPUならVT(Virtualization Technology)装備だから高性能
Virtual PC(?)みたいなのが出ると思われる。別売りだろうけどね。

別売りじゃあ商売のプットフォームにならんぞえ

VTとパシフィカの仕様書を見る限りではそんなに性能が上がるとも思えないな

>>876
マックがWindows APIを搭載すれば可能

>>880
天才

ＷｉｎｅみたいなのをアップルがＭＳと提携して責任もって
組み込んでくれないかなあ。ＭＳにメリットあるか分からんが、
ＯｆｆｉｃｅＭａｃとかをＷｉｎ用のＯｆｆｉｃｅ作るだけでよくなるじゃん。

>>882
Windows無しでWindowsソフトが動くってのはMSにとっては危険思想だろうな。
アップルがWindowsをバンドルしてくれるんなら大歓迎だろうけど。

>>883
Ｍａｃの値段の中にWin23APIのライセンス料を組み入れるんですよ

アップルにとっても膨大なＷｉｎのアプリがそのまま動くのはライセンス料
ＭＳに払う価値があると思う。尚且つマックでしか動かないかっちょいいw
アプリが動くのなら変な物好きの食指は結構動いたりして

Win23->Win32orz

システム構成が既存 PC と大きく異なる上
市場全体から見ると誤差の範囲内のような Mac に
Windows を移植する意味があるのかどうか。
Office のときのような取引でもないとなあ。

昔の（つーても安価になってからの）Macは頭だけPowerPCで、
パーツはWin機と一緒なんじゃあなかったの？

で、今回頭もx86に…

>>884
膨大なごみアプリ群が幾ら動いても嬉しくない

大半の人間がごみアプリに金を払う

もう６４bitの話題は無いのか

>>882
Wineがらみだと下のような話も。
ttp://homepage3.nifty.com/toshi3/note10.html

MacBUが無くなるのはさびしいのでOfficeMacの開発は続けて欲しいなぁ。

DirectXはうごくのかー？

あと、LinuxでWine試したけどあまり快適じゃなかった。
自前アプリをWineで動くように調整してリコンパイルして…
で何とか動かしたけどガビガビだった。

１GHｚ素のWin　＞　３GHｚLinux+Wine

もちろんWineはすごいソフトだと思うよ

３００MHｚ素のWin　＞　３GHｚLinux+Wine　かも

Win64ってDirectXが動きますか？

>>894
動くよ。最新のSDK見れ。

実際動かした人いる？　64bit化の感想ｷﾎﾞﾝﾇ

マックは真の64bitなんだけどね。

マックのAPIって、64bitポインタ渡せるの？

何か Windows って無駄に大変なんだな...

>>899
それだけじゃわからん。何がどうWinに比べて良いのか書いてくれ

別に>>899はWindowsは大変とは言ってるけど、他のOSが変体じゃないとは言って無い。

>>898
UNIX的APIは64bitコードから呼べるが、GUI関係のAPIは32bitコードからしか
呼べない。そういう意味ではWin64より面倒くさいよ。

>>902
めんどくさいだけで64bitコードからGUI32bitコードを呼べるの？
そりゃあ大層便利なのでは？

>>903
呼べない。だからGUI部分は32bitコードで書いてプロセス間通信。

Σ（；ﾟдﾟ）ｶﾞﾋﾞｿ
なんだそれ…

GUI は GUI でも X11 系の方は 64bit でも呼べるよな。
Cocoa じゃなくて gtk 使えばぁ？
てゆうか、なんでそうなってんの？ わけわからん。

X11はソケット経由だから使えるんじゃないか

少なくとも NeXTSTEP の頃は、あのウィンドウシステムも
ソケット経由だった記憶があるけど (もちろんリモートから
もウィンドウを飛ばせました)、MacOS X だと違うの？

CocoaはJavaと使うな、っていう御触れが出たらしいね
Javaだったら64bit対応なんて考えなくていいのに・・・