5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

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

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

1 :デフォルトの名無しさん:05/02/23 10:12:55
無いので建ててみました。
32bitコードから、64bitコードへ移行する際の質問などなど
言語、OS問わずここでやりましょう。



2 :1:05/02/23 10:15:02
関連スレ
【AMD64】64ビットプログラミング【EM64T】
http://pc5.2ch.net/test/read.cgi/tech/1098018478/

3 :デフォルトの名無しさん:05/02/23 10:20:24
乙。ようやくまともな64ビットのスレが立ったな。

4 :デフォルトの名無しさん:05/02/23 10:23:58
【[x86-64】
の "[" は何?w

5 :デフォルトの名無しさん:05/02/23 10:29:58
エスケープシーケンス

6 :デフォルトの名無しさん:05/02/23 10:39:16
SPARCv9は?


7 :デフォルトの名無しさん:05/02/23 11:30:15
http://www.sparc.org/standards.html

8 :デフォルトの名無しさん:05/02/23 11:49:44
すれ立てるまでもない質問板で質問させていただいたのですが、このスレがたったので
こちらの方がふさわしいと思い再度投稿します。

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

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

10 :デフォルトの名無しさん:05/02/23 20:47:17
まあいいや。

まず、そもそも 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`

11 :デフォルトの名無しさん:05/02/23 20:48:33
詳しい仕様は下記にある。
ttp://www.unix.org/version2/whatsnew/lfs20mar.html
次からはUNIXスレに行くように。


12 :デフォルトの名無しさん:05/02/23 22:18:06
>>9-11
>>8 本人じゃないけど、どうもありがとう。


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

14 :デフォルトの名無しさん:05/02/24 04:55:08
  ̄ ̄ ̄ ̄ ̄ ̄○ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
           O 。
                 , ─ヽ
________    /,/\ヾ\   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
|__|__|__|_   __((´∀`\ )< というお話だったのサ
|_|__|__|__ /ノへゝ/'''  )ヽ  \_________
||__|        | | \´-`) / 丿/
|_|_| 从.从从  | \__ ̄ ̄⊂|丿/
|__|| 从人人从. | /\__/::::::|||
|_|_|///ヽヾ\  /   ::::::::::::ゝ/||
────────(~〜ヽ::::::::::::|/        = 完 =

15 :デフォルトの名無しさん:05/02/24 07:31:54
libcってどうやったら更新できますか?

16 :デフォルトの名無しさん:05/02/24 07:44:26
>>15
libcを更新するプログラムを作りたいという話?

17 :デフォルトの名無しさん:05/02/24 14:15:09
VC++の64bit版まだー チンチン

18 :デフォルトの名無しさん:05/02/24 14:17:02
C#へどうぞ

19 :デフォルトの名無しさん:05/02/25 20:16:45
Visual C++ 2005 っていつリリースなの?今年の夏ぐらい?

20 :デフォルトの名無しさん:05/02/26 00:21:12
マイクロソフトに聞いてこい

21 :デフォルトの名無しさん:05/02/26 02:21:56
もう出ないらしいよ

22 :デフォルトの名無しさん:05/02/26 05:57:19
>>1
重複

【AMD64】64ビットプログラミング【EM64T】
http://pc5.2ch.net/test/read.cgi/tech/1098018478/l50


23 :デフォルトの名無しさん:05/02/26 20:15:01
.NET2003のライブラリが入ってるPlatform SDKもまだβ。
Visual C++ 2005はそれより後。

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

25 :デフォルトの名無しさん:05/02/27 14:40:32
重複誘導

【AMD64】64ビットプログラミング【EM64T】
http://pc5.2ch.net/test/read.cgi/tech/1098018478/l50


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

27 :デフォルトの名無しさん:05/02/27 14:47:41
誘導厨氏ね。
スレタイに半角使ってるスレなんか認められねーんだよ。

28 :デフォルトの名無しさん:05/02/27 15:01:13
>>26
えーと、釣り?

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

29 :デフォルトの名無しさん:05/02/27 16:35:59
Itaniumはかつてのi860と同じ香りがしていたのだが、やはり・・
ってどっちが本すれなんだよ。はっきりしてくれ〜

30 :デフォルトの名無しさん:05/02/27 16:39:32
結論。ia64もx64もスレはいらない。
アセンブラスレとWin32、UNIXの専用スレで十分。

31 :デフォルトの名無しさん:05/02/27 16:52:59
IA-64とx64、普通にプログラムを書く分には、違いないだろ。

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

32 :デフォルトの名無しさん:05/02/27 17:03:45
>>1はMACヲタ

33 :デフォルトの名無しさん:05/02/27 17:28:43
GR00がRAXと同じ意味なの?

34 :デフォルトの名無しさん:05/02/27 19:29:27
x86-64って、名前の通りx86に64bitのレジスタと命令をちょっと付け加えた形だからなぁ・・・
わざわざ、別スレでする必要もないような・・・。

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


35 :デフォルトの名無しさん:05/02/27 20:02:28
Linuxにsh64っていう名前のコードが入ってるんだけど、
これって実際に使われてるの?

36 :デフォルトの名無しさん:05/02/27 20:36:48
どこのファイル?

37 :デフォルトの名無しさん:05/02/27 21:47:18
linux/arch/sh64

38 :デフォルトの名無しさん:05/02/28 01:57:46
別に32bitがなくなるわけでもない。
ポインタも今まで通り32bitで扱える。
何も恐れることはない。

39 :デフォルトの名無しさん:05/02/28 02:10:06


40 :デフォルトの名無しさん:05/02/28 02:45:42
>>39
何も恐れることはない。

41 :デフォルトの名無しさん:05/02/28 03:28:24
64bitに恐怖するスレはここですか?

42 :デフォルトの名無しさん:05/02/28 09:42:43
さすがに>>38は痛いだろ。
「64bitOS上で動く32bitアプリケーションを開発すること」を
「64bitプログラミング」とは言わない。

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

43 :デフォルトの名無しさん:05/03/01 00:23:47
Windowsはラクチンだね。ポインタしか変わらん。

44 :デフォルトの名無しさん:05/03/01 14:46:26
>>43
MS-DOSや、Window3.1の頃に比べると、隔世したねぇー
にゃーとか、ふぁぁああとか、説明無しに、にゃー使うときは、
ふぁーを使うときは、なんて言われて、絞め殺してやろうかと
思ったよ。



45 :デフォルトの名無しさん:05/03/01 17:56:09
WindowsはNT3.5の時点で既に64bit意識してたしねえ。
ゲイシは94年ぐらいに「5年以内にメインフレームのOSとしても
NTが使われるようになる」と宣伝してたなそういえば。

46 :デフォルトの名無しさん:05/03/01 18:15:23
まあx86系以外のCPUのWindowsもあったわけだし。

47 :デフォルトの名無しさん:05/03/01 18:32:14
>>44
いや、その頃は、8086だったから。CPUが糞だったから。

48 :デフォルトの名無しさん:05/03/01 18:33:00
あーでもプロテクトモードのWin3.1ってのがあったような記憶も・・・・
俺は使ってないからよくわからん。

49 :デフォルトの名無しさん:05/03/01 19:35:43
また昔話が始まるのか

50 :デフォルトの名無しさん:05/03/01 20:01:21
IA-64って主流になるのだろうか
無くなりそうなきがする

51 :デフォルトの名無しさん:05/03/01 20:59:28
コンスーマ向けのIA-64 windowsは作らないからなあ

52 :デフォルトの名無しさん:05/03/01 21:06:16
>>50
分野で生き残るって感じだと思う。
必要な環境では、x86互換命令の拡張命令程度であるx86-64では足りない事もあるだろうし。
俺だって、未だにMIPS系使ってたりするから…。


53 :デフォルトの名無しさん:05/03/01 21:54:33
>>45
実際99年には既にほとんどのCOBOLシステムは
NT上のエミュレータ上で動いていたし、今もそう。

54 :デフォルトの名無しさん:05/03/02 02:07:43
>>51
ンニー系列以外で コンスーマ って言い方するところはどこだっけ?

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

55 :デフォルトの名無しさん:05/03/03 04:02:15
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環境になっていくのかな。

56 :デフォルトの名無しさん:05/03/03 09:22:19
だから.Netにしろって言ってるんだろうな

57 :デフォルトの名無しさん:05/03/03 11:26:32
問題はデバイスドライバでしょ。
32bit版は動かないし、.Netにするわけにもいかないし。


58 :デフォルトの名無しさん:05/03/03 22:11:17
6〜7年プログラミングの現場から離れて
完全64bit化が達成されてから戻るのが正解


59 :デフォルトの名無しさん:05/03/04 01:55:42
テストが大変そうね。

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

60 :デフォルトの名無しさん:05/03/13 04:51:40
質問です。
EM64T対応のCPU使ってるんですが、アセンブラ使えば32bitのOSでも64bit化されたアプリケーション作れますか?

61 :デフォルトの名無しさん:05/03/13 05:02:57
それはクロスコンパイルのことかね?

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

62 :デフォルトの名無しさん:05/03/13 08:23:25
>>59
アセンブラで書いてベースを4GB以上のところに置くとかできないのかな。
ていうか64ビットでもセグメントってまだ残ってるの?

63 :デフォルトの名無しさん:05/03/13 11:04:38
無理

64 :デフォルトの名無しさん:05/03/13 20:08:18
まぁ、とりあえず4GBほど無駄にメモリを確保してから始めればいいのかもな。

65 :デフォルトの名無しさん:05/03/13 21:10:24
え、そういう問題かなあ・・

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

67 :デフォルトの名無しさん:05/03/13 23:09:33

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

68 :デフォルトの名無しさん:05/03/13 23:12:29
周りが見えてませんから。それがマカークオリティ。

69 :デフォルトの名無しさん:05/03/13 23:45:18
>>67
RAXを使うだけならリアルモードからでも出来ますが何か?

70 :デフォルトの名無しさん:05/03/14 00:00:30
これだもんね・・・

71 :デフォルトの名無しさん:05/03/14 00:53:33
まあ拡張レジスタ使って計算するだけならタスクスイッチで退避させるだけで対応できるわな。
64bitに限らずSSEでもOS側のサポートが必要だったのはそこなわけだし。

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

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

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

73 :デフォルトの名無しさん:05/03/14 02:01:36
マカーもマニュアルぐらいは読んでね。水なしで読んでね♪

74 :デフォルトの名無しさん:05/03/14 02:47:52
>>72
OSが対応しないと出来ないと書いたのだが
叩くことに必至でその程度も読み取れないのかね?

75 :デフォルトの名無しさん:05/03/14 02:51:22
本当にバカだね。
自分で>>69になんて書いたか、もう一度読み直してみてごらん。

76 :デフォルトの名無しさん:05/03/14 02:53:40
>>75
それ別人だから。
>>66には今のOSに手を入れないと無理って書いただけだから。

77 :デフォルトの名無しさん:05/03/14 02:57:36
レジスタの待避が必要なこと(OSの対応が必要なこと)と
16/32bitモードで64bit演算が出来ないこと
この2つには、何の因果関係もない。

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

78 :デフォルトの名無しさん:05/03/14 03:01:41
>>76
で、>>66はどれに対してのレス?
少なくとも、>>60の質問に対する>>61のレスは、
「32bitモードでは64bit演算は出来ない」という意味だよ。
「OSの対応」「レジスタの待避」の問題じゃない。

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

79 :デフォルトの名無しさん:05/03/14 03:11:51
要するに
Powerアーキテクチャ >>>>>>>>>>>>>>>>>>>> x86-64
ってことでよろしいか

80 :デフォルトの名無しさん:05/03/14 03:12:22
逆説的に、>>66がx86の64bit動作に関する知識が無いことは明らかで
それに対する>>67-68のレスは、極めて的確だった

というお話でした。

81 :デフォルトの名無しさん:05/03/14 03:15:59
祝!戦勝!!
アホマカ晒しage

82 :アホマカ:05/03/14 03:17:23
皆様ごめんなさい。どうすれば許してもらえますか?(涙目

83 :デフォルトの名無しさん:05/03/14 03:20:00
>>82
マックを捨ててAthlon64マシンを自作してリアルモードからRAXを操作してみたら許してやらないこともない。

84 :デフォルトの名無しさん:05/03/14 03:22:11
>>69=>>83

85 :デフォルトの名無しさん:05/03/14 03:23:57
茶目のつもりか知らんがかなりイタいな
>>67=>>68
>>72=>>73

86 :デフォルトの名無しさん:05/03/14 03:28:56
えーと、61=67=72=77=78だけど、
マカーをバカにしてるのは別の人だよ。
まあ、>>85が必死なのはわかったけど。

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

88 :69:05/03/14 03:35:15
>>84
俺じゃねえってヴォケ

89 :アホマカ:05/03/14 03:37:51
>>87>>88の変節ぶりにワロタ。
開き直りが肝心なのか。

90 :デフォルトの名無しさん:05/03/14 03:39:31
もういいから喪前ら糞して寝ろ

91 :デフォルトの名無しさん:05/03/14 03:41:02
遅めの昼飯を食い終わったところだが?

92 :デフォルトの名無しさん:05/03/14 03:42:15
            ↓糞マカ
              )
             (
         ,,        )      )
         ゙ミ;;;;;,_           (
          ミ;;;;;;;;、;:..,,.,,,,,
          i;i;i;i; '',',;^′..ヽ
          ゙ゞy、、;:..、)  }
           .¨.、,_,,、_,,r_,ノ′
         /;:;":;.:;";i; '',',;;;_~;;;′.ヽ
        ゙{y、、;:...:,:(`A´).:.、;:.,._、}
        ".¨ー=v ''‐ .:v、,,、_,r_,ノ′
       /;i;i; '',',;;;_~⌒¨;;;;;;;;ヾ.ミ゙´゙^′..ヽ 
       ゙{y、、;:...:,:.:.、;、;:.:,:.:. ._  .、)  、}
       ".¨ー=v ''‐ .:v、冫_._ .、,_,,、_,,r_,ノ′
      /i;i; '',',;;;_~υ⌒¨;;;;;;;;ヾ.ミ゙´゙^′.ソ.ヽ
      ゙{y、、;:..ゞ.:,:.:.、;:.ミ.:,:.:. ._υ゚o,,'.、)  、}
      ヾ,,..;::;;;::,;,::;):;:;:; .:v、冫_._ .、,_,,、_,,r_,ノ′

93 :デフォルトの名無しさん:05/03/14 03:43:56
つーか、基本的なことなんだけど、

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

94 :デフォルトの名無しさん:05/03/14 03:49:25
周りが見えてませんから。それがバカークオリティ。

95 :デフォルトの名無しさん:05/03/14 03:53:43
>>66>>79を言うためのマカーの釣りでしたとさ。

96 :デフォルトの名無しさん:05/03/14 03:55:21
ということにしたいのですね?

97 :デフォルトの名無しさん:05/03/14 04:00:16
手のひらを返して大漁とか言い出すのはマカーの常套手段

98 :デフォルトの名無しさん:05/03/14 04:13:39
まあ、x86の命令セット等がボロボロなのは今に始まった事じゃないし
殆どの人がその点は認めてるわけで
>>79の言うことはもっともだとは思う。

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

99 :デフォルトの名無しさん:05/03/14 04:28:39
美しさだけで言えば、最初から64bit前提で作られたIA64が綺麗なんじゃなかろうか。
x86はツギハギだしさぁ


100 :デフォルトの名無しさん:05/03/14 04:31:51
いまだー100ゲト■⊂(゚Д゚,,⊂⌒`つ≡≡≡ズザー

101 :デフォルトの名無しさん:05/03/14 05:51:43
longモードでなければ、RAXは使えません。
>>69はバカ

102 :デフォルトの名無しさん:05/03/14 15:13:36
馬鹿(マカ)

103 :デフォルトの名無しさん:05/03/14 19:34:31
>>99
インテルもそう思ってIA-64だったのだろうが、AMDにしてやられて
後追いをるはめに。RISCブームのころに結局x86が勝ち残ったのの再現。
前回とはインテルの役回りが違ってるけどね。

104 :デフォルトの名無しさん:05/03/14 20:25:24
オチケツ

105 :デフォルトの名無しさん:05/03/14 21:47:49
え、x86って現実的で美しいと思うよ。
R0とか番号振られるより
AX アキュームレーターとかわかりやすいじゃん。


106 :デフォルトの名無しさん:05/03/14 21:51:14
( ´,_ゝ`)プッ
そんなのニーモニックの問題だろうに・・・

107 :デフォルトの名無しさん:05/03/14 22:11:34
>>99
IA-64は、パフォーマンスを出すために、ごちゃごちゃ付いてて、あんまり綺麗じゃない。

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

108 :デフォルトの名無しさん:05/03/14 22:13:33
>>105
>>106
んじゃさ、ソース上でAXとCXを全部入れ換えてみ。

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

109 :デフォルトの名無しさん:05/03/14 22:15:29
スキャン防止のために三次元マスクかけた回路は綺麗?


110 :デフォルトの名無しさん:05/03/14 22:20:33
>>108
( ´,_ゝ`)プッ
何のために?

111 :デフォルトの名無しさん:05/03/14 22:31:11
A,B,C,D,E,H,Lは4004/8008からの名残りだよ

112 :デフォルトの名無しさん:05/03/14 22:36:36
ところで、綺麗の基準ってなに?


113 :デフォルトの名無しさん:05/03/14 22:50:00
Cell の SPE のアセンブリがどんなものか気になる。どっかに資料ない
かなあ。



114 :デフォルトの名無しさん:05/03/14 23:30:16
>>111
AFBCDEHL


115 :デフォルトの名無しさん:05/03/15 09:03:45
>>101
>>87

116 :デフォルトの名無しさん:05/03/15 11:20:55
2000DDKでAMD64向けにビルドしようとしても
amd64mk.incが無いってでてコンパイルできねー!!

117 :デフォルトの名無しさん:05/03/15 11:22:16
おっとXPDDKだった

118 :デフォルトの名無しさん:05/03/15 18:45:52
>>110
まぁとにかくやってみろよ。
入れ換えてアセンブルしてみればわかるからさ。

119 :デフォルトの名無しさん:05/03/15 18:49:33
A アキュムレータ
B ベース
C カウンタ
D データ

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

120 :デフォルトの名無しさん:05/03/15 19:04:56
>>119
当時は命令が直交していないって68系の人たちからだいぶいじめられた。

121 :デフォルトの名無しさん:05/03/15 19:27:03
WinXP x64 Editionで、v1433にしたらローカル カーネルデバッガが
使えなくなってしまいました。他の方はどうでしょ?

122 :デフォルトの名無しさん:05/03/15 20:08:29
6809もAとBで微妙に扱いが違ってた

123 :デフォルトの名無しさん:05/03/15 20:14:48
>>118
自分でやれよ

124 :デフォルトの名無しさん:05/03/15 20:19:58
x86はプリフィックスとかアドレッシングモードに苦労の跡が見えるね。
もう限界だろう

125 :デフォルトの名無しさん:05/03/15 20:43:46
x512ぐらいまでがんばるよ

126 :デフォルトの名無しさん:05/03/15 21:00:19
>>125
がんばれよwww

127 :デフォルトの名無しさん:05/03/15 21:04:29
>>120
実際、コンパイラの最適化の障害になるからね。

128 :デフォルトの名無しさん:05/03/15 21:32:31
死ぬまでにx128は見れるだろうか

129 :デフォルトの名無しさん:05/03/15 22:32:44
AMD128(10nm、量子演算対応モデル)
Quantron 15000000000000+

130 :デフォルトの名無しさん:05/03/18 00:42:28
あと2ヶ月くらいでx64 Windowsリリースですが、
C++ Builderって64bitコンパイラ出す気ないでしょ

131 :デフォルトの名無しさん:05/03/18 00:46:07
何か問題でも?

132 :デフォルトの名無しさん:05/03/18 01:15:28
ポトペターが困る

133 :デフォルトの名無しさん:05/03/18 01:46:32
困るわけが無いじゃないか

134 :デフォルトの名無しさん:05/03/18 05:35:21
EXE作る分には別に32ビットのままでいい。
そんな大きなメモリを扱うようなアプリを書かないから。

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

135 :デフォルトの名無しさん:05/03/18 13:19:33
>>130
すぐには出んかもしれんが、「そろそろ金になる」と思ったら出すのでわ?
C++Builder自体、32bitになってから相当遅れて出てきたし。

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

136 :デフォルトの名無しさん:05/03/18 23:26:49
確かDelphiって、IDEは当然Delphi製なんだけど
コンパイラが、BCCで作られていたはず。
って事は、(ソース的には当然互換性はあるだろうけど)
まず、C/C++コンパイラが無いと64bit版Delphiは出せない。

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

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

137 :デフォルトの名無しさん:05/03/19 00:00:41
>>136
そうなると、まず32bitのC++コンパイラで64bitDelphiを作り上げて、その後
ブートストラップ的に64bitC++コンパイラでも作るんかもしれんね。

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

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

138 :デフォルトの名無しさん:05/03/19 03:03:34
Borlandってやる気感じられない。なぜいまだに64Bitコンパイラの予定すらないのだろう?
Microsoftは送れているが予定はある。

139 :デフォルトの名無しさん:05/03/19 04:09:02
まぁ投入できる開発費が違うから。

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

140 :デフォルトの名無しさん:05/03/20 02:39:57
MSは.net2005で64bit対応じゃね?

141 :デフォルトの名無しさん:05/03/20 04:05:07
なんでやねん

142 :デフォルトの名無しさん:05/03/20 18:02:51
> って事は、(ソース的には当然互換性はあるだろうけど)
> まず、C/C++コンパイラが無いと64bit版Delphiは出せない。

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


143 :デフォルトの名無しさん:05/03/21 02:07:06
そういや、昔のBorland C++は、Win32アプリをDOS上でコンパイルしてたような希ガス。

144 :デフォルトの名無しさん:2005/03/26(土) 08:47:39
Win64(?)になった場合DWORDは32bitのままなのかね?
64bitにすんなり移植できるようなプログラムマナーのようなものきぼんぬ。
WindowsでC言語の場合です。

145 :デフォルトの名無しさん:2005/03/26(土) 09:56:00
>>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

146 :デフォルトの名無しさん:2005/03/26(土) 10:09:36
そういえば、VCTKで64bit移植性の警告みたいなオプションを付けたら
/W4で何も言わない、自分では64bit(Unix)への移植性も考慮しているつもりなコードに
滅茶苦茶警告が並んであせった覚えが。

147 :デフォルトの名無しさん:2005/03/26(土) 11:13:09
/W64か
おれもいろいろ直しまくったけど。

148 :デフォルトの名無しさん:2005/03/26(土) 11:43:27
64ビットでコンパイルすれば、自動的に2^32以上を扱えるプログラムになるかっていうと、
そんなに甘くはないんだよね。

149 :デフォルトの名無しさん:2005/03/27(日) 03:09:02
たしかMASMで倍精度浮動少数とMMXはQWORDだった覚えがあったのだけど
DWORD64ってなんだよ・・・

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

150 :デフォルトの名無しさん:2005/03/27(日) 03:10:53
あと、SSE*のDQWORDもどうかと思ったけどな。OWORDだろ、と。

151 :デフォルトの名無しさん:2005/03/27(日) 06:38:05
C99 なら int8_t/int16_t/int32_t/int64_t がC言語標準としてあるし、
ポインタを納められる整数型もintptr_tがあるから、これらを使えば
わざわざ自分で定義する必要はないと思う。
C89への移植を気にする場合は、これらの型定義を自分で提供する方向で。

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

152 :デフォルトの名無しさん:2005/03/27(日) 10:18:49
ちなみにstdint.hを独自に作るときには__w64を使えばINT_PTRなどに相当する型が作れる。
(/W64でも警告が出なくなる)

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

153 :デフォルトの名無しさん:2005/03/27(日) 12:27:16
そういやBeOSの64bit版は、64bitCPUで使うと2CPUとして認識するようになるらしいぞ。
32bitCPU2個で64bitだ!とか言ってたヤツの逆だなw
やっぱ64bitのレジスタを2つにわけるのかな?

154 :デフォルトの名無しさん:2005/03/28(月) 02:49:25
>>153
ワロタ
ソースは?

155 :デフォルトの名無しさん:2005/03/28(月) 03:08:24
クローズド・ソースです!!!

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

156 :デフォルトの名無しさん:2005/03/28(月) 09:25:53
>驚いたのは、64ビットCPUへの対応だ。同氏は「64ビットCPUは、32ビットのデュアルCPUとして認識する」という。

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

157 :154:2005/03/28(月) 13:12:40
>>155
サンクス

・・・ポカーン

158 :デフォルトの名無しさん:2005/03/29(火) 21:53:31
質問です。
32bitのDLLを64bitのアプリケーションから利用することは可能ですか?
私の開発環境はEM64Tです。

よろしくお願いします。

159 :デフォルトの名無しさん:2005/03/29(火) 22:33:46
ちょっと調べれば、あるいは
ちょっと考えれば
わかりそうなもんだけど。

160 :デフォルトの名無しさん:2005/03/29(火) 22:50:40
>>158
逆は無理だが一応できるはず。
少なくとも、何かの記事で見た。

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


161 :デフォルトの名無しさん:2005/03/29(火) 23:10:58
その「何かの記事」とは、10年ほど前の16/32環境のものだろう。

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

162 :デフォルトの名無しさん:2005/03/29(火) 23:31:56
64bit化が難しい場合は
COMにしてexeのサーバをおったてるのも手
MSもこれを推奨…

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

163 :デフォルトの名無しさん:2005/03/29(火) 23:37:34
外部ライブラリでもクラスライブラリでもなくDLLなのだから、DLLなんでしょう。


164 :デフォルトの名無しさん:2005/03/29(火) 23:44:01
おいおい、WIN64アプリからWin32のDLLの利用は可能だぞ?


165 :デフォルトの名無しさん:2005/03/29(火) 23:45:41
>>164
できません。

166 :デフォルトの名無しさん:2005/03/29(火) 23:47:06
Out-of-processコンポーネンとして利用できるとMS自身が公言している。

167 :デフォルトの名無しさん:2005/03/29(火) 23:49:42
>>158
OSはなんでしょう

168 :デフォルトの名無しさん:2005/03/29(火) 23:54:09
>>164
少なくとも、「簡単に」出来るのなら
64bit版WinXPに、32bit版IEが付属するなどという事態にはなりません。
これは、Flush等のプラグインが動かせない事が理由ですので。

169 :デフォルトの名無しさん:2005/03/30(水) 03:20:09
>>166
それの意味わかってる?

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

170 :デフォルトの名無しさん:2005/03/30(水) 05:11:34
難しい簡単の差はあるものの、実装できないと言うわけではないから
可能と言えば可能だろう。

171 :デフォルトの名無しさん:2005/03/30(水) 08:22:54
いや、単に「利用」と言ったら、通常はインポートライブラリなり
LoadLibraryなりdlopenなりして使うことをさすだろ。

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

172 :デフォルトの名無しさん:2005/03/30(水) 08:54:22
汚名を挽回するのか……。

173 :デフォルトの名無しさん:2005/03/30(水) 09:14:37
汚名挽回の起源はジェリドかと思っていたが
ちばあきおのキャプテン内で使われているのを最近読んだ。

174 :デフォルトの名無しさん:2005/03/30(水) 11:40:29
DCOMのアウトプロセスサーバは、あんまり良い思い出ないな・・・。

175 :デフォルトの名無しさん:2005/04/04(月) 13:59:19
もうすぐWindowsXP x64が出ますな。
こういうときに.NETアプリは便利だなぁ・・・
コード書き換え不要でそのまま64bitネイティブアプリ化するし・・・

176 :デフォルトの名無しさん:2005/04/04(月) 15:41:08
>>173へえ、そんな昔から銀英伝からかと思ってた

177 :デフォルトの名無しさん:2005/04/04(月) 20:31:38
>>175
中間言語をJITコンパイルするのは、ネイティブとは言わない!

178 :デフォルトの名無しさん:2005/04/04(月) 21:00:58
VC2005はいつになるやら

179 :デフォルトの名無しさん:2005/04/10(日) 16:52:49
五月出るらしいが。

180 :デフォルトの名無しさん:2005/04/10(日) 18:11:06
幸運な事にbit幅に依存するプログラムを書いたことがありません


181 :デフォルトの名無しさん:2005/04/10(日) 19:02:54
んなアホな

182 :デフォルトの名無しさん:2005/04/10(日) 22:26:48
5月に出るのはPSDKだろ

183 :デフォルトの名無しさん:2005/04/11(月) 00:46:17
PSDKって、OSよりも先にfixしてリリースされて来たとおもうけど。

184 :デフォルトの名無しさん:2005/04/11(月) 20:30:44
まだβでしょ。x64のは。

185 :デフォルトの名無しさん:2005/04/11(月) 21:28:12
ここはwindows専用ですか?

186 :デフォルトの名無しさん:2005/04/11(月) 22:03:49
>>1

187 :デフォルトの名無しさん:2005/04/12(火) 04:18:38
AMDのACMライブラリのWin用の64bit版ってまだ出てない?
Linuxのみ?

188 :デフォルトの名無しさん:2005/04/12(火) 05:25:54
>>180
えっ? intが16ビットになったら困るコード書いたこと無いの?
int変数に32768(unsignedなら65536)以上の値を入れたこと無いの?

189 :デフォルトの名無しさん:2005/04/12(火) 06:44:05
今Winsockでプログラムを組んでるのですが
64bitアプリからは32bitDLLは呼べないんですよね?
と言うことは、64bit用のWinsockで再コンパイルし直さないといけないのでしょうか?
また、64bitのWinsockはもう公開されてますか?


190 :デフォルトの名無しさん:2005/04/12(火) 09:36:12
> 64bitアプリからは32bitDLLは呼べないんですよね?
呼べます。

終了〜。

191 :デフォルトの名無しさん:2005/04/12(火) 14:24:03
64bit用C++Builderはいつ頃出るのでしょうか?

192 :age:2005/04/12(火) 14:39:37
>>191
米Borlandのニュースグループで尋ねてみては?

193 :デフォルトの名無しさん:2005/04/12(火) 15:27:43
>>190
また大嘘かよw
>>164と同じやつか?
質問者騙して楽しい?


194 :デフォルトの名無しさん:2005/04/12(火) 16:51:26
>>173 どうでもいいけど。
30年位前の消防向け国語辞典冒頭の読み物にあった。

195 :デフォルトの名無しさん:2005/04/12(火) 17:14:26
>>189
普通に64ビットでコンパイル・ビルドすればOK。
意識しなくても自動的に64ビット版のDLLを使ってくれる。

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


196 :デフォルトの名無しさん:2005/04/12(火) 17:14:48
>>190
インプロセスでは呼べないぞ。

197 :デフォルトの名無しさん:2005/04/12(火) 20:58:32
Win9xのLoadLibrary16みたいな隠しAPIはないのだろうか。

198 :デフォルトの名無しさん:2005/04/12(火) 21:44:04
下手するとまた裁判沙汰になるからなあ

199 :デフォルトの名無しさん:2005/04/12(火) 21:50:52
今回はサンクレイヤーで処理してくれないのかね

200 :デフォルトの名無しさん:2005/04/13(水) 01:10:13
64bit版のWinsockって高速化してたりするんだろうか?
32bit以上の値のコピーを1度に出来るとかで、色々速くなってそうな気がするんだけど・・・

201 :デフォルトの名無しさん:2005/04/13(水) 02:04:47
メモリコピーを速くしたければ、SSE2使うという手が。

202 :デフォルトの名無しさん:2005/04/13(水) 02:52:55
GbE転送ベンチでもしてみないことには分からんのとちゃうかなー

203 :デフォルトの名無しさん:2005/04/14(木) 17:53:39
byte benchmark では、x86_64 の方が明らかに速いみたいよ。
メモリフットプリントが増えるのはかえって不利な要素の筈
だけど、レジスタが多いのが効いているんじゃないかという
希ガス。

204 :デフォルトの名無しさん:2005/04/14(木) 23:53:16
NICチップとのデータ転送がネックだったらあんまり関係ないような。
IntelのとかだとNICチップ上でいろいろ計算してくれるし...

205 :デフォルトの名無しさん:2005/04/17(日) 13:17:18
さて、そろそろX64版WindowsXPが出るわけだけど
現状64bitアプリを開発できるVC++系の環境ってない?
2005は、なんかもう落とせなくなってるし・・・

206 :デフォルトの名無しさん:2005/04/17(日) 13:37:10
gccがPE32+扱えないからなぁ・・・

207 :デフォルトの名無しさん:2005/04/17(日) 18:26:37
じゃあ、現状無料で手に入る64bitネイティブコードをはき出すコンパイラは無し?
・・・そりゃ、普及しないわけだ・・・

208 :デフォルトの名無しさん:2005/04/17(日) 18:37:32
一応PlatformSDKがあるが・・・
しかし、これ落としてもMFC使えないんじゃなぁ・・
VS 2003.NET使ってるが、2005が出たら速攻乗り換えなければならん・・・。

209 :デフォルトの名無しさん:2005/04/17(日) 18:57:21
PSDKのコンパイラって、MFCコンパイルできないの?

210 :デフォルトの名無しさん:2005/04/17(日) 19:43:45
>>207
まだ出てもいないのに、
普及しないわけだと結論だすのもどうかと思うが。
ということにしたいだけなのかな?

211 :デフォルトの名無しさん:2005/04/17(日) 19:44:41
現段階で試験的にもっと出回っててもおかしくないのに普及してないってことだろ。


212 :デフォルトの名無しさん:2005/04/17(日) 19:51:31
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では動いたのに。

213 :デフォルトの名無しさん:2005/04/18(月) 17:24:33
MSDNでVS 2005beta2出てるよ。


214 :デフォルトの名無しさん:2005/04/19(火) 09:13:52
おまいらは、普通に32ビットアプリを書いていればよし。
何が理由で64bitでビルドするの?

215 :デフォルトの名無しさん:2005/04/19(火) 14:32:05
そこに64bitがあるからだろ

216 :デフォルトの名無しさん:2005/04/19(火) 22:02:21
215がいいこと言った

217 :デフォルトの名無しさん:2005/04/19(火) 22:34:26
えーと64bitだと符号なしでどの位の整数が表せるんだっけ


218 :デフォルトの名無しさん:2005/04/19(火) 23:01:33
10エクサぐらい

219 :デフォルトの名無しさん:2005/04/19(火) 23:20:34
零から壱千八百四十四京六千七百四十四兆七百参十七億九百五十五万壱千六百壱拾五まで

220 :デフォルトの名無しさん:2005/04/20(水) 00:57:03
32ビットだとオーバーフローを気にしながらコーディングするが、
64ビットだと、事実上無限大だと思って気にしなくなって、
あとで悲惨なことになりそうだな・・・。

221 :デフォルトの名無しさん:2005/04/20(水) 01:40:55
つまり1バイトが64ビットになるの?

222 :デフォルトの名無しさん:2005/04/20(水) 02:00:54
そんなエサで俺様が(ry

223 :デフォルトの名無しさん:2005/04/20(水) 08:14:11
ディスクのサイズはとっくの昔に4Gじゃ足りなくなってるし、
メモリもそろそろ4Gじゃ足りないからでそ。

224 :デフォルトの名無しさん:2005/04/20(水) 13:05:25
純粋にメモリ空間足りないから。。。
Windowsプロセスでユーザが使えるの2GBにも満たないし、もう窮屈だよ

225 :デフォルトの名無しさん:2005/04/20(水) 13:17:00
初心者ほど高価な道具を欲しがる。


226 :デフォルトの名無しさん:2005/04/20(水) 13:47:50
64bit環境は別に高価ではないが?
手軽に64bitを試せるんだから各々好きにやればいいジャマイカ


227 :デフォルトの名無しさん:2005/04/20(水) 14:49:46
>>224
1プロセス2GBで足りなくなるって、すごいプログラム書いてるんですね。

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

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

228 :デフォルトの名無しさん:2005/04/20(水) 15:36:15
Windowsのx64 Editionはコンテキストスイッチの際に
FPU レジスタを保存しないって本当ですか?

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

229 :デフォルトの名無しさん:2005/04/20(水) 16:17:39
64bitモードではSSE使えよ

230 :デフォルトの名無しさん:2005/04/20(水) 16:59:54
インラインアセンブラでx87を使っているWin32アプリを64bitに移植する場合、
x87をSSE2で書き換えなければならないのかと思って聞いてみた次第。

231 :デフォルトの名無しさん:2005/04/20(水) 21:38:38
>Windowsのx64 Editionはコンテキストスイッチの際に
>FPU レジスタを保存しないって本当ですか?

つか、これのソースは?


232 :デフォルトの名無しさん:2005/04/20(水) 21:57:28
ごめんなんでもない。>>231はなかったことに・・・

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

233 :デフォルトの名無しさん:2005/04/20(水) 22:16:32
64ビット化! 64ビット化! 
さっさと64ビット化! 
しばくぞ!


234 :デフォルトの名無しさん:2005/04/21(木) 02:06:11
x64のLONGモードは、x87をサポートしてない、ってどこかで読んだけど。

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

235 :デフォルトの名無しさん:2005/04/21(木) 02:23:36
MMXもね。Intel C++もVC++もそうじゃないの。

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

236 :デフォルトの名無しさん:2005/04/21(木) 05:19:08
x87がネックなのはいいとして、
SIMDでもないものまでSIMDで計算するっていうのも豪快だよね。

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

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

237 :デフォルトの名無しさん:2005/04/21(木) 13:02:34
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とかコンパイラがあまり吐いてくれない命令を使ってまふ。


238 :デフォルトの名無しさん:2005/04/21(木) 14:43:56
>>236
XMMレジスタ使ってスカラー演算するだけじゃないの?
ADDSS とか ADDSD みたいな

239 :デフォルトの名無しさん:2005/04/23(土) 07:01:58
AMD64の古いコアだと、LONGモードでもx87レジスタはコンテキスト
スイッチの際退避されるみたい。
OSの仕様上保障はされていないけどね。

240 :デフォルトの名無しさん:2005/04/23(土) 10:44:13
>>239
FPUレジスタが退避されるのはWOW64上で32bitアプリ(16bitアプリも)を
動かしたときだけかと思われ。
レジスタの退避はOSの仕事なのでコアの新旧は関係ないでしょ。

241 :デフォルトの名無しさん:2005/04/23(土) 11:57:43
Windows XP Professional x64 Edition 発売記念あげヽ(`Д´)ノ

242 :デフォルトの名無しさん:2005/04/23(土) 15:33:38
>>239
うちはC0コアだけど、確認しました。
これはfast fxsave/fxstoreのあるなしの関係かな?

243 :242:2005/04/23(土) 16:16:11
確認に使ったプログラムです。
これを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);
}
}

244 :242:2005/04/23(土) 16:16:57
.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

245 :デフォルトの名無しさん:2005/04/23(土) 17:44:22
>>242
勘違いしていないか?
fast fxsave/fstorは、XMMレジスタについて保存復元を「しない」
ものだよ(LONGモードかつRING0でのはなしね)

246 :242:2005/04/23(土) 17:58:46
>>245
あらーw
242-244は忘れてください。

247 :デフォルトの名無しさん:2005/04/23(土) 18:42:59
>>243-244を実行してみたけど、x87ステートも保存しているよな。
なぜ? xp x64の製品版はどうなんだろ。

248 :デフォルトの名無しさん:2005/04/23(土) 19:09:11
誰かXP x64買ったか?

249 :デフォルトの名無しさん:2005/04/23(土) 19:09:52
キニスルナ!!

250 :デフォルトの名無しさん:2005/04/23(土) 19:10:29
おまえらとりあえずPDF読めば?

251 :デフォルトの名無しさん:2005/04/23(土) 19:29:26
>>250
読んだ上で言っています。

252 :デフォルトの名無しさん:2005/04/23(土) 20:34:32
>>247
プログラマが反抗したい年頃だったから。

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


254 :デフォルトの名無しさん:2005/04/23(土) 20:51:21
>>253
これ使えば
http://www.microsoft.com/whdc/DevTools/Debugging

255 :デフォルトの名無しさん:2005/04/23(土) 22:55:10
>>254
サンクス子
あとで試してみます

256 :デフォルトの名無しさん:2005/04/24(日) 06:24:54
>>253
VS2005のコンパイラはインラインアセンブラ使える?
ddk付属のx64版clやIntelC++だと使えなくなっているんだけど。

257 :デフォルトの名無しさん:2005/04/24(日) 13:20:46
>>256
駄目ですた。>インラインアセンブラ

VSのドキュメントにも

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

と書いてますた。

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

まだ64bitのSDKはないの?


259 :デフォルトの名無しさん:2005/04/24(日) 15:24:39
あれ?32bitのIEでもだめだわ・・・
どうしよう・・・・。

260 :デフォルトの名無しさん:2005/04/24(日) 16:02:50
VS2005β2に入っているPSDKならWinSock使えるけど?

261 :デフォルトの名無しさん:2005/04/24(日) 16:15:50
なんでWinsockないの?

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

262 :261:2005/04/24(日) 16:18:01
ちゃんとIA64のディレクトリにWS2_32.libがあるぞ。

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

263 :デフォルトの名無しさん:2005/04/24(日) 17:07:25
本当だ
俺もVC++2005で何か作ろうと思ったら
Winsock2.hやwindows.hがないって言われた。
標準装備じゃないの?

264 :デフォルトの名無しさん:2005/04/24(日) 17:49:16
PlatformSDKに統一するとか言ってた気がする
VC++自身には含まれなくなったんじゃないかなあ

265 :デフォルトの名無しさん:2005/04/24(日) 18:07:30
>>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


266 :デフォルトの名無しさん:2005/04/24(日) 21:02:53
統一できてないじゃん・・

267 :デフォルトの名無しさん:2005/04/24(日) 21:25:45
>>265
新しいml64ではx87命令が使えなくなってますな。

268 :デフォルトの名無しさん:2005/04/24(日) 21:39:48
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'
こんなエラーが・・・。


269 :デフォルトの名無しさん:2005/04/24(日) 22:15:11
VS2005 beta2ってMSDN入っていなくてもDL出来るの?
なんかCD購入(CDはタダだけど送料がかかる)画面にいっちゃうん
だけど。

270 :デフォルトの名無しさん:2005/04/24(日) 22:26:41
>>269
Express以外はDLできない。お布施がいやなら雑誌にでも載るの待ちましょう。
注文したほうが安そうだけど。

271 :デフォルトの名無しさん:2005/04/24(日) 23:20:24
>>268
VCが対応してないからな。
一般公開のだと、Win32しか選べないと思う。
リンクの設定だけ、それにしても無理

272 :デフォルトの名無しさん:2005/04/24(日) 23:27:34
俺もX64プログラムのmake方法がわからん。
正直まとまった資料が無いんだよな。
多分ここがX64ネイティブアプリが増えない最大の理由のような・・・

273 :デフォルトの名無しさん:2005/04/24(日) 23:37:44
コマンドラインでHello Worldも作れないんか?

274 :デフォルトの名無しさん:2005/04/24(日) 23:46:54
Cマガジン2004年10月号に64ビットプログラミングの特集があって
VisualStudio.NET/.NET2003/6.0のいずれかとPlatformSDKの組み合わせか
VisualStudio2005βを使うって載ってるから使えそうなんだけど、駄目そう?
環境設定方法が載ってるから試したいんだけど、時間がない。。。

275 :デフォルトの名無しさん:2005/04/24(日) 23:53:45
関係ありそうなところを写してみる。
プロパティの[C/C++]、[全般]、[デバッグ情報の形式]を[プログラム データベース (/Zi)]。
プロパティの[リンカ]、[コマンドライン]、[追加のオプション]に[/machine:AMD64]。
うまくいきます?

276 :デフォルトの名無しさん:2005/04/25(月) 00:56:38
>>275
それでやってみましたけど
.\Release\stdafx.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
と出ますね。
VC++2005エクスプレスBeta2と>>265の組み合わせです。


277 :デフォルトの名無しさん:2005/04/25(月) 01:10:38
>>269
注文した。DDKの時は配送料$15だったのに、今回は$20。ナジェ?

278 :デフォルトの名無しさん:2005/04/25(月) 02:04:16
>>276
書くだけじゃなんなんで、VS2003でやってみました。そして駄目でした。
Cマガに書いてあった内容も、
http://www.amd64dev.com/kaihatu/document/30887.html
と同じで特別なことは書いてないみたいで。すまんです。

279 :デフォルトの名無しさん:2005/04/25(月) 04:28:40
Makefileくらい書いたらいいじゃん。

280 :デフォルトの名無しさん:2005/04/25(月) 06:15:57
>>276
/machine:amd64をリンカ オプションにつけても駄目?
うちはVC6.0でうまくいったけど。

281 :デフォルトの名無しさん:2005/04/25(月) 08:33:58
>>280
275で書いてあるじゃんw


282 :デフォルトの名無しさん:2005/04/25(月) 23:01:40
18446744073709551616

283 :275:2005/04/28(木) 23:34:30
時間ができたんで、今日改めてやってみたらコンパイルできました。
方法は278のリンク先の内容プラス、bufferoverflowU.libをリンクしたくらい。

284 :デフォルトの名無しさん:2005/04/29(金) 12:10:33
DirectX SDK入れようと思うんですけど
WinXP X64用のSDKって出てますか?
32bitのでOK?

285 :デフォルトの名無しさん:2005/04/29(金) 15:04:59
SDLをx64向けにmakeしようとしたら
インラインアセンブラ使ってるおかげでエラー吐くね。。。

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


286 :デフォルトの名無しさん:2005/04/29(金) 15:16:02
前後の最適化で邪魔になるから

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

287 :デフォルトの名無しさん:2005/04/29(金) 15:17:41
淫乱部分がないと、VM書いたりスタックいぢりたいとき大変じゃねー?


288 :デフォルトの名無しさん:2005/04/29(金) 15:57:08
SDLのインラインアセンブラはCPUID検出用かぁ・・・
コンパイラ標準のに差し替えれればすぐに出来るんじゃないかな

289 :デフォルトの名無しさん:2005/04/29(金) 17:25:28
http://www.amd64dev.com/kaihatu/document/30887.html
ここの方法だと、既にあるプロジェクト毎に開いてRelease64を追加しますけど、
あらかじめRelease64を普通のReleaseのように選択出来るように設定する事は出来ないんでしょうか?
プロジェクト変えるたびに設定しなおすのが大変です。

290 :デフォルトの名無しさん:2005/04/29(金) 19:53:09
CPUIDなんて直に書くなよ。

__cpuid

どぞ〜

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

292 :デフォルトの名無しさん:2005/04/30(土) 00:17:24
FAQっぽいんだけど、
32ビットと64ビットを判別して、それぞれのEXEをキックしなおすの、どうやってます?

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

293 :デフォルトの名無しさん:2005/04/30(土) 00:19:56
32bitのexeの中に2つのバイナリを格納しておく。

294 :デフォルトの名無しさん:2005/04/30(土) 00:24:57
>>293
PEでMach-OのFATみたいなことできるの?

295 :デフォルトの名無しさん:2005/04/30(土) 04:05:58
ローダー自作でもしない限り無理じゃないか?
Winは再配置できないし、


296 :デフォルトの名無しさん:2005/04/30(土) 04:47:48
最初にロードされる部分が32ビットなら、ずっと32ビットなんじゃないか?
32ビットから64ビットに移行するAPIがあるならともかく。

297 :デフォルトの名無しさん:2005/04/30(土) 07:08:08
実行ファイルを作り出して、プロセスを起動。

298 :デフォルトの名無しさん:2005/04/30(土) 15:33:23
むぅ・・・
コンソールやライブラリは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



299 :デフォルトの名無しさん:2005/04/30(土) 17:24:03
>>298
>プロジェクト 'mfctest64'、構成 'Release64|Win32' の中間ファイルおよび出力ファイルを削除しています。
                           ~~~~~
( ゚,_・・゚)ブブッ

300 :デフォルトの名無しさん:2005/04/30(土) 17:47:03
>>298
リンクに失敗してるだけじゃん。
あともう一息だね!

301 :デフォルトの名無しさん:2005/04/30(土) 18:08:50
>>298,300
>warning C4005: '_WIN32_WINDOWS' : macro redefinition

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



302 :デフォルトの名無しさん:2005/04/30(土) 18:19:30
そんなの理由なんてないよ!
あともう一息だね!

303 :デフォルトの名無しさん:2005/04/30(土) 18:22:27
理由があるから警告が出るんだよ。

304 :デフォルトの名無しさん:2005/04/30(土) 19:00:09
おまえに生きてる理由なんてあるのか?

305 :デフォルトの名無しさん:2005/04/30(土) 19:05:34
>>298=300=302=304
必死だな。w
お前が64bitプログラミングに挑戦するのは
珍子の皮が剥けてからでいいと思うよ。
m9(^Д^)プギャ―――ッ

306 :デフォルトの名無しさん:2005/04/30(土) 19:12:00
理由が無くても生きていける!

307 :デフォルトの名無しさん:2005/04/30(土) 20:52:10
まぁ、一番的外れなのは>>299だけどな。

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

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

309 :デフォルトの名無しさん:2005/04/30(土) 22:46:28
>>308

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

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

310 :デフォルトの名無しさん:2005/04/30(土) 22:57:24
まぁ、一番馬鹿なのは>>307だけどな。

311 :デフォルトの名無しさん:2005/04/30(土) 23:52:52
>>309
VS2003+PSDKな組み合わせだとX64の項目無いからね。
前にちゃんとコンソールで64bitバイナリ吐けたなら、多分そこの設定は間違ってないかと


312 :デフォルトの名無しさん:2005/05/01(日) 00:49:04
・WIN64マクロが定義されていない(WIN32マクロのまま)
・MFCの64bitインポートライブラリにリンクしていない

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

313 :デフォルトの名無しさん:2005/05/01(日) 01:07:20
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でデバッグも出来ます。

314 :デフォルトの名無しさん:2005/05/01(日) 01:13:29
>>313
いや、MFCアプリケーションのことを言っている訳で。

315 :デフォルトの名無しさん:2005/05/01(日) 02:02:50
>>314
MFCですよ。

316 :デフォルトの名無しさん:2005/05/01(日) 04:57:49
>>315
誰もそんな事は聞いてない
帰りたまえ

317 :デフォルトの名無しさん:2005/05/01(日) 07:03:22
>>313
MFCのReleaseビルドはうまくいくんですが、Debugビルドだと
実行時にMFC42D.DLLがないというダイアログが出てきてしまいます。
どうやってデバッグしているんですか?


318 :デフォルトの名無しさん:2005/05/01(日) 07:55:24
愛と勇気で

319 :デフォルトの名無しさん:2005/05/01(日) 08:03:35
>>317
スタティックライブラリをリンクするようにすればいいとおもいます。
VC6だったら、プロジェクトの設定の一般タブでMFCのスタティックライブラリを使用を
選択します。

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

320 :デフォルトの名無しさん:2005/05/01(日) 14:16:42
う〜む、すいません。
どうしてもMFCだけmake出来ないんですが
IDEの設定はこんな感じです。
何かありましたら指摘お願いします。

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


321 :デフォルトの名無しさん:2005/05/01(日) 16:14:11
Visual Studio 2005 Beta 2 を使いましょう。

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

322 :デフォルトの名無しさん:2005/05/01(日) 16:16:16
なんか変なのが住み着いたな。
2005じゃ配布出来ないだろう。

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

323 :デフォルトの名無しさん:2005/05/01(日) 16:30:17
>>322
Beta2からGo-Liveライセンスが適用されるようだが?

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

324 :デフォルトの名無しさん:2005/05/01(日) 16:46:19
Visual Studio 2005 Beta 2は今すぐだとMSDN入ってないと入手できないからねー。
申し込みでのCD送付は6月予定だし、CD付属雑誌の発売も早くて5月中旬だったかな?
どのみち、アホはスルーで。

325 :デフォルトの名無しさん:2005/05/01(日) 19:52:05
なんか265のPSDKのISOインストールしたんだけど、それからというもの
Windows起動時に毎回Setup Wizardが出てくるようになったんだけど、自分だけ?
スタートアップフォルダも、レジストリのRunにも登録されてなさそうなんだけど…。

326 :デフォルトの名無しさん:2005/05/02(月) 00:18:07
実はインストールしたと思いこんでいるだけで
Setupをまだしてないとか

327 :デフォルトの名無しさん:2005/05/02(月) 21:24:29
>>320
その設定で>>298のエラー出るのは変
なんか、コンパイラオプション間違ってないか?
変なもんリンクしたとか・・・

328 :デフォルトの名無しさん:2005/05/03(火) 02:30:39
公開されているpsdkのmfcは、バージョン4.2にしか対応していないんじゃないの?
psdkのライブラリ見ていたらそんな感じがしたんだけど。

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

329 :デフォルトの名無しさん:2005/05/03(火) 18:10:30
x64版Windows向けのCgコンパイラって出ないのかな?
nVIDIAってAMD64推進派っぽいし、もう直ぐでそうだけど・・・
Linux版は確かあったよね?

330 :デフォルトの名無しさん:2005/05/03(火) 18:24:32
hgjklkl

331 :おこk:2005/05/03(火) 18:37:55
すいません、リンクをクリックしたら色が変わりますが、
あの色を変えないようにするスタイルシートを教えて下さい。
ほんっとどんな単語で検索していくら探しても見つからないんです。

332 :デフォルトの名無しさん:2005/05/03(火) 20:07:18
>>331
板違いだ。W3C逝け間抜け。

333 :デフォルトの名無しさん:2005/05/05(木) 18:42:57
#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

}

334 :デフォルトの名無しさん:2005/05/05(木) 18:43:54
int main(void)
{
*(DWORD *)addr1 = aaa;

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

_asm
{
call fword ptr addr1
}

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

return 0;
}

335 :デフォルトの名無しさん:2005/05/05(木) 18:49:26
↑WOW64上のWin32から64bitモードに切り替えることが
出来るみたいなんだけど、何かに使えない?

336 :デフォルトの名無しさん:2005/05/05(木) 19:09:21
>>335
スペースが削られているところがあって、なんじゃらほいとおもったけど。
何も役に立たないんじゃないの?

337 :デフォルトの名無しさん:2005/05/05(木) 22:56:49
MFCの64bit化まだ〜?
このスレでも既出だけどVS2003で使えなくて困ってる。
2005買えって事なのかな?

338 :デフォルトの名無しさん:2005/05/05(木) 23:24:16
俺もMFC使えんと話にならんから64bit化は遊びでもやってない。
MFCの64bitソースはあるのに使えないとかMSは何考えてるんだ?2005買わせるための作戦か?


339 :デフォルトの名無しさん:2005/05/06(金) 00:50:56
32ビットアプリも動くんだから
わざわざ64ビットで作る必要もない。

340 :デフォルトの名無しさん:2005/05/06(金) 02:16:32
そんな事言ってると、Win98時代くらいまでだったら、16bitアプリも動くんだから、わざわざ32bitアプリを作る必要もない
って言ってるのと変わらんて。
64bit上で動かす限り、ネイティブなアプリケーションを開発しようとするのは自然なこと。

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

341 :デフォルトの名無しさん:2005/05/06(金) 03:01:11
64ビットアプリから
Win32API を使うことはできますか?

342 :デフォルトの名無しさん:2005/05/06(金) 09:12:11
>>340
Windowsの16ビットと32ビットは、天と地ほどの差があるんですけど・・・。

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

343 :デフォルトの名無しさん:2005/05/06(金) 09:44:05
少なくとも、このスレ的には
x86の64bitモードの、レジスタ増加による優位性は明らかですが。

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

344 :デフォルトの名無しさん:2005/05/06(金) 10:51:44
>>343
プリエンプティブなOSで、その増えたレジスタの待避に時間がかかり、
かえって遅くなる事もある。x86は近頃のCPUにしては設計が古い
のでレジスタが少なく、コンテキスト切り替えに有利だった。

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

345 :デフォルトの名無しさん:2005/05/06(金) 11:40:21
レジスタが増えたことによるメモリアクセスの減少数に比べたら、
コンテキストスイッチうんぬんなんて、まったく問題にならないと思うけど。


346 :デフォルトの名無しさん:2005/05/06(金) 15:26:42
>>345
32bitアプリを動かすならコンテキストスイッチングのオーバーヘッドは問題に
なるかもしれんが、64bitアプリなら初めから関係ないね。というか、仮想32
みたいなモードを使っているのなら、32bitでも遅くならないはず。

347 :デフォルトの名無しさん:2005/05/06(金) 15:28:00
あんな古臭い糞FPUはイラネ

348 :デフォルトの名無しさん:2005/05/06(金) 15:29:12
64bitプログラミング総合スレ

349 :デフォルトの名無しさん:2005/05/06(金) 16:58:17
>>344
たまにその手の知ったか発言をするアフォが痛い
その程度のコンテキスト切り替えオーバーヘッドが問題になるってどんなCPUだ

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

351 :デフォルトの名無しさん:2005/05/06(金) 17:46:55
>>350
どんなコーデックだい? 整数主体? 実数主体?
教えて呉呉

352 :デフォルトの名無しさん:2005/05/06(金) 18:08:58
とりあえずzlibは2倍程度のパフォーマンスだと
どこかで見たような。

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

354 :デフォルトの名無しさん:2005/05/07(土) 00:49:21
>>344
それはどういうOSで?

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

1秒間に数万回。

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

355 :デフォルトの名無しさん:2005/05/07(土) 00:54:47
>>354
HP-UNIX(ハイパープリエンプティブ・UNIX)。
一秒に一億回のコンテキストスイッチング。

356 :デフォルトの名無しさん:2005/05/07(土) 01:46:59
して、それはx86で動いてるの?
さらに、x86-64でも動かす予定があるの?

357 :デフォルトの名無しさん:2005/05/07(土) 03:01:46
>>344
> x86は近頃のCPUにしては設計が古いのでレジスタが少なく、
> コンテキスト切り替えに有利だった。

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

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

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

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

358 :デフォルトの名無しさん:2005/05/07(土) 03:33:01
>>352
あのzlibはAMDが配布したもので、疑惑があるらしい。
http://www.x86-secret.com/index.php?option=newsd&nid=837

359 :デフォルトの名無しさん:2005/05/07(土) 12:12:21
64ビットでプログラミングしてみたが、あまり変わらん・・・・
当たり前かw

360 :デフォルトの名無しさん:2005/05/07(土) 17:56:26
__int64をサポートした32ビット環境を使ってると、代わり映えはしないね。

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

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

361 :デフォルトの名無しさん:2005/05/07(土) 18:29:12
>>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秒

362 :デフォルトの名無しさん:2005/05/07(土) 19:43:30
> Itaniumのレジスタは、実質的には32本です。
> レジスタというよりは、スタック専用キャッシュみたいなものです。

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


363 :デフォルトの名無しさん:2005/05/07(土) 19:46:20
UNIX系OS上でのベンチマークだけど、ここ見ると同じマシンで、
x86_64の方がIA32よりも、たいがい速い。
ttp://www.nagoya.bug.gr.jp/~oshima/netbsd/bytebench/index.html
たまに遅いのがあるけど。

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


364 :デフォルトの名無しさん:2005/05/07(土) 20:02:13
gccにAMDのスタッフが参加してるので、gccはAMD寄りに最適化されてる。
インテルコンパイラはIntel向けに最適化されてるとは言え、AMDのCPUも含めて殆どの場合速い結果を出す。

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

365 :デフォルトの名無しさん:2005/05/07(土) 21:06:40
> gccにAMDのスタッフが参加してる

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

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


366 :デフォルトの名無しさん:2005/05/08(日) 06:07:47
>>361
EM64T-based applications, Version 8.1で、-QxWなしをキボン

367 :デフォルトの名無しさん:2005/05/08(日) 12:24:24
I社の人からx86->x64の性能向上の理由として関数引数がスタックから
レジスタ渡しになった事が原因の一つと聞いたことがある。

368 :デフォルトの名無しさん:2005/05/08(日) 13:34:22
あんだけあれば普通の呼び出しは全部レジスタに乗るよなあ

369 :デフォルトの名無しさん:2005/05/08(日) 14:25:10
>>335
まったくでたらめな使い方だけど、どうやらWOW64上のアプリでも
コンテキストスイッチの際、拡張レジスタを保存してくれるみたい。

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

370 :デフォルトの名無しさん:2005/05/08(日) 23:15:04
>>365
けど、Intelコンパイラだと、Netburstでも速くなって
その上AMDのCPUでも、更に速くなるんだぞ。
根本的にgccの設計が悪いんだと思うねぇ・・・

371 :デフォルトの名無しさん:2005/05/08(日) 23:17:10
すんません。
VS2005 + .NET Framework SDKの64bitで.NETアプリの64bit化をしようと思ったんだけど
普通にパス通すと、PSDK 64bit版のcl.exeが不正終了しません?
何ででしょうか・・・
誰か.NETアプリの64bit化に成功した人居ませんか?

372 :デフォルトの名無しさん:2005/05/09(月) 14:05:00
>>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ですか。デカい。

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

373 :デフォルトの名無しさん:2005/05/09(月) 14:07:12
gccはさすがに時代遅れだと思う。

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

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

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


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

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

376 :デフォルトの名無しさん:2005/05/09(月) 15:17:49
>>362
コンテクスト・スイッチもさりながら、
例外処理やunwind-protectのための状態退避のコストが大きくなりそうな気が
するんだけどどうだろう。



377 :デフォルトの名無しさん:2005/05/09(月) 15:19:12
>>372
コンテキストスイッチの際って、生真面目に全物理レジスタを待避すんの?
そもそも、ソフトウェアから物理レジスタにアクセスできんの?

378 :361:2005/05/09(月) 15:19:53
>>366
QxWありなしとでは、ほとんど変わりませんでしたよ。

379 :デフォルトの名無しさん:2005/05/09(月) 15:20:39
gccが遅いのは、クロスコンパイルを可能にするために、特定のCPUに
チューンしてないからだという記事をどこかで読んだ。gcc4.0.0のリリース時
にgnuの人がどこかで語ってた記憶がある。

380 :377:2005/05/09(月) 15:41:25
>>372
あ、もしかして、それはIteniumの話をしてたの?
x64の話かとおもって377を書いたわけだけど。

381 :デフォルトの名無しさん:2005/05/09(月) 15:46:43
レジスタ・ウィンドゥを装備して、コンテクスト・スイッチング時の転送量を
極力減らしているCPUも多いな。

382 :デフォルトの名無しさん:2005/05/09(月) 15:50:23
>>381
待て待て。レジスタウインドは、コンテキストスイッチングの為にある
わけじゃないぞ。よく考えてみろ。

383 :デフォルトの名無しさん:2005/05/09(月) 16:03:54
>>369
64bitコード内では問題ないんだけど、Compatibleモードに戻してから
APIやCRTのエピローグルーチンを実行すると、保護例外が発生する。
何が問題なんだろ?ちゃんと動いてる?

384 :デフォルトの名無しさん:2005/05/09(月) 19:38:49
>>383
R8-R15を使っているなら、使う前にそれらを退避しないといけませんよ。
拡張レジスタはWOW64で使われていますから。

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

>>380
IA-64です。

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

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

386 :デフォルトの名無しさん:2005/05/10(火) 10:30:05
今は
8086の全主記憶分がL2に載り、Z80の全主記憶分がL1に載り
ビデオメモリがWindowsが楽々動作する量になっている
そんな時代ですよ。

387 :デフォルトの名無しさん:2005/05/10(火) 16:09:55
>>386
それでも遅いと不満を鳴らす俺がここにいる。
Windowsそのものが重すぎるんだなきっと。

388 :383:2005/05/10(火) 16:17:45
>>384
Thx.
うまくいった。

389 :デフォルトの名無しさん:2005/05/10(火) 17:25:53
>>388
いますぐ試せないから聞いてしまうけど
この手法って32ビットWindowsでも有効なの?

390 :デフォルトの名無しさん:2005/05/10(火) 19:08:23
>>389
>>335

391 :デフォルトの名無しさん:2005/05/11(水) 00:10:58
>>388
64bitコード部分は>>333のようにハンドアセンブルしているの?

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

392 :デフォルトの名無しさん:2005/05/11(水) 18:14:47
>>391
yasm使えばいい。x64命令に対応かつWin32なオブジェクトを吐いてくれる。

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

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

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


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

394 :デフォルトの名無しさん:2005/05/11(水) 19:14:19
WOW64限定ということは、x64 Edition限定ってことしょ?
こんな怪しい方法で64bitコード実行するより、普通にWin64で作ればいいじゃん。

395 :392:2005/05/11(水) 19:32:51
>>393
xmm8〜も使えるよ。xmmレジスタについては特に制限はないみたい。

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

396 :デフォルトの名無しさん:2005/05/12(木) 01:56:47
Windowsで64bitのソフトを作りたいのですが、何が必要ですか?

397 :デフォルトの名無しさん:2005/05/12(木) 10:24:58
やる気

398 :デフォルトの名無しさん:2005/05/12(木) 10:35:36
熱気

399 :デフォルトの名無しさん:2005/05/12(木) 16:29:19
>>396
64bitモード時、アラート状態でAPCが発生しても大丈夫なの?
あと↑でAPI呼び出しは当然無理だよね?

400 :デフォルトの名無しさん:2005/05/12(木) 16:39:16
>>334
どうでもいいけど
>*(DWORD *)addr1 = aaa;
これは無理だr

401 :デフォルトの名無しさん:2005/05/12(木) 16:54:11
>>400
拡張子cppで保存しているからじゃないの?
VC6だったら警告は出るけど、コンパイルリンクは出来る。

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

402 :デフォルトの名無しさん:2005/05/12(木) 17:50:41
>>400-401
のプログラムだと、1度目は0、2度目のモード変更後では-1になる。

403 :デフォルトの名無しさん:2005/05/12(木) 21:58:12
>>399
SleepEx()など呼んで制御がシステムに移っている間アラートになるわけででしょ?
特に問題はないと思う。

404 :デフォルトの名無しさん:2005/05/12(木) 22:56:37
timerSetEvent()はどうですかね?
64bitコード実行中にちょうどコールバックが呼ばれるようにして

405 :デフォルトの名無しさん:2005/05/13(金) 16:07:43
>>404
他のスレッドに影響はないので問題はないと思う。
実際やってみたけど、不具合はなかったよ。

406 :デフォルトの名無しさん:2005/05/17(火) 16:48:36
size_tのサイズって何を基準に決めるの?
4byteままでいいじゃん

407 :デフォルトの名無しさん:2005/05/17(火) 16:54:55
それじゃ4G以上のサイズ表現できねぇじゃん

408 :デフォルトの名無しさん:2005/05/17(火) 19:49:29
べつにいいじゃん

409 :デフォルトの名無しさん:2005/05/18(水) 10:49:47
サイズ固定でいいならそもそもsize_tを使う必要がない

410 :デフォルトの名無しさん:2005/05/18(水) 22:42:01
smbclientで4G以上のファイルが送れませんでした
氏ね

411 :デフォルトの名無しさん:2005/05/23(月) 08:53:53
質問です。
VC++にx86-64のコンパイラを含んだPSDKを入れて組んだコード内の構造体のサイズはどのようになるのでしょうか?
今までどおり4の倍数なのでしょうか?

412 :デフォルトの名無しさん:2005/05/23(月) 11:39:41
構造体内のアライメントの話?

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

413 :デフォルトの名無しさん:2005/05/23(月) 13:10:43
int型は64ビットになるのですか?

414 :デフォルトの名無しさん:2005/05/23(月) 13:49:03
プラットフォームとコンパイラによります。


415 :デフォルトの名無しさん:2005/05/23(月) 16:56:07
>>413
とりあえずVCではintもlongも32ビットのまま。
INT_PTRの類は64ビット化される。
long longなどもそのまま64ビット。

416 :デフォルトの名無しさん:2005/05/23(月) 19:19:57
知ったか様が降臨しました!!!

417 :デフォルトの名無しさん:2005/05/23(月) 19:30:56
>>416
おいでませ〜

418 :デフォルトの名無しさん:2005/05/23(月) 19:43:52
知ったか様、知ったか様、
いらっしゃりましたらおいでください・・

419 :デフォルトの名無しさん:2005/05/23(月) 19:44:53
>>416
えっ?どこどこ?
>>412
>コンパライのオプション
これ?

420 :デフォルトの名無しさん:2005/05/24(火) 00:50:21
紺払い

421 :デフォルトの名無しさん:2005/05/24(火) 07:12:51
doubleについてはどうですか?やはり32ビットのままなのでしょうか?

422 :デフォルトの名無しさん:2005/05/24(火) 11:18:00
floatについてはどうですか?やはり64ビットのままなのでしょうか?


423 :デフォルトの名無しさん:2005/05/24(火) 12:01:54
>>421-422
それぐらいsizeof()で調べようよ・・・

424 :デフォルトの名無しさん:2005/05/24(火) 22:32:50
わからないなら黙っていて下さい。

425 :デフォルトの名無しさん:2005/05/24(火) 23:21:13
shortについてはどうですか?やはり16ビットのままなのでしょうか?


426 :デフォルトの名無しさん:2005/05/25(水) 07:44:41
VCではそうだよ。

427 :デフォルトの名無しさん:2005/05/25(水) 23:20:55
floatが64ビットって何やねん

428 :デフォルトの名無しさん:2005/05/25(水) 23:33:17
C言語の変数は型によってビット長が特に決まっていないから
64bitのfloatがあってもおかしくはない。

429 :デフォルトの名無しさん:2005/05/26(木) 00:00:25
CRAYがshortもfloatも64bitと昔聞いたことがある

430 :デフォルトの名無しさん:2005/05/26(木) 09:52:27
doubleが32ビットには突っ込まないのな。
floatが64ってのはあのボケを見て書いたんだと理解したんだが

431 :デフォルトの名無しさん:2005/05/26(木) 10:16:29
doubleが32ビットでもおかしくないが
sizeof(double) >= sizoef(float)は決まっている



432 :デフォルトの名無しさん:2005/05/26(木) 12:39:24
>>421>>422は別個のネタだろ

433 :デフォルトの名無しさん:2005/05/26(木) 16:51:17
でもぶっちゃけ、IEEE754が圧倒的に多い。
そしたら、float = 32ビット、 double = 64ビットになるでしょ。

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

434 :デフォルトの名無しさん:2005/05/26(木) 17:29:48
64bit環境で試すコンパイラ - アセンブルコードに見るその実力
大原雄介
http://pcweb.mycom.co.jp/special/2005/compiler/

O原 gj! 続編書けや。

435 :デフォルトの名無しさん:2005/05/26(木) 18:08:58
>>429
調べたら、charとlong double以外は全部64bitだったw

436 :デフォルトの名無しさん:2005/05/27(金) 06:21:31
>>434
性能向上比のグラフとか、いろいろ間違っているんじゃないか?

437 :デフォルトの名無しさん:2005/05/27(金) 16:08:52
>>434
アホだ・・・

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

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

438 :デフォルトの名無しさん:2005/05/27(金) 16:10:16
というか、あんな記事を一般人に見せて何の役に立つのか。


439 :デフォルトの名無しさん:2005/05/27(金) 16:33:50
ベンチマーク禁止はベータ版やサーバ系ではなかったかな?

440 :デフォルトの名無しさん:2005/05/29(日) 15:42:56
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にコンパイルしなおせないジャン。。。

441 :デフォルトの名無しさん:2005/05/29(日) 15:54:01
>>440
だってハンドルやポインタは64ビット。
GetWindowLongで32ビットに切り詰めた値を返されても困るでしょ。

442 :デフォルトの名無しさん:2005/05/29(日) 16:09:52
なるほど・・・
そういえばそうだな。
GetWindowLongPtr 使えって事か・・・

443 :デフォルトの名無しさん:2005/05/31(火) 01:22:38
しかし GetWindowLongPtr の Win32 での定義が腐ってるので
結局 #ifdef で分岐しなくてはならない罠。
最新の Platform SDK では修正されてたりしますか?

444 :デフォルトの名無しさん:2005/05/31(火) 07:46:02
AtlWin.hかなんかでインライン関数として書かれている。

445 :デフォルトの名無しさん:2005/05/31(火) 23:04:29
ネイティブのmp3プレーヤー作ろうと思ったが、MCIコマンドがうまく動いてくれない。
おかしいなあと思ってデバイス一覧取得してみたら・・
 mpegvideo が無かった orz

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

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

446 :デフォルトの名無しさん:2005/06/01(水) 00:07:34
MCIデバイスドライバも32ビットDLLだからそりゃx64のexeからは使えないわな
MCIはlegacyだからDirectMusicとか使えってことかな

447 :デフォルトの名無しさん:2005/06/01(水) 03:47:23
かなりの互換性問題は、
EXEとDLLはビット数を同じにしなければならない
で説明できちゃうんだよね・・・。

448 :デフォルトの名無しさん:2005/06/01(水) 04:43:14
というか、64bit 環境でも MCI まだ実装してる事実に驚いた。



449 :デフォルトの名無しさん:2005/06/01(水) 14:39:25
そのためのCOMですよ

450 :445:2005/06/01(水) 21:19:01
Directshow SDK をダウンロードしてきて動かしてみたけど、
やっぱり64bitネイティブだと mp3再生ができない  orz

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

451 :デフォルトの名無しさん:2005/06/01(水) 22:09:32
グローバルフックがたるい

452 :デフォルトの名無しさん:2005/06/01(水) 23:14:41
Windows Media Playerも32ビット版だけか。
(64ビット版があったとしてもCodecが全然なくて役に立たないだろうけど)
本気で64ビットアプリからはmp3鳴らせないみたいだねえ

453 :デフォルトの名無しさん:2005/06/01(水) 23:31:47
作れ

454 :デフォルトの名無しさん:2005/06/02(木) 07:05:31
>>453
下のMP3ソースコードを64bitでコンパイルしたが漏れの実力では動かせなかった orz

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

455 :デフォルトの名無しさん:2005/06/02(木) 21:34:38
>>454
これつかったら?

http://www.fmod.org/

456 :デフォルトの名無しさん:2005/06/04(土) 06:07:59
>>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;
}
 コードはこれだけなんだけど・・

457 :デフォルトの名無しさん:2005/06/04(土) 10:22:57
マネージ?

458 :デフォルトの名無しさん:2005/06/04(土) 17:12:37
SDLの64bit版が出ないので、色々やり難いなぁ・・・
インラインアセンブラが廃止になったので移植がやりにくいんだろうけど・・・
俺外部にアセンブラ出すのやった事ないし・・・

459 :デフォルトの名無しさん:2005/06/04(土) 18:09:02
マネージド コードに64bitと32bitで違いあったっけ?

460 :デフォルトの名無しさん:2005/06/04(土) 21:10:09
ttp://www.exconn.net/Blogs/team01/archive/2005/06/01/481.aspx

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

461 :デフォルトの名無しさん:2005/06/05(日) 00:26:08
>>456
サンプルもコンパイルできないの?
sampleにある.dspファイルからVSを立ち上げて、プラットフォームをx64
リンクするモジュールをfmodvc.libからfmod64vc.libに変えるだけで
問題なくコンパイルできる。

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

462 :デフォルトの名無しさん:2005/06/05(日) 13:27:56
>>461
情報ありがとう。
日本語版で試して見た。ワーニングを無視して
リンクモジュールの変更/DLLを配下にコピーでちゃんと動いた。

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

463 :デフォルトの名無しさん:2005/06/05(日) 20:50:31
配下とか押下とかアベンドとかそういう単語をそろそろ捨てないか?

464 :デフォルトの名無しさん:2005/06/06(月) 18:43:45
アベンドは便利だから残して欲しい

465 :デフォルトの名無しさん:2005/06/06(月) 22:30:34
アベンド2回で某超巨大企業T出入り禁止と聞いて1日も早く
脱出したかったオレは何とか2回起こす方法を
考えたがクライアント側担当ではどうあがいてもムリと悟って(ry

466 :デフォルトの名無しさん:2005/06/07(火) 09:58:52
http://pcweb.mycom.co.jp/special/2005/compiler/

467 :デフォルトの名無しさん:2005/06/07(火) 11:11:15
>>466
>>434

468 :デフォルトの名無しさん:2005/06/07(火) 23:28:08
>>445
なんかsysWOW64だけじゃなくてsystem32にもmciqtz32.dllがあるなあ。
Dependency Walkerで覗いてみたけど間違いなく64ビットバイナリみたい。
MPEGVideoとして登録さえすれば使えるのかな?
つーかmci*.drvまであるが16ビットサポートを廃止したのにいったい何に使うんだ

469 :デフォルトの名無しさん:2005/06/08(水) 01:36:36
mciqtzにはmp3デコーダ含んでいないし。

470 :デフォルトの名無しさん:2005/06/08(水) 02:37:23
/noexecute=OptIn(XP x64のデフォルト)だと64ビットアプリまで保護から外れる
みたいだけどそういう仕様なの?
/noexecute=OptOutのとき64ビットアプリを例外に追加することはできないのに。

471 :デフォルトの名無しさん:2005/06/10(金) 22:55:58
AMD64版のPlatform SDKについてくるDependency Walkerがファイルシステム
リダイレクションを考慮してなくて、32ビットのDLLをまともに表示できない。
もう1GB使ってx86版のSDKも入れろとおっしゃいますかそうですか

472 :デフォルトの名無しさん:2005/06/10(金) 23:42:49
つ[NTFSの圧縮属性]

473 :デフォルトの名無しさん:2005/06/11(土) 10:11:06
FPU使えないとしたら、指数関数や三角関数はどうやって計算するんだろう。
計算するコードを用意しないといけないの?
FPUにあってSSEにない機能がけっこうあるからな。

474 :デフォルトの名無しさん:2005/06/11(土) 11:09:21
>>473
pgr

475 :デフォルトの名無しさん:2005/06/11(土) 14:29:28
マックにINTELのCPUが乗るということで、
IA−64について調べています。
情報源などありましたら、よろしくお願いします。

476 :デフォルトの名無しさん:2005/06/11(土) 14:47:18
x87のFSINCOSとかスループット130とかだし
内部的にはテイラー展開してんのかな?

477 :デフォルトの名無しさん:2005/06/11(土) 15:31:44
>>475
Mac に載るのは IA32 だよ。つまり、最初のバージョンは32bitに逆戻りする。
そのうち x86_64 にも対応して 64bit 化するだろうけど。
IA64 (Itanium) は載らんだろ。

478 :デフォルトの名無しさん:2005/06/11(土) 17:04:49
>>477
意外とItanium2載せて、多量消費効果により、Itanium2の値段が下がったりな。
Windowsではx86-64が主流なのでもう遅いけど。

479 :デフォルトの名無しさん:2005/06/11(土) 17:11:27
Mac程度の台数じゃなあ。

480 :デフォルトの名無しさん:2005/06/11(土) 17:28:49
>>476 CORDIC、sincosなんて典型的

481 :デフォルトの名無しさん:2005/06/11(土) 20:08:18
じゃあ64bitアプリでsinとか使うときは必ず長いコードを書く(コピペする)の?
速度的にはよくてもアセンブラできれいに書けないなあ。

482 :デフォルトの名無しさん:2005/06/11(土) 21:29:36
>>481
マクロアセンブラって知ってる?w

483 :デフォルトの名無しさん:2005/06/11(土) 21:38:41
あー、そういえば、MacこそIA64向けの絶好の市場かもな
どちらにせよ互換性の問題は発生するわけだから、どうせならIA64にしてしまっても問題ないわけで・・・
けど、乗るのはPenM系みたいだからIA64を乗せるのは大変だろうけどw
Pen4系だったら、内部は殆どソフトウェアで簡単に仕様変更が出来るらしいけどね。


484 :デフォルトの名無しさん:2005/06/11(土) 21:47:29
まさかとは思うが、マック用に新たなチップを起こすとか考えてる?

485 :デフォルトの名無しさん:2005/06/11(土) 21:48:14
>>483
IA64って本当に速いのかなぁ。実は失敗作だったりしない?

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

486 :デフォルトの名無しさん:2005/06/11(土) 21:51:00
>>485
コンパイラとX86互換の問題が有るんでぇ、それさえ解決したら早いよ。
てか、インテルはItuniumから、下位互換を全て抹消するべきだよ。
持ってても意味無いし。

487 :デフォルトの名無しさん:2005/06/11(土) 22:21:35
>>485
単純に以前の32bitを切り捨てるくらいの勢いで作ったけど
互換性についての市場の要望があまりに強かったから、とりあえずx86エミュレーター積んどこう
くらいのノリでやったら、過去の資産が鈍足になっちまっただけで、64bitネイティブだと普通に速い。


488 :デフォルトの名無しさん:2005/06/11(土) 22:23:40
とにかく、Intelさんはマック用に最高のCPUを作ってもらいたいね。
ウィンが真っ青になるぐらいの(笑)

489 :デフォルトの名無しさん:2005/06/11(土) 22:51:52
自分で自分の首を絞めろとw

490 :デフォルトの名無しさん:2005/06/11(土) 22:52:41
なんつーかPentium Proの二の舞

491 :デフォルトの名無しさん:2005/06/12(日) 00:57:40
>>487
普通に速いと言ってもFPだけで、シングルスレッドの
整数演算性能だと、P4 や Athlon 64 より遅いよ。

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


492 :デフォルトの名無しさん:2005/06/12(日) 01:58:14
>整数演算性能だと、P4 や Athlon 64 より遅いよ。

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


493 :デフォルトの名無しさん:2005/06/12(日) 02:38:06
マックに使うときまでには解消しているはずですよね〜☆

494 :デフォルトの名無しさん:2005/06/12(日) 02:43:50
>>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 なんて
使わないよ。

495 :デフォルトの名無しさん:2005/06/12(日) 02:54:31
Itanium2だからじゃないの?
Itaniumはブランチ演算3個、整数演算4個、浮動小数点演算2個の構成だから、整数演算に重点が置かれてるとおもうけど・・

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


496 :デフォルトの名無しさん:2005/06/12(日) 03:14:37
> 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 に乗り換えるんだろう。


497 :デフォルトの名無しさん:2005/06/12(日) 03:42:07
>>494
クロックが違いすぎるぅーーーーーー
もちろん板ちゃんのクロックが引きあがらない問題はあるけども。
SPECだと、PEN4の得意分野だし。

498 :デフォルトの名無しさん:2005/06/12(日) 03:47:12
IA64は命令セットの話で
CPUの能力そのものに影響しないわけじゃないけど(そりゃ固定長かどうかとか命令数の量とか重要だけど)
Itaniumのクロックや演算器の数などのCPU自体の演算性能とは何の関係も無いと思われ。

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

499 :デフォルトの名無しさん:2005/06/12(日) 03:54:47
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 を達成できてない
ってことだね。


500 :デフォルトの名無しさん:2005/06/12(日) 07:44:55
まず64bitと32bitでどう比較したのかしらんが
Itaniumは整数演算が速くて、浮動小数点演算が遅いのだよ?(そのつもりで設計されてる)
多分得意分野を逆に記憶してるか、32bitエミュレーションでの比較を勘違いしてないか?

501 :デフォルトの名無しさん:2005/06/12(日) 08:35:03
というか、マックには最強のCPUを搭載してほしいんですけど。

502 :デフォルトの名無しさん:2005/06/12(日) 11:34:41
要望だけなら、誰でもできるわな。

503 :デフォルトの名無しさん:2005/06/12(日) 15:03:36
>>500
設計がどうだろうと、実測で Pen4 や Athlon 64 に負けてるだろ。
整数演算で Pen4 や Athlon 64 よりいい結果を出すベンチマーク結果を示してみろよ。

504 :デフォルトの名無しさん:2005/06/12(日) 15:20:45
負けてるって、浮動小数点演算能力は無視かよw
整数だと数パーセント負けてるが、浮動小数点なら倍勝ってるんだぞ。

505 :デフォルトの名無しさん:2005/06/12(日) 15:24:10
投入している物量(特にキャッシュ容量)を考えると物足りない性能
なのは確かだと思うなぁ。>IA64

506 :デフォルトの名無しさん:2005/06/12(日) 15:26:54
割算もちゃんとできないのか。面白い奴だな。
>>494 のベンチで Pentium 4 と比べてみようか。

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

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

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

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

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


507 :デフォルトの名無しさん:2005/06/12(日) 15:59:47
Macな人が、Ituniumを貶そうとしてるの?
Ituniumは良くも悪くも(悪くの部分が大きくなってるけど)実験中だからねー。
Ituniumの現在スペックを持って糞というのは、言えるけど言っても仕方ない
事で。

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



508 :デフォルトの名無しさん:2005/06/12(日) 16:06:16
Itunium って何よ?

509 :デフォルトの名無しさん:2005/06/12(日) 16:08:00
>>507
>Macな人が、Ituniumを貶そうとしてるの?

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

510 :デフォルトの名無しさん:2005/06/12(日) 16:10:05
ずいぶんと「実験中」が長いよね。正直期待していたのだが・・・・

511 :デフォルトの名無しさん:2005/06/12(日) 16:23:50
その成果がマックに!
ということで期待大!!!

512 :デフォルトの名無しさん:2005/06/12(日) 16:26:21
マクユーザを騙るのは止めてくれ

513 :デフォルトの名無しさん:2005/06/12(日) 16:37:20
>>510
中に浮いちゃったよぉおね。

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

514 :デフォルトの名無しさん:2005/06/12(日) 16:45:58
クロック 1.6GHz しかないのに、Pen4 3.8 GHz と、まあ同等の
性能が出てるわけだから、これでクロックが Pen4 並とはいか
なくても、せめて Athlon 64 なみに速くなればねえ…

やっぱり大量生産を見込んで大量にお金をつぎこまない限り、
クロックは上げられないのか。 (´・ω・`) ショボーン

515 :デフォルトの名無しさん:2005/06/13(月) 13:01:33
>>508
iTunes に最適化されたプロセッサ。

516 :デフォルトの名無しさん:2005/06/13(月) 21:04:26
CPU が統一されるのは良い事だ
不幸なのは、それが x86 という事……

517 :デフォルトの名無しさん:2005/06/13(月) 21:13:25
おもちゃみたいなPowerPCに統一されても、どもならんし
PowerやItanium2は、話にならんしなあ

518 :デフォルトの名無しさん:2005/06/13(月) 22:19:58
appleはPentium Mあたりが欲しいだけだろ

519 :デフォルトの名無しさん:2005/06/13(月) 23:50:40
インテルさんは、最高のCPUをアップルに提供すると約束したんでしょ。
だからアップルは採用したの。
PentiumMだかなんだから知らないけど、最高であることは
間違いないわけだし、心配しなくていいんじゃないかな。
ウィンな人たちが悔しがっても、し〜らないっと。

520 :デフォルトの名無しさん:2005/06/14(火) 00:56:55
最高のCPUをAppleにだけ供給するとか
Mac板でも、そういうありえん妄想してる奴が多いな
もうすっかりintel insideに順応してしまったようで
ウォッチしててもつまらなくなってしまったw

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


521 :デフォルトの名無しさん:2005/06/14(火) 01:18:57
なんつー信仰心だ

522 :デフォルトの名無しさん:2005/06/14(火) 01:29:17
今回の件で、MacOSがWindowsベースになっても
ハードとソフトの見た目がMacなら信者はついていくと確信したね

523 :デフォルトの名無しさん:2005/06/14(火) 01:36:19
>>522
別に信者じゃないけど、ハードとソフトの見た目がMacなら結構良いじゃん
と思ってしまいました。w

524 :デフォルトの名無しさん:2005/06/14(火) 01:39:38
そうだろ、そうだろ
そしてその次の段階は、OSの完全なWindows化
ハードの見た目だけMacになる

なんてな


525 :デフォルトの名無しさん:2005/06/14(火) 01:43:22
>>524
なんで >>522 から劣化してんだよw

526 :デフォルトの名無しさん:2005/06/14(火) 01:47:17
ついでにプログラマからの見た目もMacになると、ちょっと嬉しい。
.NETからCocoaが呼べるとかね。(爆)

527 :デフォルトの名無しさん:2005/06/14(火) 01:47:37
何故っていわれても、そもそもMacはどんどん劣化してるじゃん・・・

528 :デフォルトの名無しさん:2005/06/14(火) 01:59:20
WINE が使えるのが嬉しい様な、嬉しくない様な

529 :デフォルトの名無しさん:2005/06/14(火) 03:30:14
Macの将来について語るスレはここですか?
>>528
VirtualPCと違って同じデスクトップで動作する可能性があるわけか

530 :デフォルトの名無しさん:2005/06/14(火) 08:56:20
マックは64ビットですし。

531 :デフォルトの名無しさん:2005/06/14(火) 12:16:29
質問させて下さい。

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

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

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

532 :デフォルトの名無しさん:2005/06/14(火) 12:29:03
>>531
VCのリンカで/LARGEADDRESSAWAREを指定する必要がある。
ちなみにこれは元々32bit Windowsでboot.iniの/3GB指定と組み合わせてユーザー仮想アドレス空間を3GBに広げるための物だった。

533 :デフォルトの名無しさん:2005/06/14(火) 12:47:04
http://www.marbacka.net/asm64/arkiv/64bit_addressing.html
ここも参考になると思う。


534 :デフォルトの名無しさん:2005/06/14(火) 12:58:20
>>532-533
色々調べて/LARGEADDRESSAWAREと/3GBまでは辿りついた所でした。
Thanksです!!
また分からない事があったら質問させてください。

535 :デフォルトの名無しさん:2005/06/14(火) 13:44:05
↓で128bitプログラミングのことも話題にしてくれ
http://pc8.2ch.net/test/read.cgi/pcnews/1117523052/

536 :デフォルトの名無しさん:2005/06/14(火) 22:22:49
>>535
それだけは勘弁してくれ

537 :デフォルトの名無しさん:2005/06/14(火) 22:26:37
PS2のEmotion Engineを128bitCPUと強弁してみる

538 :デフォルトの名無しさん:2005/06/15(水) 04:25:34
IA32はi432と同じ運命をたどるのかの?

539 :デフォルトの名無しさん:2005/06/15(水) 06:44:15

IA32じゃなくてIA64の間違い

540 :デフォルトの名無しさん:2005/06/15(水) 07:21:33
これか。

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 とか、面白そうな事を
やってたんだね。勿体ないなぁ。

541 :デフォルトの名無しさん:2005/06/15(水) 16:13:52
AMDもAm2900とかAm29000とか、面白そうな物はあったみたい。
いろいろ研究の結果、一番はやってるIA32を踏襲するが吉と判断したのでせう。

542 :デフォルトの名無しさん:2005/06/15(水) 16:42:51
VisualStudio2005 BetaでMFC使っている人いますか?

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

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

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

543 :デフォルトの名無しさん:2005/06/15(水) 23:26:26
managed codeになってるだけとか

544 :471:2005/06/17(金) 02:40:01
結局415kbで済みますた。
http://www.dependencywalker.com/

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

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

545 :デフォルトの名無しさん:2005/06/20(月) 19:15:58
XP x64 にて、32bitアプリから 64bitアプリのウインドウハンドルは
扱えますか?

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


546 :デフォルトの名無しさん:2005/06/20(月) 19:24:30
>>542
それは x64 とか 64bitコンパイラとは別の問題?

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

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

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



547 :デフォルトの名無しさん:2005/06/22(水) 07:19:19
Win32以外のサブシステム以外は絶滅したって聞いてたのに
レジストリにはこっそりposixの指定だけあるのな
SFUを移植する予定があるんだろうか

548 :デフォルトの名無しさん:2005/06/24(金) 10:33:11
>>546
Thanks!
VC6.0からの移行だったんだけど、MFCは.netで随分変わったみたいね。
とりあえずx64でコンパイルが通って、実行出来ますた。
32bit版と比べて、1割程度高速になりますた。


549 :デフォルトの名無しさん:2005/06/24(金) 16:02:11
>>546
>32bit版と比べて、1割程度高速になりますた。

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



550 :デフォルトの名無しさん:2005/06/24(金) 16:03:09
>>549
>>546 → >>548


551 :デフォルトの名無しさん:2005/06/24(金) 16:10:18
インラインだと最適化が阻害される場合もあるし
速度重視ならアセンブラに分離した方がいいよ
クラス扱うのが面倒だが

552 :デフォルトの名無しさん:2005/06/24(金) 16:40:17
>>551
>インラインだと最適化が阻害される場合もあるし

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

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

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

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

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



553 :デフォルトの名無しさん:2005/06/24(金) 17:57:30
>>552
>Cのローカル変数名を使えるのは何者にも替えがたい…
だね。

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

554 :デフォルトの名無しさん:2005/06/24(金) 18:21:05
>>553
>(アセンブルはできるし例外も出ない)。

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




555 :デフォルトの名無しさん:2005/06/24(金) 22:39:47
>>554
Windowsがプロセス・スレッド切り替えのときにFPU/MMXレジスタの退避を行わないから事実上使えない。

556 :デフォルトの名無しさん:2005/06/24(金) 23:55:39
>>555
了解…

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

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



557 :デフォルトの名無しさん:2005/06/25(土) 00:30:44
SSE非対応のOSでもSSEが使えるようなもんだ
立場が逆になっただけで

558 :デフォルトの名無しさん:2005/06/25(土) 01:47:02
>>557
意味がわかりませぬ


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

560 :デフォルトの名無しさん:2005/06/25(土) 10:08:37
x64で sizeof(HWND)って、4? 8?


561 :デフォルトの名無しさん:2005/06/25(土) 10:17:53
ハンドル類は全部8。
WOW64の都合があるから実際には32ビットで表せる数を超えるハンドルが
同時に作られることはないけど

562 :デフォルトの名無しさん:2005/06/25(土) 10:53:05
>>561
ありがと

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

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


563 :デフォルトの名無しさん:2005/06/25(土) 11:10:02
勝手にやっちゃまずいだろ・・・

564 :デフォルトの名無しさん:2005/06/25(土) 11:17:20
>>563
>勝手にやっちゃまずいだろ・・・
操作する方もされる方も、自分のアプリです

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


565 :デフォルトの名無しさん:2005/06/25(土) 11:34:14
64bit版でインラインアセンブラを使えなくした意図は何?

566 :デフォルトの名無しさん:2005/06/25(土) 14:37:35
たぶんコンパイラの最適化のためではないかと思う。

567 :デフォルトの名無しさん:2005/06/25(土) 14:37:41
>>565
激しくわからん。
同じVS2005でも32bit版は使えるわけで、何故使えなくしたのかサパーリ。

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

568 :デフォルトの名無しさん:2005/06/25(土) 14:58:53
インテル、MSどっちのコンパイラも_asm駄目なんでしょ?
なんか企みはありそうだ。まあ、インテルのコンパイラは
VC互換を売り文句にしてるからかも知れんけど。

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

569 :デフォルトの名無しさん:2005/06/25(土) 15:05:57
M$はクソだな。GCCマンセー。

570 :デフォルトの名無しさん:2005/06/25(土) 15:08:21
C++もついに実行時コンパイルの時代に・・・!

571 :デフォルトの名無しさん:2005/06/25(土) 15:08:38
汎用レジスタ16本、XMMレジスタ16本もあれば、普通にコンパイラの最適化に任せておいても
それなりに速度でると思う。
8本が少なすぎた。16本もあってしかもアウトオブオーダ実行可能だから、そんなに気合入れて最適化
する必要ないと思う。




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

572 :デフォルトの名無しさん:2005/06/25(土) 15:12:26
>>569
そこでmingwのx64版が欲しいんですよ。gccならばりばりインライン可だからね。

573 :デフォルトの名無しさん:2005/06/25(土) 15:12:55
>>567
AMDのが速いだろ。構造的に。

574 :デフォルトの名無しさん:2005/06/25(土) 15:18:37
IA32用のコードはそのまま別の意味で通るから危険と言えば危険だからある意味正解だとは思うけど
オプションで有効化可能にすればいいんだから確かに怪しいな

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

こんな所か

575 :デフォルトの名無しさん:2005/06/25(土) 15:18:42
汎用レジスタベースならAMD、XMMレジスタベースならIntelのほうが速かった。

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

576 :デフォルトの名無しさん:2005/06/25(土) 16:40:39
>>571
>8本が少なすぎた。16本もあってしかもアウトオブオーダ実行可能だから、そんなに気合入れて最適化
>する必要ないと思う。

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

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

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

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

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

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

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



577 :デフォルトの名無しさん:2005/06/25(土) 17:09:31
SIMDに関しては、組み込み関数が
しっかり最適化をしてくれるなら
これの為にアセンブラを使う意義はあまりないと思う。


578 :デフォルトの名無しさん:2005/06/25(土) 18:00:28
>>577
VCの組み込み関数ってある? インテルだけ?

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

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

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


579 :デフォルトの名無しさん:2005/06/25(土) 19:05:30
http://pc8.2ch.net/test/read.cgi/tech/1103609337/218

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

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

580 :デフォルトの名無しさん:2005/06/25(土) 19:09:05
コンパイラの出力も参考にできるし
好きなだけ時間かけられるなら
コンパイラに負けるはずはない
手間かける価値があるかだけが問題

581 :デフォルトの名無しさん:2005/06/25(土) 19:21:47
>>579
確かに簡単だ…
オレとしては単純だと人間不利だと思ってるが違う?

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

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


582 :デフォルトの名無しさん:2005/06/25(土) 19:33:53
>もちろん、今後数年はそれで食うためのコードだから手塩にかけるのだ
ターゲットが決まってるんなら、これもありだけどねぇ。
VC++2005ってことは、ターゲットがないってのと同義だしねぇ。


583 :デフォルトの名無しさん:2005/06/25(土) 19:41:32
>>579
http://pc8.2ch.net/test/read.cgi/tech/1103609337/218
_mm_add_pd これが組み込み関数だと思うけど、こういうのって
一般的にパラメータにローカル変数名を受け取るよね?

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

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


584 :デフォルトの名無しさん:2005/06/25(土) 19:41:56
>>581
違うだろう。
あれしきのコードなら、頭の中でアセンブラの最適コードが組める。
人間が理論値を出せばコンパイラに勝ち目はない。
しかも、>>579ではコンパイラが凡ミスして遅くなっている。

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

585 : ◆.MeromIYCE :2005/06/25(土) 19:46:00
>>583
そこには書いてないけど、組み込み関数で1700clkを出したコードでは、
ループの中ではレジスタに割り当てっぱなしだった。

586 :デフォルトの名無しさん:2005/06/25(土) 19:46:38
>>582
>ターゲットが決まってるんなら、これもありだけどねぇ。
インテルとAMDくらいだったら二つ用意して実行時に切り替える
くらいやってる人多くね?

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


587 :567:2005/06/25(土) 19:56:42
なんか盛り上がってるな。
>>574
同意。
inline asmが使えなくなったのは、IA64互換がらみかなと踏んでみた。
.net使えゴルァというMSの企みやもしれん。




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

588 :デフォルトの名無しさん:2005/06/25(土) 19:58:31
>>584
おっしゃることも分かるけど、やっぱ実感としては、もうちょい
大きいコードで人間は有利だと思う。コンパイラには分からない
プログラムの意味が加味できるから。

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

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

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

589 :デフォルトの名無しさん:2005/06/25(土) 20:07:20
>>588
>コンパイラには分からない プログラムの意味が加味できるから。
同意。これはでかい。
アセンブラはCや組み込み関数より圧倒的に表現力が高い。

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

590 :デフォルトの名無しさん:2005/06/25(土) 20:14:26
>>553
6つでは?
CX,DX,7,8,9,10

591 :デフォルトの名無しさん:2005/06/25(土) 20:15:14
↑CX,DX,8,9,10,11の間違い

592 :デフォルトの名無しさん:2005/06/25(土) 20:18:28
手で最適化するのに意味のあるコードを書く人がどれくらいいるのか・・・

593 :デフォルトの名無しさん:2005/06/25(土) 20:26:15
>>576
VCは「こいつアホか」って思うコード吐くときはあるけど、Intelはスタックフレームの使い方結構うまいと思うよ。
SIMD組み込み関数/クラスを使った明示的ベクトライズでいいじゃん。
これなら並大抵のハンドオプティマイズじゃ追いつかない。

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

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

594 :デフォルトの名無しさん:2005/06/25(土) 20:33:26
>>593
>並大抵のハンドオプティマイズじゃ追いつかない。
具体例キボン。
人間がアセンブラ書いても負けるとは思えないよ。

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

595 :デフォルトの名無しさん:2005/06/25(土) 20:38:35
常に人間がチェックできるほどヒマだったらいいんだけどねえ

596 :デフォルトの名無しさん:2005/06/25(土) 20:39:55
アセンブラマニア多いなーこのスレ。
同志がイパーイ。

597 :デフォルトの名無しさん:2005/06/25(土) 20:53:03
まあ、汎用レジスタが16個になるのは効くだろう。
espやebpは変にいじれないし、mul、div、カウンタに食われるから、
実質3倍くらいに増えた感触じゃないかな。

598 :デフォルトの名無しさん:2005/06/25(土) 21:02:10
>>595
盛り上がってるのでスレ違いだと思いつつ最適化の話題。

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

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

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

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

で、根幹のエンジン部分だとSIMDが大活躍するわけだ。だから
インラインasm復活キボンヌ

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





599 :デフォルトの名無しさん:2005/06/25(土) 21:04:40
え、商用アプリの話だったの?

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

600 :デフォルトの名無しさん:2005/06/25(土) 21:17:53
>>599
境界はきわめて曖昧&600

601 :デフォルトの名無しさん :2005/06/25(土) 21:31:48
>>597
漏れはRISC系のレジスタの多さにちょっと目がクラクラしそうになったことがある。

602 :デフォルトの名無しさん:2005/06/25(土) 21:34:24
SIMDヲタにとってはPowerPCは夢のマシンだな。
アポーはIntel移行だけど。

603 :デフォルトの名無しさん:2005/06/25(土) 21:47:04
>>594
具体的にはいえないけど、C言語で1サイクル400〜500ステップくらいのループを、
MMX/SSE2で並列化、とか。

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



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

604 :デフォルトの名無しさん:2005/06/25(土) 21:47:15
MSPゴ依存AAを禁止されて等幅だけでAAを組まなくてはならなくなった
AA職人が愚痴り合うスレはここですか?

605 :デフォルトの名無しさん:2005/06/25(土) 21:56:37
まんもすっぴー♪ゴ依存アナル遊びを禁止されて等幅だけでアン肝アソボットを組まなくてはならなくなった
アースホールアヌス職人が愚痴り合うスレはここですか?

606 :デフォルトの名無しさん:2005/06/25(土) 22:00:39
>>603
500ステップくらいだったらがんばれ!

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

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

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

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


607 :デフォルトの名無しさん:2005/06/25(土) 22:25:02
>>606
いや、整数論理演算ベースでも、ICCでSIMD関数使ったときのあのスケジューリングはとてもまねできない。

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

608 :デフォルトの名無しさん:2005/06/25(土) 22:38:15
>ICCでSIMD関数使ったときのあのスケジューリングはとてもまねできない。
なるほど、もしかしたら俺の知らないインテルコンパイラでの
優位性というのはそこなのかもしれんね。

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

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



609 :デフォルトの名無しさん:2005/06/26(日) 10:35:28
>>603
なるほど、Intelのコンパイラが優れているということか。
そして変数の数がレジスタより多くなった場合は確かにやりにくい。
正直500ステップはやりたくないよ。実際バグ入りそうだし。

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


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

610 :デフォルトの名無しさん:2005/06/26(日) 11:14:51
>>609
>正直500ステップはやりたくないよ。
うーん。もっと長いのぼこぼこやってるんだわ(_asmで1000ステップ
2000ステップ)。そんなファイルが何個もある。スケジューリングは
根性の手動。もちろん全部見渡すなんてできないから、小ブロック
に分けて追いきれる範囲でやるんだが。

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

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

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


611 :デフォルトの名無しさん:2005/06/26(日) 11:34:42
このスレ読んで思ったが、64bit化を担当している人は、
漏れと同じくバリバリアセンブラ書く人たちなんだなー。

612 :デフォルトの名無しさん:2005/06/26(日) 11:49:32
>>611
つーかスレ違い(笑)

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


613 :デフォルトの名無しさん:2005/06/26(日) 12:34:36
64bitプログラミングネタに戻りましょうね

614 :デフォルトの名無しさん:2005/06/26(日) 12:34:46
Win32からx64コードを呼び出すネタに興味があるのですが
x64コード部分はハンドアセンブルで作るしかないのでしょうか?

615 :デフォルトの名無しさん:2005/06/26(日) 12:40:05
だれか >>562 に答えてくれお願いします

616 :デフォルトの名無しさん:2005/06/26(日) 12:48:35
マイクロソフトに聞けよ・・・

617 :デフォルトの名無しさん:2005/06/26(日) 13:28:12
>>615
たぶん「駄目」だと思う。

618 :デフォルトの名無しさん:2005/06/26(日) 13:47:08
>>617
ありがと

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


619 :デフォルトの名無しさん:2005/06/26(日) 14:05:56
>>618
32bitアプリからは64bitアプリは不可視なんじゃないかなぁ

620 :デフォルトの名無しさん:2005/06/26(日) 14:06:27
>>618
その場合はOSが受け渡す前に変換してくれるから何も考える必要ない
UnicodeウィンドウがANSIウィンドウに文字列含むメッセージ送信しても
問題ないのと同じ

621 :デフォルトの名無しさん:2005/06/26(日) 14:06:31
なお、答えられない人、「MSに聞け」、などの低脳な人はお断りです。

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

623 :デフォルトの名無しさん:2005/06/26(日) 14:12:04
> 32ビットのハンドル値を持ってるよ
32ビットのハンドル値を持ってるように見えると言った方が誤解を招かないか

624 :デフォルトの名無しさん:2005/06/26(日) 14:15:36
>>610
MMXを使っているようだが、64bit化するときはSSEにしないといけない。
簡単に変換できる?

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

625 :615:2005/06/26(日) 14:23:05
なんかできそうな雰囲気もありますね。x64機手に入れるときが
来たら、相互にハンドル交換でアクセスできるか試してみます。

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


626 :デフォルトの名無しさん:2005/06/26(日) 14:28:07
>>624
Win64がそのうちMMXがOKに…ならんよなあ。
CPUとしては使えるような感触が上読んでるとあるが。

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


627 :デフォルトの名無しさん:2005/06/26(日) 14:30:37
>>625
不完全ながらUserAgentで判別はできるが変えている人も少なくないし実用になるかな

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

629 :デフォルトの名無しさん:2005/06/26(日) 14:42:29
>>626
あ、もちろんSSE2整数のことだよ。ゴメン。
アライメントは、movq → movdqu(movdqaはダメ)なら問題ないが、

paddd mm0,[eax] → paddd xmm0,[eax]
これだと16byte alignがないと例外発生。

movdqu xmm1,[eax] / addd xmm0,xmm1
としなければならず、面倒だし、命令数が増えて遅くなる。

630 :デフォルトの名無しさん:2005/06/26(日) 14:44:56
>>627
おっしゃるのはサーバー側で切り替えるということ?

うーむ、IEのほうでobject64とか新タグ規定して、64bitIEは
そっちを優先して見に行くような機構があればいいのに、
と思った次第。


631 :デフォルトの名無しさん:2005/06/26(日) 14:48:04
>>628
ActiveX作るときって単にMFCっぽいプロジェクトからビルドする
だけなんだど、そのマルチアーキテクチャって、どの変でプログ
ラマが意識することなの?


632 :デフォルトの名無しさん:2005/06/26(日) 14:52:04
>>614
>>392

633 :デフォルトの名無しさん:2005/06/26(日) 14:53:43
>>629
>paddd mm0,[eax] → paddd xmm0,[eax]
このケースってどうしてもレジスタが足りないときにしかやらないから、
レジスタ増えた分で補えば何とかなりそうかな。

演算の読み込み元のストリームバッファがmmxレジスタのイメージ
で並んでるのって結構メモリの無駄が多いから、読み込みは大抵
movd -> unpackなんだよねえ、オレのケースでは。幸いかな

634 :デフォルトの名無しさん:2005/06/26(日) 14:56:02
>>632
オペコードマップ自体違うから無理じゃないかなぁ

635 :デフォルトの名無しさん:2005/06/26(日) 14:58:16
>>631
漏れは使ったことないくせに知ったかぶってるだけだから分からん
このへん見てテキトーに判断してくれ
http://msdn.microsoft.com/workshop/delivery/download/overview/inf.asp
つーかその昔はエミュレーションでx86のActiveX使えたのかよ
なんか納得いかんな
http://pc.watch.impress.co.jp/docs/article/960919/nt40us.htm

636 :デフォルトの名無しさん:2005/06/26(日) 15:05:53
>>634
use64セグメントではamd64
use32/use16セグメントではx86のオペコードを吐くんでしょ

637 :デフォルトの名無しさん:2005/06/26(日) 15:08:13
>>635
返事ありがと。
あーinfで複数のファイルをcabにして配布するってのがあったなあ

おれのはocxを直に配置だから、そこんとこ変えりゃあいいんだ。
……マンドクセ orz

638 :デフォルトの名無しさん:2005/06/26(日) 15:16:46
>>636
セレクタさえ作れればWow64からは可能だろうけどWin32からは無理だと思う

639 :デフォルトの名無しさん:2005/06/26(日) 15:21:34
>>638
392のすぐ後でWOW64限定という話が出てるから
それは前提だと思ってた

640 :614:2005/06/26(日) 15:59:20
>>632
その付近全部読んでいたはずなんだけど、読み飛ばしていたorz
Thx.

641 :デフォルトの名無しさん:2005/06/26(日) 20:39:48
インラインアセンブラ禁止は
x86廃棄のいい機会。

642 :デフォルトの名無しさん:2005/06/26(日) 21:00:14
廃棄してもいいこたあないよ。

レジスタたくさんあるCPUのアセンブラとか結構組んだけど、
面白さはどっちも同じだ。

いや面白がってどうするハハハ


643 :デフォルトの名無しさん:2005/06/26(日) 22:18:25
今回は、インラインアセンブラの禁止、そしてx87&MMX命令の禁止と
二つ重なってるんだよね。
32bitではインラインアセンブラ使えるし、WOW64ではx87もMMXも使える。
何故nativeの64bitで両方禁止したんだか...結局はMSの策略なのかな?

appleもIntelに乗り換えるわけだし、x86は今後も消えないと思うが...。

644 :デフォルトの名無しさん:2005/06/26(日) 22:20:47
ヒント:PARROT

645 :デフォルトの名無しさん:2005/06/27(月) 11:51:19
x87とMMXは、将来x86から消す予定なんじゃないのか?
これに関してはいいタイミングで禁止したと思うけど。

インラインは知らん。

646 :デフォルトの名無しさん:2005/06/27(月) 12:07:05
AMDのロードマップで、「今後AMD64にFPUサポートを追加」ってのがあったと思ったけど。


647 :デフォルトの名無しさん:2005/06/27(月) 20:22:17
ハードウェア的にはすでにサポートはあるでしょ。Win64がサポートしていないだけで。
16ビットサポートと同じ。

648 :デフォルトの名無しさん:2005/06/27(月) 23:06:53
じゃあ近い将来にx87がなくなることはないんだ。

649 :デフォルトの名無しさん:2005/06/27(月) 23:51:33
その前に人類は地球を食い尽くすよ

650 :デフォルトの名無しさん:2005/06/27(月) 23:56:56
すげーなx87

651 :デフォルトの名無しさん:2005/06/28(火) 00:35:57
x87がすごいのかよ

652 :デフォルトの名無しさん:2005/06/28(火) 12:31:06
Win64でいきなり87を潰すのもなんだかなー・・・・
SSE命令に移行させたい気持ちはわかるんだが、過去との互換性を最大限に
保とうってのがx86の利点じゃなかったのかよ。

ま、Intelはそれを守ってきたが、AMDがx86-64で命令コード変えて、互換性
を無くしてしまったが。ここまで市場が大きくなれば、少しぐらい勝手な事をして
も売れ行きは鈍らないと読んだんだろうな。

本当の理由は、オペコードに隙間がなさ過ぎて、命令の拡張が困難になった
ので、INCやらDEC命令を潰したんだっけ。そしてREXプリフィックスにした。

それはいいとして、32ビットモードでは87が動き、64ビットネイティブでは動かない
という奇妙な状態が出現している。しかもインラインアセンブリが不可とは。
大丈夫なんかね?

653 :デフォルトの名無しさん:2005/06/28(火) 12:37:17
>>652
え? x87動かないの? 上見るとWin64がコンテキストセーブの
対象から外しただけのようなこと書いてあるが。

もしかしてx87(MMX)レジスタ物理部分を64bit汎用レジスタ新設の
スペースに回したとか。


654 :デフォルトの名無しさん:2005/06/28(火) 12:59:28
SSEではなくx87やMMXを敢えて使いたい理由って過去の遺産以外に何かあるの?
どうせバイナリ互換のなくなるx64は過去を捨てる良いチャンスだと思うのだが。

655 :デフォルトの名無しさん:2005/06/28(火) 13:13:57
>>654
通常のCコード(整数演算)をSIMD化するとき
MMX化する
SSE化する
SSE2化する(XMMX)

これを比べると、一番効果あるのって経験上MMX化なんだよね。
オレと同じ感触持ってる人いない?

656 :デフォルトの名無しさん:2005/06/28(火) 13:58:10
`AMD64 Architecture Programmer's Manual Volume 5' を見てみると、
LONGモードでもx87使えると明記してあるね。

NetBSD/amd64はコンテキストスイッチでx87レジスタをちゃんと保存し
てるみたいだし、やっぱりMicrosoftの陰謀なのか。


657 :デフォルトの名無しさん:2005/06/28(火) 15:36:33
>>656
そいつはわかってる。WinXP64が、ネイティブモードで意図的にx87をサポート
してない事が問題なんだ。

658 :デフォルトの名無しさん:2005/06/28(火) 15:44:34
>>655
PentiumMではMMXが速いことが多い。
SSEは128bitだが、内部で64bit*2の処理に分解されるので遅いのだ。

ただ、Pentium4では圧倒的にSSE/2が速いし、
これから出る64bit対応MeromでもSSEが速くなっているだろう。

現状ではMMXが速くても、ターゲットとなる64bitCPUでは
SSEが速いので、さして問題にはならないと思う。

659 :デフォルトの名無しさん:2005/06/28(火) 16:13:27
今が変わる時期だとは思ってる。

660 :デフォルトの名無しさん:2005/06/28(火) 16:18:22
x64でレジスタが増えたといっても多い方ではないし
64bitデータの退避先として悪くないと思うんだが

661 :デフォルトの名無しさん:2005/06/28(火) 16:45:33
>>658
>ただ、Pentium4では圧倒的にSSE/2が速いし、
圧倒的というほど速くない。SSE/2で補強された命令
を使ってさらにMMXを速く動かすというのがオレの実感

>>660
消極的イクナイ


662 :デフォルトの名無しさん:2005/06/28(火) 17:08:51
で、ここで愚痴って何か変わるのかね?

MSがそうすると決めたんだから
その流儀に従うか、そうでなければMSを離れるかしかないよ。

663 :デフォルトの名無しさん:2005/06/28(火) 18:02:21
ここはぐちぐち言う場なのではなのかね?

ちなみにオレはMSにはさほど悪感情はもって無いよ

664 :デフォルトの名無しさん:2005/06/28(火) 18:44:38
64ビットのプログラミングモデルで、MMXが推奨されていないのは痛い。
XMMで完全代用できないんだよなー、レジスタこそ増えてるけど
L/S とか演算器の負担が増えて遅くなっちまう。

665 :デフォルトの名無しさん:2005/06/28(火) 18:51:05
世論がたくさん望めば巨人が動くこともある

666 :デフォルトの名無しさん:2005/06/28(火) 18:52:20
MMXレジスタが8本のままってのが悲しかったが、
論理演算だったら64ビットGPR使えばいいのか。

667 :デフォルトの名無しさん:2005/06/28(火) 20:30:24
とりあえず、インラインアセンブラ復活の声は結構あるはず・・・
けど、そんなことはMSだって実行する前からわかってたわけだから、動いてくれないよなぁ・・・
戦略上何気に重要そうだし・・・

668 :デフォルトの名無しさん:2005/06/29(水) 11:12:12
ICC9.1からEM64Tのインラインアセンブラをサポートすると
IDF 2005で言ってた。
Itanium2ではkernelモードでx87をサポートしていないので
全てのインラインアセンブラ削除だと。

669 :デフォルトの名無しさん:2005/06/29(水) 12:05:34
>>667
VCがインラインサポートしないなら、それを理由にICに
乗り換えるのもありかな。

670 :デフォルトの名無しさん:2005/06/29(水) 12:06:52
>>669
>>667>>668

671 :デフォルトの名無しさん:2005/06/29(水) 12:33:54
>>668
意図がよくわからん。Itanium2とx87とインラインアセンブリに何の関係が??


672 :デフォルトの名無しさん:2005/06/29(水) 13:09:40
Itanium2ではSSE/SSE2しかサポートしていないので、
既存のMMX、x87インラインアセンブラは使えません。
SSE2関数呼出しを使ってくださいという事でつ。

673 :デフォルトの名無しさん:2005/06/29(水) 13:19:39
Itaniumの浮動小数点演算命令がx87互換だった、ということ?
(自分はIA-64に関する知識はぜんぜんないです…)


674 :デフォルトの名無しさん:2005/06/29(水) 13:33:22
688見て思ったが、VCのインライン廃止は
x87やMMXがインラインで入った過去のコードを引き継がせないため?

・・・でもそれなら単に該当命令があるときエラー吐けばいいだけか。

675 :デフォルトの名無しさん:2005/06/29(水) 13:35:27
>>668
なんでx87をサポートしていないと、全てのインラインアセンブラが
禁止になるのか?

まあ、Itaniumなんか使わないからどうでもいいが

676 :デフォルトの名無しさん:2005/06/29(水) 13:36:58
>>674
MMXはインラインあたりまえだが、x87をインラインで書く香具師いる?

677 :デフォルトの名無しさん:2005/06/29(水) 13:48:20
インラインアセンブリ記述をサポートしなくなっただけで
asm モジュールのリンクは問題ないんだろ?

678 :デフォルトの名無しさん:2005/06/29(水) 14:02:50
>>676
俺は趣味でだけ。
80bit精度が欲しいときとか、アセンブラで簡単にsin使いたいときとか。

>>677
それはOKだろう。
でもインラインの手軽さ・便利さが惜しい。

679 :デフォルトの名無しさん:2005/06/29(水) 15:14:00
最近のAMD64版masmでは、x87命令に対応しなくなったな。
server2003 DDK付属のものは対応していたのに。

680 :デフォルトの名無しさん:2005/06/29(水) 15:28:36
>>675
誤解を招く書き方でスマんかった。
EM64T→MMX、x87インラインアセンブラのみ禁止。
IA-64→インラインアセンブラ全て禁止。
Itanium2の場合EPICといって、できるだけ並列実行できる様にコンパイラが
スケジューリングを行なうのでインラインアセンブラ全て禁止なんだと思う。

681 :デフォルトの名無しさん:2005/06/29(水) 18:13:43
gcc 使えば IA64 でもインラインアセンブラ使えるでしょ。
実際、ここいらではバリバリ使ってる。
ttp://lxr.linux.no/source/include/asm-ia64/gcc_intrin.h

682 :デフォルトの名無しさん:2005/06/29(水) 20:32:25
Linuxはよく知らないですけど、bugの修正の為に使ってるんでは。

683 :デフォルトの名無しさん:2005/06/29(水) 20:36:41
Linux 知らなくても IA64 知ってれば見れば分かると思うけど…
バグ修正じゃなくて、高速化のために使ってるんだよ。
いちいちアセンブラ部分を関数に分けて関数コールとかしてたら
遅いでしょ。

684 :デフォルトの名無しさん:2005/06/29(水) 22:21:44
・・・バカ?

685 :デフォルトの名無しさん:2005/06/29(水) 23:25:16
インラインアセンブラ禁止ネタ飽きた

686 :デフォルトの名無しさん:2005/07/02(土) 17:41:11
だれかネタ投下キボン

687 :デフォルトの名無しさん:2005/07/02(土) 18:30:14
>>686
Microsoft自身からネタ提供をやめるように仕向けたも同然なので、
このスレは間もなく潰れます。

688 :デフォルトの名無しさん:2005/07/02(土) 21:21:43
64bitプログラミング=インラインアセンブラで64bitレジスタをいじる
だよね。うん。俺もそう思う。
というわけで終了。

689 :デフォルトの名無しさん:2005/07/02(土) 21:36:24
逆に俺は
「64bit CPU 使ってまでアセンブラでちまちまやるのかよ。
 いい加減そんな枝葉の部分はコンパイラに任せちまえよ」
と思ってしまうわけだが。

690 :デフォルトの名無しさん:2005/07/02(土) 22:11:20
32bitのインラインアセンブラのプログラムに64bitのコンパイラの
出力が勝てるならそれでもいいよ

691 :デフォルトの名無しさん:2005/07/02(土) 22:42:26
おまいら動画のデコードでもしてるんですか


692 :デフォルトの名無しさん:2005/07/02(土) 23:16:40
インラインアセンブラで最適化できないなら
それはプログラミングと認められないよ

693 :デフォルトの名無しさん:2005/07/02(土) 23:48:46
>淫乱な熟女が
まで読んだ

694 :デフォルトの名無しさん:2005/07/02(土) 23:51:03
gcc 使えばいいじゃん。と言ってみる。

695 :デフォルトの名無しさん:2005/07/03(日) 07:14:18
gccはインラインアセンブラじゃない部分の最適化が(ryですから
全部アセンブラで書くしかないのでは

696 :デフォルトの名無しさん:2005/07/03(日) 10:15:44
全部アセンブラで書くくらいなら、コンパイラにアセンブラ出力させれば良いんでないの
ケースバイケースかもしれんが...

697 :デフォルトの名無しさん:2005/07/03(日) 11:07:50
>>696
空気嫁

Cのコードの中にアセンブラで書けることがプログラミング・ツールの要件
なんだよ。

698 :デフォルトの名無しさん:2005/07/03(日) 13:07:56
>>695
gcc 4.0 は結構頑張ってるよ。なんて言ってみる。

699 :デフォルトの名無しさん:2005/07/03(日) 15:29:13
>>697
えらく狭い要件だな。

700 :デフォルトの名無しさん:2005/07/03(日) 17:15:08
はぁ?プログラミング・ツールが利用方法を制限してどうする?
インラインアセンブラが使えないCコンパイラなんて聞いたことない。
MSは今すぐ方針転換すべき。

701 :デフォルトの名無しさん:2005/07/03(日) 17:27:19
インラインアセンブラが使えないCコンパイラって昔は結構あったな

702 :デフォルトの名無しさん:2005/07/03(日) 18:35:46
>>697
流れ嫁

703 :デフォルトの名無しさん:2005/07/03(日) 19:03:30
OSが独占されているからといって開発環境まで独占させる必要はない。
MSが駄目なら他社に期待すればいいだけだろう。

704 :デフォルトの名無しさん:2005/07/03(日) 21:39:17
なんか理由があったからそうしたに決まってるだろ。
MSにしたがってれば間違いないんだよこの業界は。

705 :デフォルトの名無しさん:2005/07/03(日) 21:49:06
OSサポートがないと拡張命令は使えないんだろ
つかインラインアセンブラが使えないってのは、FP/MMXの話だろ

OSがレジスタの待避をしてくれないとしたら?

706 :デフォルトの名無しさん:2005/07/03(日) 21:51:32
汎用レジスタからMM0-MM7にダイレクトに値を交換する命令って追加されてたっけ?

707 :デフォルトの名無しさん:2005/07/03(日) 23:26:04
>つかインラインアセンブラが使えないってのは、FP/MMXの話だろ
その書き方だと_asmはOKでfpu,MMX関連だけが駄目のように読める

708 :デフォルトの名無しさん:2005/07/04(月) 00:10:55
IA64の場合はどう?
やっぱアセンブラで書かせろとか言うの?

709 :デフォルトの名無しさん:2005/07/04(月) 00:30:51
>>708
Cがサポートしなくて(あるいはタコで)尚且つ効果的な命令があれば。
まあ実際のとこ民生用に普及しなければ触る機会は無いだろうな

710 :デフォルトの名無しさん:2005/07/04(月) 00:39:53
>>708
空気嫁

CPUやOSに関わらず、インラインアセンブラは使えなければならない。
その必要性は歴史が証明している。

711 :デフォルトの名無しさん:2005/07/04(月) 00:58:46
>>710
後学のためにどう「歴史が証明している」のか具体例を示して頂けまいか。

712 :デフォルトの名無しさん:2005/07/04(月) 01:11:58
歴史=このスレ

713 :デフォルトの名無しさん:2005/07/04(月) 01:31:02
>>693
そこで読むのをやめる喪前はどうかしてる

714 :デフォルトの名無しさん:2005/07/04(月) 06:20:04
>>713
熟女好きばかりでは無いという事だ

715 :デフォルトの名無しさん:2005/07/04(月) 09:18:02
まぁ、特殊なドライバでちょっとだけ特権命令を使いたい場合なんかはインラインアセンブラが
便利だけどチューニング目的なら_asm{}の前と後に付くレジスタ退避・復帰もあるから
asmファイルで別コンパイルだな。


716 :デフォルトの名無しさん:2005/07/04(月) 09:54:44
>>715
実際には復帰退避のコードってあまり生成されない気がする。
コンパイラが_asmをまたいだレジスタの継続使用をやらなくな
るだけで。

717 :デフォルトの名無しさん:2005/07/04(月) 09:58:47
どっちにしろそういう場合、_asm{}の外は
速度的にどうでもいい部分だから外なんだし

718 :デフォルトの名無しさん:2005/07/04(月) 10:09:14
んだんだ

719 :716:2005/07/04(月) 10:16:20
まあ、_asmの外のこまごまが気になるというのは、インライン化する
範囲の設定を勘違いしている可能性大

関数丸ごとアセンブラモジュールにするのと_asm使うのはほとんど
効果は変わらないよね

それにしても、アセンブラスレや最適化スレよりもなぜにこっちで盛り上がるのか(笑)

720 :デフォルトの名無しさん:2005/07/04(月) 10:46:34
>>716-717
何か勘違いしているようだが、パフォーマンス気にするなら頻繁に_asm{}を
出入りするようなコードは書かないはずだからファイル分割で良いだろうと言う意味。

721 :716:2005/07/04(月) 11:03:21
頻繁の度合いによるよ。

ループの外側に_asmを置くような例で、その関数が如何に何千回
呼び指されようと、ループの内部が数十万回繰り返すなら、ファイ
ル分割&モジュール全てアセンブラと差は無いと思う

722 :デフォルトの名無しさん:2005/07/04(月) 11:34:06
720は何も分かっちゃいねえと思われ

723 :デフォルトの名無しさん:2005/07/04(月) 14:10:32
>>721
いや、実際に性能にこだわるんだったらループ自体も含めinline asm化するしかないでしょ。
そうしないとinline asmによるコンパイラ最適化機能の抑制もあって旨くない。
まぁ俺の場合だとiccのvectorize等で十分だったりするから性能目的で_asm{}を使う事は
ほとんどないってのもある。正直、ドライバでコントロールレジスタ等が弄れない方が痛い。

>>722
お前がなにかわかっているようにも思えんがな。

724 :デフォルトの名無しさん:2005/07/04(月) 14:22:41
>>723
721は「差はないと思う」と書いているが、おまいは差があると思うの?
俺は差がないと思う。

719にあるように_asmの範囲をちゃんと考えることが大事なのよ。

725 :デフォルトの名無しさん:2005/07/04(月) 15:50:04
>>724
論点がずれている。インラインアセンブラが必須と考えているかどうかが問題。
差がないと思っているならインラインアセンブラは必要なしと考えている?

726 :デフォルトの名無しさん:2005/07/04(月) 16:15:05
はあ?ループ自体を丸ごと_asm{}内に書いて
ループ前後の性能に影響しない部分をC++で書くから
コンパイラの最適化抑止なんかどうでもいいだろうが
アホか?

727 :デフォルトの名無しさん:2005/07/04(月) 16:42:34
>>726
日本語が苦手な人なんですね。w

728 :デフォルトの名無しさん:2005/07/04(月) 18:49:28
>>725
あなたがずれてるよ。
インラインの利点は性能じゃなくて便利さ。
差がなかったらインラインの方が簡単でいいでしょ。

729 :デフォルトの名無しさん:2005/07/04(月) 19:00:32
短いコードならインラインのほうが楽だが
そうでないならマクロなどを使える方がいい

730 :716:2005/07/04(月) 19:45:18
>>723
えーと、オレは
>ループの外側に_asmを置くような例で、

と書いたんだが、(_asmがループの外)

>いや、実際に性能にこだわるんだったらループ自体も含めinline asm化するしかないでしょ。
と読んでくれい。_asm使うときでも少なくとも最内側のループごと
アセンブラにする。そんなのあたりまえっす。

俺が言ってるのは、関数モジュール丸ごとファイルを分けて
フルアセンブラ化しても、_asmに比べてメリットは無視
できるほど小さいってこと。

みんなそうだべ?

731 :716:2005/07/04(月) 19:48:45
>>726
そうそれ、言ってること正解。
でもまたーりしる

732 :デフォルトの名無しさん:2005/07/04(月) 22:54:28
インラインアセンブラ必須ということでFA?

733 :デフォルトの名無しさん:2005/07/05(火) 00:31:10
用途によりけりでしょ >インラインアセンブラ

まあ俺は普段使わんからあってもなくてもどっちでも構わんけど。

734 :デフォルトの名無しさん:2005/07/05(火) 03:46:29
>>732
なくてもかまわんが多数派だろ。

735 :デフォルトの名無しさん:2005/07/05(火) 03:51:22
>>728
「必要 or 不必要」と「便利 or 不便」は別の話ではないのか?

736 :デフォルトの名無しさん:2005/07/05(火) 07:29:58
インラインアセンブラなんて使わないからいらない

737 :デフォルトの名無しさん:2005/07/05(火) 07:43:36
最適化開発者の99%はinline asmをなくしたいと思っている。



738 :デフォルトの名無しさん:2005/07/05(火) 12:41:30
>>737
ソース

739 :デフォルトの名無しさん:2005/07/05(火) 14:20:25
実際、コンパイラ作ってる人にとっては
インラインアセンブラは嫌なのかね?

でもまあアセンブラの方が速いのは事実だから
ないと不便ではある。

740 :デフォルトの名無しさん:2005/07/05(火) 15:24:49
なんだ、VC++2005の64ビットモードは、インラインアセンブラ無しかよ。
糞だな。

741 :デフォルトの名無しさん:2005/07/05(火) 17:09:00
みんながアセンブラ使いになったらコンパイラが売れなくなるから。

742 :デフォルトの名無しさん:2005/07/05(火) 17:57:35
>>741
いや、それはその仮定自体ありえないw

743 :デフォルトの名無しさん:2005/07/05(火) 18:17:57
誰かポインタが64ビットになって幸せになった香具師はいないのか?

744 :デフォルトの名無しさん:2005/07/05(火) 21:03:28
雑誌記事やこのスレへの書き込みを見ていると、
単純にリコンパイルしただけで1割程度の高速化が
見込めるようだが(32bit比)、なぜ速くなるのだろうか。

例えば以下のような単純な例でも速くなったりする? 最適化は考えないとして
for(i=0; i<1000000000; i++){
x++;
}



745 :デフォルトの名無しさん:2005/07/05(火) 21:09:44
インラインアセンブラが使われたコードは
最適化の対象にならない。

最適化とはようするに、意味が同じになるようにコードを
組替えることなんだから、インラインアセンブラという
なにをしているのか解釈できないコードがあると最適化は不可能になる。

746 :デフォルトの名無しさん:2005/07/05(火) 22:27:41
>>744
>>203, >>343->>346, >>357, >>367-368

ページサイズが大きくなったのも貢献してるんじゃないかな

747 :デフォルトの名無しさん:2005/07/05(火) 23:07:25
アンカーサンクス

ざっと見たけど説得力あるのは
>レジスタ渡しになった事が原因の一つと聞いたことがある。
くらいかなあ。後はオレの知識不足から、他はホントに効果
あるのか判断できん要素ばかりだ。

mov eax,ebx

のスピードは32bitでもロングモードでも変わらんのでしょ?
あとは上でも散々不評なMMXレジスタのコンテキスト切り替え
の負荷軽減? そんなもん体感できないと思う…

>ページサイズが大きくなったのも貢献

スワップアウトが絡まない状況ではどうかしら?

748 :デフォルトの名無しさん:2005/07/05(火) 23:15:57
ページサイズって書いたのは、仮想アドレス→物理アドレスの変換テーブルのリーチが
長くなるって事。これについてベンチマークを見た事が無いので、あまり関係無いかも
しれないけど。

レジスタの数が増えた事は大きなプラスだと思う。特にコンパイラ屋さんは嬉しいんじゃ
ないかな。特に、Java みたいな Runtime が大掛かりな言語なんかは。

749 :デフォルトの名無しさん:2005/07/05(火) 23:35:12
>レジスタの数が増えた事は大きなプラスだと思う。
なるほどそれは単純に説得力あるね

750 :デフォルトの名無しさん:2005/07/06(水) 11:24:24
>>744
その例では同じ速さだと思う。

大きなメモリを使うアプリだったら、
単にOSのバージョンが違うという影響もあるだろうが。


引数のレジスタ渡し。
PentiumMは、スタックエンジンによって5%程性能が上がっているらしいので、
(push,pop,call,ret等のespを操作する命令に効く)
pushがmovで済んで引数つきretがなくなるだけでかなり速くなりそう。

逆に言うと、PentiumM(現状32bit)は64bit化すると
スタックエンジンの恩恵が薄れてしまうね。
Meromにもスタックエンジン載るのかな。


32bitで本当によく最適化されたプログラムは64bit化しても速くならないっぽ。

751 :デフォルトの名無しさん:2005/07/06(水) 11:33:20
>>750
速さに関してはやはりそうだね。ならばメリットは主にサイズという
ことになると思うのだが、ポインタ64bitに関してはレス無しか。

mallocや.bssセクションに4GB以上の領域を平気で指定するような
プログラミングスタイルに移行すると思う?

16->32bitの時は平気で64KB以上のメモリを確保するようになったわけだが。

752 :デフォルトの名無しさん:2005/07/06(水) 12:03:11
64KB以上のメモリは切実に欲しいけど、
4GBは一部のアプリでしか使わないからな。

俺も差し迫って4GBが欲しいわけじゃないので、
どうしてもポインタ64bitには興味がなくなってしまう。

753 :デフォルトの名無しさん:2005/07/06(水) 12:22:08
動画編集とか声高に言われているけど、1バッファリニアで4GB越え
を確保したりするのかな?

ああいうアプリは合計して4GB越えなんだろうかと。組んだこと
無いのでよく知らんが、HDも活用するスタイルでの組み方は
廃れちゃうんかねえ。

>どうしてもポインタ64bitには興味がなくなってしまう。
やっぱそうなんだよね。オレもですよ。

なんだか32bitは16bitほど簡単には消えない気がするなあ。
飽和したハード市場に、ネタに困ったメーカーが苦し紛れに
投入を急いで、メディアも記事のネタに困ってとりあえず足並
みそろえているだけの感が否めん。

このスレでこんなこと言ってゴメンよ

754 :デフォルトの名無しさん:2005/07/06(水) 12:24:47
アドレス空間が64bitになって嬉しいのは、ほんとに一部のアプリだけ
でしょ。データベースとか、動画関係とか。

それらにしたって、実際に4GB超のメモリを確保するんではなく、
FileMappingやmmap()で扱うんだろうなあ。


755 :デフォルトの名無しさん:2005/07/06(水) 13:07:22
データベースってほとんどファイルに書き出されていて、
ソートで縦1行舐めたりするときにメモリ上に持ってくるって
イメージ。

データ全部メモリ上に物理的に置いてしまって高速化しようという
魂胆なのかな?

756 :デフォルトの名無しさん:2005/07/06(水) 13:21:25
物理的にメモリ上に乗るかどうか別にして4G以上のファイル全体をとりあえず
mmapしちゃって、あとはリニアにアクセスできれば楽というのはあるな。
最近のデータベースとかはそういう作りが多い。
もちろんメモリとして見えるからといって無造作にアクセスするわけではなく、
効率上ページ境界とかある程度意識するけどね。

757 :デフォルトの名無しさん:2005/07/06(水) 13:42:33
なるほどプログラムが(新規に起こすなら)楽になるという方向か。

たしかにファイルマッピングはある種の処理の書き方が、普通に
ファイル中をseekするよりも異様に簡潔になる場合があるね。

758 :デフォルトの名無しさん:2005/07/06(水) 14:00:20
新規に作る場合は、「あ、32bitに収まんねえ」という小さな躓く石がなくなっていいね。
いづれ移行するので、今少しガマンすれば後は幸せになれるはず。

759 :デフォルトの名無しさん:2005/07/06(水) 14:01:12
開発者が楽になるという方向はわかったが、パフォーマンスアップは無いのかな?

上の例だと実際にデータベースにアクセスするユーザーには64bit化のメリット
がわかりにくい。ファイルマッピング使ってプログラムが綺麗になってもなあ。

データベースの64bit化でもパフォーマンスアップがプッシュされていたように
思うけど(ソースは忘れたが何かの雑誌の64bit化特集記事立ち読み)もし
性能がよくなるならそれは何故なんだろうか

760 :デフォルトの名無しさん:2005/07/06(水) 14:09:24
>>759
単純にレジスタ倍増と引数のレジスタ渡しのせいだとオモ。

メモリをちょこちょこ使うとか関数呼び出しが多いとかの、
「極限までの最適化はしてない」タイプのプログラムだと
相当に性能がブーストすると思われ。

761 :デフォルトの名無しさん:2005/07/06(水) 14:14:39
その「相当」というのは上に出ている1割かな?

762 :デフォルトの名無しさん:2005/07/06(水) 14:26:35
ゴメン。試したことはない。多分1割。

「相当」というのは、「無駄に関数呼び出しが多いプログラムだとかなり効くだろうな」
と思ったから。

いやね、アセンブラのありがたみが少〜し減ったなと思ったのよ。
少ないレジスタでメモリアクセスを極限まで減らした高速化も、
64bitだと潤沢なレジスタで簡単にできてしまう。
そういうプログラムに比べたら、最適化の甘いプログラムは
64bit化で「相当」高速化するだろうなと。

763 :デフォルトの名無しさん:2005/07/06(水) 14:33:50
まあ雑談なんでとくに謝ることは無いぽ。好印象ではあるけど
おれも実際そう大規模のデータベースはいらないし、適当言ってるだけw

全部オンメモリという力技でないと、ファイルマップする様なもので
HDガリガリ言い出したら、レジスタ増の恩恵も減りそうだね

764 :デフォルトの名無しさん:2005/07/06(水) 14:38:49
64bit化で、ビット幅2倍、リニアに指せる領域40億倍なのに、
速度は0.1倍増のみか。時間は距離に比べて手ごわいね

ふと l = tc を思い出した(cは光速定数) 全然関係ないけどw

765 :デフォルトの名無しさん:2005/07/06(水) 14:46:57
64bitの整数演算とかなら2倍以上速くなると思うけどねぇ。
んなもん、さほど使わんし。(趣味では素因数分解とかに使いたいけど)

並列性の抽出が難しいのはどこも一緒。

766 :デフォルトの名無しさん:2005/07/06(水) 17:29:08
>765
固定小数点演算は、64bit整数が速ければ十分恩恵を受けられそう。

767 :デフォルトの名無しさん:2005/07/06(水) 17:53:12
64bit幅の固定小数表現って用途としてどんなのがある?

768 :デフォルトの名無しさん:2005/07/06(水) 21:21:26
>>767
64bitコードでのポインタ演算w

769 :デフォルトの名無しさん:2005/07/06(水) 21:37:51
固定小数点数のポインタ?

770 :デフォルトの名無しさん:2005/07/06(水) 21:39:11
OS が 64bit 化されるのも嬉しいんじゃないかな。
今までアプリケーション側からは 4GB フルに使えなかった、
っつーか4GB を複数アプリと OS とで分け合ってた訳だから。

サーバサイドなら、Java のヒープを 2GB にして複数の VM を
起動とか、DB のキャッシュ領域に数 GB とか、メモリはあれば
あるだけ嬉しいよ。Opteron みたいなサーバ向けプロセッサには
必須なんじゃない?

771 :デフォルトの名無しさん:2005/07/06(水) 22:05:12
現実のマシンとして物理メモリはどれだけつめるんだろう?

772 :デフォルトの名無しさん:2005/07/06(水) 22:06:35
>っつーか4GB を複数アプリと OS とで分け合ってた訳だから。
32bitOSって2GBのアプリをいくつも起動できるんじゃないのか…?

773 :デフォルトの名無しさん:2005/07/06(水) 22:09:10
できるよ。物理メモリの話じゃないの?

774 :デフォルトの名無しさん:2005/07/06(水) 22:10:17
>>768
マジレスキボンヌ

775 :デフォルトの名無しさん:2005/07/06(水) 22:12:16
>できるよ。物理メモリの話じゃないの?
前後を読むとそういうニュアンスに読めなくもなくもないようなorz

776 :デフォルトの名無しさん:2005/07/06(水) 22:19:07
>>764
現実問題として、同じデータ個数の場合、64bitデータを引っ張ってくるのは
32bitに比べて倍のバス帯域が必要な訳で…メモリ速度が…

メモリセルは現実的に速度向上が進んで無いし、かと言って
CPU内部キャッシュのバス帯域もなかなか…

777 :デフォルトの名無しさん:2005/07/06(水) 22:20:35
PAE って使われてるの?

778 :デフォルトの名無しさん:2005/07/06(水) 22:46:55
>>776
メモリ速度は落ちてるのか?例えば1バイト読むとき
char a = *p;
とするわけだが、64bitの方が遅い?

779 :デフォルトの名無しさん:2005/07/06(水) 22:49:59
>>778
「1バイト読む」は変わらんけど、そのpの値はどこかのメモリから持っ
てこなきゃけいないわけで、それが遅いと思われ。



780 :デフォルトの名無しさん:2005/07/06(水) 22:56:22
単純に
movzx eax , byte ptr [ebx]

movzx rax , byte ptr [rbx]

を比較したらどうかな?キャッシュなどは同条件で、bにはもう
ポインタが設定済みとして。(ニーモミックは適当かも)

アドレスデコーダはロングモードでは倍の幅データが流れるような
気がするんだが、そこに速度の差は現れないのかな?

781 :デフォルトの名無しさん:2005/07/06(水) 22:57:01
ニーモミック→ニーモニック

782 :デフォルトの名無しさん:2005/07/06(水) 23:08:47
>>780
少なくともAthlon 64は最初から広い内部アドレスバスで設計されてるから
L1へヒットしている限りは同じ速度だと思うよ。EM64Tは知らんが。

783 :デフォルトの名無しさん:2005/07/06(水) 23:09:07
同じポインタでも2倍のメモリ食うし、
キャッシュヒット率が下がるのが懸念されるが
やっぱレジスタ増えるほうが効果高いんかなあ

784 :デフォルトの名無しさん:2005/07/06(水) 23:13:31
64bitでコンパイルしなおして1割速くなったというのは既出のようだけど、
逆に遅くなったケースはあまり聞かないね。レジスタ倍増効果が
あるのかもしれん。

遅くなった香具師いないの?

785 :デフォルトの名無しさん:2005/07/06(水) 23:20:58
>>782
おれがCPUの中の人だったら、32bitのときに遊んでるリソースを
どこかにまわしたいと思うかも。

786 :デフォルトの名無しさん:2005/07/06(水) 23:28:39
Pentiumのときすでに内部バスは64bit幅だった気がした

787 :デフォルトの名無しさん:2005/07/06(水) 23:52:40
>>786
外部データバス幅の話と混同してない?
内部バスっていろいろあるから、どのパスが64bitとか言わないと意味無いと思う。

788 :デフォルトの名無しさん:2005/07/06(水) 23:55:43
SPECint2000では32bitより64bitの方が遅くなったりしてるね。
↓の64bitLinux上でのテストでも、Peak Tuningではいくつかのテストで
 -m32オプションを付けて32bitバイナリ出力してスコア伸ばしてるし。
http://www.spec.org/cpu2000/results/res2005q2/cpu2000-20050613-04262.html

789 :デフォルトの名無しさん:2005/07/07(木) 00:00:22
Celeron Dに続いてSempronも64bit化されるね。
http://pc.watch.impress.co.jp/docs/2005/0706/amd.htm

790 :デフォルトの名無しさん:2005/07/07(木) 00:46:55
64bitになったからって32bitで済むなら、32bitオペランド使うだろうし。
何が何でも64bit長のロード/ストア使わなきゃいけないということはない。
(x64の場合)

791 :デフォルトの名無しさん:2005/07/07(木) 00:49:48
>>790
ポインタは何が何でも64bit強制でしょ? 上の一連、ポインタの
指す先の幅はまた別の話だと思う。それとも x64 で

movzx rax , byt ptr [ebx]
ってやっていいのかな?

792 :デフォルトの名無しさん:2005/07/07(木) 01:02:09
下位4G以下ならいいんじゃない。
まぁ、ポインタの値はOSしだいだけど。

WOW64上で64bitモードに切り替えるってやつならOKだろうねw

793 :デフォルトの名無しさん:2005/07/07(木) 01:24:01
>>792
linkで/LARGEADDRESSAWARE:NOオプションをつけると、プログラムイメージや
ロードされるDLLは、すべて2G以内に収まるよ。

もちろんAPIに渡すポインタは64bit長じゃないといけない。

794 :デフォルトの名無しさん:2005/07/07(木) 01:24:47
インラインアセンブラが使えないからどうでもいい

795 :デフォルトの名無しさん:2005/07/07(木) 03:14:40
ただたたきたいだけちゃうかと

796 :デフォルトの名無しさん:2005/07/07(木) 04:07:23
>767
32bitだと、シフトしたりして計算してるうちに、どんどん桁が足りなくなるじゃん。



797 :デフォルトの名無しさん:2005/07/07(木) 09:07:46
>>796
精度とかじゃなくて、どんなことに使えるか? というネタ投下。
食いつき悪いところ見ると、あまりそういう使い方してる人いな
さそうですね

x64 で何が悲しくて固定小数…といったところかな

798 :デフォルトの名無しさん:2005/07/07(木) 09:48:52
>>794
話を単純にするためにニーモニック風に書いてるけど、
ポインタの幅が倍になることによるバスレベル?の負荷増減
の話をしているんだと思う。アセンブラ限定の話題でも無いと思う

799 :デフォルトの名無しさん:2005/07/07(木) 09:53:34
>>793
>linkで/LARGEADDRESSAWARE:NOオプションをつける
もしかしてこれ付けるとuint32型へポインタを格納しても
事実上情報の欠落は無くなるということ?

お勧めはしないけどイイコトキイタ

800 :デフォルトの名無しさん:2005/07/07(木) 14:20:31
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個も入るので
普段は問題ないだろう。

801 :デフォルトの名無しさん:2005/07/07(木) 14:21:06
固定小数は、64bitならdoubleよりも精度があるわけで。
かけ算やシフトで半分犠牲にしてもfloat以上というのは魅力的。
・・・趣味の範囲に止まりそうですが。
つーか固定小数みたいなな速度優先だったら、SIMDのpacked 32bitでいい気も。
俺はMMXで水面のシミュを作った。

802 :デフォルトの名無しさん:2005/07/07(木) 19:18:19
>>801
掛け算したときの上位桁をCレベルで手軽にケアできる?
アセンブラならdstが128ビットであつかえるから問題ないが…

>俺はMMXで水面のシミュを作った。
なくなってムカついてる口ですね。蒸し返すようだけど、
倍精度の計算をSSE2でやるんなら、FPUを常に寝かせて
ずっとMMXとして扱えるじゃないか。

emms書く必要もなくなるなら非常に嬉しいんだが。

803 :デフォルトの名無しさん:2005/07/07(木) 19:22:13
80bit浮動小数点を亡き者にしたいのかもしれないな
MMXは巻き添え

804 :デフォルトの名無しさん:2005/07/07(木) 20:57:18
将来的にはMMXなくなってもいいと思うけどな。
SSE2整数がMMXより速くなるだろうから。

MMXとSSE2の両方あるのは、レジスタ数や名前空間の無駄。

805 :デフォルトの名無しさん:2005/07/07(木) 21:08:40
>>804
>MMXとSSE2の両方あるのは、レジスタ数や名前空間の無駄。

そんな事は君が決めることじゃない。

806 :デフォルトの名無しさん:2005/07/07(木) 21:20:10
そう、俺が決める。

807 :デフォルトの名無しさん:2005/07/07(木) 21:22:55
名前空間???

808 :デフォルトの名無しさん:2005/07/07(木) 21:24:26
>>806
ニート風情が何を大言壮語叩いてやがる。

809 :デフォルトの名無しさん:2005/07/07(木) 22:28:51
>>791
RIP相対32ビットで済む場合は32ビットじゃなかったっけ?

810 :デフォルトの名無しさん:2005/07/07(木) 22:37:11
>>809
プログラムカウンタ相対の話してるの? ジャンプ系統なら
リンカがより短い相対ジャンプに最適化してくれるんじゃないかな。

データを読み出すポインタの話とはまたちょっと違わね?

811 :デフォルトの名無しさん:2005/07/07(木) 22:50:33
データも64ビットだとグローバル何とかってのがあるってどこかで
見た記憶があるんだけど。
IA-64だっけ?

812 :デフォルトの名無しさん:2005/07/08(金) 00:23:54
>>810
x64では、データアクセスにrip相対アドレスを指定できる。

813 :デフォルトの名無しさん:2005/07/08(金) 01:17:52
>>812
Cからだとグローバル変数のアクセスへはそのアドレッシング
モードが使えそうだね。

その場合Cのポインタ変数へアドレスを代入するとオフセット値の
32bitが入るのかな?

なんかCではそのアドレッシングは使われない気もするなあ

814 :デフォルトの名無しさん:2005/07/08(金) 02:54:13
MSC AMD64版のアセンブラ出力見ると、グローバル変数のラベルは
32bitアドレスっぽい。

815 :デフォルトの名無しさん:2005/07/08(金) 08:42:18
>>814
リンカかWin64の制限で静的にリンクされるオブジェクトの
合計は2GBって決まっていたような希ガス。

816 :デフォルトの名無しさん:2005/07/08(金) 09:18:18
>>814
ロードされるアドレスを絶対番地で4GB超に設定できるのかな?

その場合でもオペコードのラベル部分はrip相対で32bit内に
収まるようになるなら >>815 のリンク制限はなにをかいわんや

817 :デフォルトの名無しさん:2005/07/08(金) 09:53:30
>>815
ベースアドレスを4GB超で設定できるよ。
ただ、イメージサイズは2GBまで。これ以上はリンカでエラーが出る。

相対ripを使うから2GB制限なのか・・・な?

818 :デフォルトの名無しさん:2005/07/08(金) 10:13:54
>>818
おれは適当言ってるだけなんだが、イメージサイズが2G越えたら、
端っこのオペコードがグローバル変数が置かれている
場所に届かなくならね? グローバルを真ん中に置けば4G付近まで
いけるけど、そんなせこい工夫はしないだろう。

.bssセクションにchar data[4GB]とかやってもイメージサイズは小さいままだよね。
この場合もdataのラベルは32bitなんか?

そもそも命令とデータ部分が同じアドレス空間にマップされているのかな。
命令のゼロ番地とデータのゼロ番地って同じもの入ってる?

819 :デフォルトの名無しさん:2005/07/08(金) 10:14:18
>>818>>817

820 :デフォルトの名無しさん:2005/07/08(金) 16:18:33
>>818=819
自分で確認すりゃいいじゃん。

821 :817:2005/07/08(金) 16:56:20
>>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

822 :デフォルトの名無しさん:2005/07/08(金) 19:07:38
>>821
要は2GB以上はmallocしろということかぁ
ならグローバル変数にrip相対32bit持ってくるのは
妥当と思われるけど

mov eax, dword ptr a+78787878h
これのソースオペランドののアドレッシングが明示しなくても
rip相対になるということ?

>>820
すまん環境が無いんだ。後学のためにぐだぐだ書いているんで、
目ざわりだったら読み飛ばしてくれぃ

823 :デフォルトの名無しさん:2005/07/08(金) 20:31:20
>>822
了解です。
NGワードにするからコテハンをつけて頂けると有難いです。

824 :デフォルトの名無しさん:2005/07/08(金) 22:14:53
>>816
できるよ。デバイスドライバは実際にその位置にロードされるし

825 :デフォルトの名無しさん:2005/07/08(金) 22:31:05
あった。「グローバルポインタ」だ。
http://msdn.microsoft.com/msdnmag/issues/1100/hood/
やっぱIA-64の話だった

826 :デフォルトの名無しさん:2005/07/08(金) 22:53:47
総合すると、グローバル変数のポインタを扱うとき、上位32bitは本質的には
遊んでるってことか。

827 :デフォルトの名無しさん:2005/07/09(土) 02:25:03
> NGワードにするからコテハンをつけて頂けると有難いです。

なんて自分勝手なやつだ!!

828 :デフォルトの名無しさん:2005/07/09(土) 05:40:14
> 目ざわりだったら読み飛ばしてくれぃ
と言ってるし…

829 :デフォルトの名無しさん:2005/07/09(土) 10:28:45
>>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の方が嬉しい。

830 :デフォルトの名無しさん:2005/07/10(日) 22:17:31
int a;
int *p = &a;
int *q = malloc(sizeof(int));
int *r = new int;

ってやったら、p,q,r の上32ビットに何が入ってますか?

831 :デフォルトの名無しさん:2005/07/10(日) 22:36:41
人類の夢と希望

832 :デフォルトの名無しさん:2005/07/10(日) 23:29:57
>>830
0xfffff800

833 :デフォルトの名無しさん:2005/07/10(日) 23:52:34
マジレスすると、OS、OS のバージョン、そのコード実行時に
既に確保されているスタックやヒープのサイズに依存するので
それらを限定せずに質問しても全く意味がない。

834 :デフォルトの名無しさん:2005/07/11(月) 00:04:50
Windowsの話は知らないけど、Linux/gccだとメモリモデルの指定なんてのが
あるんだね。
-mcmodel={small,kernel,medium,large}
16bit時代を思い出して、ちょっとほろ苦い気分だ。w

835 :デフォルトの名無しさん:2005/07/11(月) 00:08:01
>>830
ついでに
void func(void) {}
void *s = (void*) func;
して、sの値も調べてみよう。

836 :デフォルトの名無しさん:2005/07/11(月) 00:48:34
>>834
それって、Am29000 依存のオプションでしょ。Linux じゃなくて
組み込み用途のプロセッサ、それももうほとんど使われてないやつ
だよ。


837 :デフォルトの名無しさん:2005/07/11(月) 00:49:00
>>834
それ(smallとか)指定するとポインタの大きさが32bitになったりするん?

838 :デフォルトの名無しさん:2005/07/11(月) 00:50:59
>>836
いやいや、それがx86-64用オプションなんすよ
http://gcc.gnu.org/onlinedocs/gcc-4.0.1/gcc/i386-and-x86_002d64-Options.html
の一番下あたりね

839 :デフォルトの名無しさん:2005/07/11(月) 00:51:56
>>837
コードサイズのオプションみたい。ポインタサイズは常に64bitね。

840 :デフォルトの名無しさん:2005/07/11(月) 00:52:43
>>833
たとえばx64でlink時、/LARGEADDRESSAWARE:NOオプション付けたら

841 :デフォルトの名無しさん:2005/07/11(月) 00:56:16
ワラタ
-mcmodel=large
〜Currently GCC does not implement this model.

842 :デフォルトの名無しさん:2005/07/11(月) 00:59:48
int64 で64bit一発整数命令使って intとポインタが32bitのプログラミングモデルキボンヌ

843 :デフォルトの名無しさん:2005/07/11(月) 01:23:36
MIPS にはそういうのがあったな。N32って呼ばれてた。
(64bit ポインタは N64)

844 :デフォルトの名無しさん:2005/07/11(月) 02:01:56
16->32bit移行時には far とか nearとかいらなかったんだよ。
大半のアプリは16bitに収まらなかったんだから。

むしろ32->64bit移行時に64bitポインタがほしいアプリのため
だけにlargeポインタキーワードを作ってほしかった。

大半のアプリは32bitで収まるんだから。やること逆だよエライ人

845 :デフォルトの名無しさん:2005/07/11(月) 04:17:20
>>840
動的に確保されるメモリも下位2GBのメモリ空間に割り当てられる模様。
そのオプション付けると、VirtualAllocで2GB超の仮想アドレスを指定すると
エラーになる。

846 :デフォルトの名無しさん:2005/07/11(月) 04:46:30
>>844
OSの作りを無視してアホな要求するな。

847 :デフォルトの名無しさん:2005/07/11(月) 04:57:54
ハァ?アホな要求?
インラインアセンブラマンセー!!!

848 :デフォルトの名無しさん:2005/07/11(月) 09:47:20
>>845
イイコトキイタ、thx!

ってことは、事実上64bitアプリでint32bitとポインタ交換する
コードはOKってことか

849 :デフォルトの名無しさん:2005/07/11(月) 21:30:42
>>848
オッケーオッケー(^^)
int32にポインタを格納するのが「ツウ」ってことになるかもネ!

850 :デフォルトの名無しさん:2005/07/11(月) 21:47:03
インラインアセンブラは良くても
int32にポインタを格納するような
処理系依存は許しがたし

851 :デフォルトの名無しさん:2005/07/11(月) 21:48:43
windbg 6.5.3.7きましたよ

852 :デフォルトの名無しさん:2005/07/11(月) 21:48:51
>>849
勝手にやれば。後で困るのはおまいらだし。

853 :デフォルトの名無しさん:2005/07/11(月) 21:52:39
>>850
アセンブラの方が処理系依存

854 :デフォルトの名無しさん:2005/07/11(月) 21:58:51
>>853
OS依存を重視するかCPU依存を重視するかという問題だな。w
漏れの周りだとOSはWindows/Linux/MacOSいろいろ転がってるが、
CPUのほうは近い将来AMD64/EM64Tに統一されそうな勢いだ。
だからOS依存のポインタキャストよりはアセンブラのほうがマシと言え
なくもない。(8割くらいは冗談で書いてるからマジで突っ込むなよ)

855 :デフォルトの名無しさん:2005/07/11(月) 22:02:15
>>854
インテルマックは64ビットOSなの?

856 :デフォルトの名無しさん:2005/07/11(月) 22:04:48
>>855
最初は32bitで出るみたいだね。まぁ「近い将来」の話だから大目に見てくれ。w

857 :デフォルトの名無しさん:2005/07/11(月) 22:09:55
>>854
俺もマジで、x86系列でアセンブラ表記が統一されて欲しいと思ってるよ

でもWin64のMMX禁止は許せないね。アライメンがお気楽なのがx86の
いいところだったのにXMMXで代用しろといわれてもちとなあ…

858 :デフォルトの名無しさん:2005/07/11(月) 22:12:56
>>856
つかさ、あぽーは何でアプリの互換性にあれほど気を払わないんだ?
今後10年はインテルに託すそうだけど、10年たったらまた組み直しかよ…

そんなこっちゃいつまでたってもアプリベンダは本腰入れないね

859 :デフォルトの名無しさん:2005/07/11(月) 22:41:12
コンパイラなど存在しないかのような発言だな

860 :デフォルトの名無しさん:2005/07/11(月) 22:56:58
マックのアプリはそのときのCPU向けに最大限の最適化をかけますからね
再コンパイルで簡単に移植できるとは限らないのですよ

861 :デフォルトの名無しさん:2005/07/11(月) 23:07:34
>>859
実行形式での互換性が大事

>>860
そこまで持ち出さなくても、、、

同じWinでもフレームワークやミドルウエアが違えばいくら
コンパイラがあっても簡単に移行できないでしょ

ましてやOSが変わるんならお手軽移行は絶望的…
簡単に移行できた例ってありますか?

862 :デフォルトの名無しさん:2005/07/11(月) 23:13:24
あとユーザーの立場から

OSが変わると買ったアプリは間違いなくアボン Winでも
うまくいかない例は少なくないが、ぜんぜん増しである。

ユーザーは買ったアプリをリコンパイルできない。たとえその
アプリがリコンパイルするだけで移行できる優れものでも。

メーカーのサポート切れだともう打つ手なし。

客の買い替え意欲を激しく削がないか? 商売として正しいとは
とても思えないよ

863 :デフォルトの名無しさん:2005/07/12(火) 00:23:01
前のアプリを救うための環境は毎度提供してますけどね。>アップル

864 :デフォルトの名無しさん:2005/07/12(火) 01:12:37
なんでマカがでてくんだよ
うせろ

865 :デフォルトの名無しさん:2005/07/12(火) 01:15:26
>>864
アップルの話を書いただけで「マカ」呼ばわりするキチガイ発見

866 :デフォルトの名無しさん:2005/07/12(火) 01:15:26
マックがプログラマに嫌われてることが証明されましたね。

867 :デフォルトの名無しさん:2005/07/12(火) 07:25:08
マカのおかげで男の自信を取り戻したオレにはアップル嫌いとは言いにくい。
でもアップル嫌い。

868 :デフォルトの名無しさん:2005/07/12(火) 11:45:47
OS XのAPIって64bitに対応していないって本当?

869 :デフォルトの名無しさん:2005/07/12(火) 11:57:48
>>863
はたして今回はどうかな? ある意味楽しみでもある。傍観しているだけだが

今までもエミュレーション環境を提供していたのは知っているけど、
どれほど有用だったのかは疑問

870 :デフォルトの名無しさん:2005/07/12(火) 12:00:35
もう詳細が記事になってるよ

871 :デフォルトの名無しさん:2005/07/12(火) 21:40:02
記事のURL貼ってください

872 :デフォルトの名無しさん:2005/07/13(水) 01:53:57
Intel に移行した理由はノートPC用の省電力CPUのためだと
いう報道は複数出てたよね。
ノートPC 用の CPU である Pentium-M は今のところ 64bit
には対応してないし、Pentium-M の次世代である Yonah も
64bit に対応してないと言われている。従って、少なくとも
ノートPC は 32bit オンリーであると予想されるわけ。

873 :デフォルトの名無しさん:2005/07/13(水) 11:14:24
2年後だと微妙だな。64bitのノート用Meromが出る。
かと言ってYonahでは使えませんとも言えない時期だし。

874 :デフォルトの名無しさん:2005/07/13(水) 11:46:43
今度のマックはx86,x64が動くのか? できればexeそのまま行けるのキボンヌ

875 :デフォルトの名無しさん:2005/07/13(水) 11:52:54
Intel Mac については、IA-32でやるということが明言されている。x64
になる予定は(今のところ)ない。もちろんPE(.exe)でもない。



876 :デフォルトの名無しさん:2005/07/13(水) 11:56:54
たのむからexe動かしてくれ。そのほうがマックのためだ

877 :デフォルトの名無しさん:2005/07/13(水) 13:34:35
>>876
今でもVirtual PCで動くが。w
来年以降のCPUならVT(Virtualization Technology)装備だから高性能
Virtual PC(?)みたいなのが出ると思われる。別売りだろうけどね。

878 :デフォルトの名無しさん:2005/07/13(水) 13:46:53
別売りじゃあ商売のプットフォームにならんぞえ

879 :デフォルトの名無しさん:2005/07/13(水) 14:13:29
VTとパシフィカの仕様書を見る限りではそんなに性能が上がるとも思えないな

880 :デフォルトの名無しさん:2005/07/13(水) 20:25:57
>>876
マックがWindows APIを搭載すれば可能

881 :デフォルトの名無しさん:2005/07/13(水) 20:32:19
>>880
天才

882 :デフォルトの名無しさん:2005/07/13(水) 20:40:49
WineみたいなのをアップルがMSと提携して責任もって
組み込んでくれないかなあ。MSにメリットあるか分からんが、
OfficeMacとかをWin用のOffice作るだけでよくなるじゃん。

883 :デフォルトの名無しさん:2005/07/13(水) 21:21:12
>>882
Windows無しでWindowsソフトが動くってのはMSにとっては危険思想だろうな。
アップルがWindowsをバンドルしてくれるんなら大歓迎だろうけど。

884 :デフォルトの名無しさん:2005/07/13(水) 22:42:30
>>883
Macの値段の中にWin23APIのライセンス料を組み入れるんですよ

アップルにとっても膨大なWinのアプリがそのまま動くのはライセンス料
MSに払う価値があると思う。尚且つマックでしか動かないかっちょいいw
アプリが動くのなら変な物好きの食指は結構動いたりして

885 :デフォルトの名無しさん:2005/07/14(木) 08:37:02
Win23->Win32orz

886 :デフォルトの名無しさん:2005/07/14(木) 11:17:31
システム構成が既存 PC と大きく異なる上
市場全体から見ると誤差の範囲内のような Mac に
Windows を移植する意味があるのかどうか。
Office のときのような取引でもないとなあ。

887 :デフォルトの名無しさん:2005/07/14(木) 11:53:14
昔の(つーても安価になってからの)Macは頭だけPowerPCで、
パーツはWin機と一緒なんじゃあなかったの?

で、今回頭もx86に…

888 :デフォルトの名無しさん:2005/07/14(木) 12:37:17
>>884
膨大なごみアプリ群が幾ら動いても嬉しくない

889 :デフォルトの名無しさん:2005/07/14(木) 15:20:37
大半の人間がごみアプリに金を払う

890 :デフォルトの名無しさん:2005/07/14(木) 23:33:13
もう64bitの話題は無いのか

891 :デフォルトの名無しさん:2005/07/14(木) 23:48:07
>>882
Wineがらみだと下のような話も。
ttp://homepage3.nifty.com/toshi3/note10.html

MacBUが無くなるのはさびしいのでOfficeMacの開発は続けて欲しいなぁ。

892 :デフォルトの名無しさん:2005/07/15(金) 00:11:30
DirectXはうごくのかー?

あと、LinuxでWine試したけどあまり快適じゃなかった。
自前アプリをWineで動くように調整してリコンパイルして…
で何とか動かしたけどガビガビだった。

1GHz素のWin > 3GHzLinux+Wine

もちろんWineはすごいソフトだと思うよ

893 :デフォルトの名無しさん:2005/07/15(金) 00:12:34
300MHz素のWin > 3GHzLinux+Wine かも

894 :デフォルトの名無しさん:2005/07/15(金) 00:19:12
Win64ってDirectXが動きますか?

895 :デフォルトの名無しさん:2005/07/15(金) 00:22:57
>>894
動くよ。最新のSDK見れ。

896 :デフォルトの名無しさん:2005/07/15(金) 00:48:10
実際動かした人いる? 64bit化の感想キボンヌ

897 :デフォルトの名無しさん:2005/07/15(金) 01:28:52
マックは真の64bitなんだけどね。

898 :デフォルトの名無しさん:2005/07/15(金) 08:05:12
マックのAPIって、64bitポインタ渡せるの?

899 :デフォルトの名無しさん:2005/07/15(金) 08:34:08
何か Windows って無駄に大変なんだな...

900 :デフォルトの名無しさん:2005/07/15(金) 08:40:49
>>899
それだけじゃわからん。何がどうWinに比べて良いのか書いてくれ

901 :デフォルトの名無しさん:2005/07/15(金) 09:07:28
別に>>899はWindowsは大変とは言ってるけど、他のOSが変体じゃないとは言って無い。

902 :デフォルトの名無しさん:2005/07/15(金) 09:41:56
>>898
UNIX的APIは64bitコードから呼べるが、GUI関係のAPIは32bitコードからしか
呼べない。そういう意味ではWin64より面倒くさいよ。

903 :デフォルトの名無しさん:2005/07/15(金) 09:46:16
>>902
めんどくさいだけで64bitコードからGUI32bitコードを呼べるの?
そりゃあ大層便利なのでは?

904 :デフォルトの名無しさん:2005/07/15(金) 09:48:39
>>903
呼べない。だからGUI部分は32bitコードで書いてプロセス間通信。

905 :デフォルトの名無しさん:2005/07/15(金) 10:39:52
Σ(;゚д゚)ガビソ
なんだそれ…

906 :デフォルトの名無しさん:2005/07/15(金) 11:14:18
GUI は GUI でも X11 系の方は 64bit でも呼べるよな。
Cocoa じゃなくて gtk 使えばぁ?
てゆうか、なんでそうなってんの? わけわからん。

907 :デフォルトの名無しさん:2005/07/15(金) 13:24:47
X11はソケット経由だから使えるんじゃないか

908 :デフォルトの名無しさん:2005/07/15(金) 19:09:33
少なくとも NeXTSTEP の頃は、あのウィンドウシステムも
ソケット経由だった記憶があるけど (もちろんリモートから
もウィンドウを飛ばせました)、MacOS X だと違うの?

909 :デフォルトの名無しさん:2005/07/15(金) 21:56:31
CocoaはJavaと使うな、っていう御触れが出たらしいね
Javaだったら64bit対応なんて考えなくていいのに・・・

910 :デフォルトの名無しさん:2005/07/19(火) 12:13:20
もう64bitの話題は終わりなのか?

911 :デフォルトの名無しさん:2005/07/19(火) 16:24:36
Windows XP Professional x64 Edition
ソフトウェアコンテスト
http://win64xp.impress.co.jp/

くだらない議論なんかしていないで、作れyo


912 :デフォルトの名無しさん:2005/07/19(火) 16:30:53
おお、面白そう! とうぜん64bitを活かしたものじゃないと
応募資格無いんだよね!? おれは持って無いので静観
だが楽しみだ。どんなもんが出てくるだろう

913 :デフォルトの名無しさん:2005/07/19(火) 16:33:25
64bitCPUもらってもうれしくねーw

914 : :2005/07/19(火) 17:39:32
VisualStudio 2005の正式版リリースっていつなの?


915 :デフォルトの名無しさん:2005/07/19(火) 17:39:47
>>913
ワラタ

それはともかく、
>64bitならではの広大なメモリ空間、そして高い計算能力を活かしたプログラム
こんなソフトがどれだけあるんかねー?

ゲーム?64bitでしか動かないゲーム?w

916 :デフォルトの名無しさん:2005/07/19(火) 17:45:08
広大なメモリ空間を生かすつったら4GB以上だろうしなぁ・・・

917 :デフォルトの名無しさん:2005/07/19(火) 17:51:19
PAEを必要としている分野にしか普及しないヨカーンって言ったら怒る?
つーか個人用途で必要な香具師いるのか?

918 :デフォルトの名無しさん:2005/07/19(火) 18:38:40
レジスタ周りかと思われ

「64ビットを生かしたアルゴリズム」はMMXによりIA32にも移植でき、なおかつそっちのが便利だったからな。
多少それより速くすることはできても、新しいことやろうってのにはちと苦しいかと。

919 :デフォルトの名無しさん:2005/07/19(火) 18:45:27
64bitの単数演算できてもあんまうれしく無いんだ罠
16bitx4だから良かったのに、MMX禁止しやがって

920 :デフォルトの名無しさん:2005/07/19(火) 18:48:20
データベース系になるか知らんけど、人口無能ってどうよ?

32bitでは扱いきれないほどの語彙をオンメモリで処理して
応答速度を上げるとか、むりやり64bitを活かしたような仕様

921 :デフォルトの名無しさん:2005/07/19(火) 18:57:15
ようするにメモリがあればあるだけ意味のあるアプリだな。
しかもオンメモリで

もしかしたらテラバイト級のメモリ使えば進化するAIが〜

922 :デフォルトの名無しさん:2005/07/19(火) 19:27:14
メモリは安くなったんだからメモリスロット8つくらいのマザボが普通になればなぁ。
メモリさえ載ってればそれを使いたいアプリは出てくると思うよ。

923 :デフォルトの名無しさん:2005/07/19(火) 19:48:11
スピードのアドバンテージがほとんど無いんだから(MMXと_asm禁止で
むしろ遅い)32bitで不可能なサイズをmallocする以外に特色なんて
出しようが無いじゃん

924 :デフォルトの名無しさん:2005/07/19(火) 20:03:52
イメージ丸ごとメモリにキャッシュするライティングソフトとか(w

925 :デフォルトの名無しさん:2005/07/19(火) 20:08:30
>>924
それはHDにイメージ置くのに比べてどんくらい有利なんだ?

926 :デフォルトの名無しさん:2005/07/19(火) 20:12:46
>>923
いちおうSSE2はあるんだけどね。Pen4はこっちのほうが速いしレジスタ数倍増で多少L/Sの負担は減らせるのでは

927 :デフォルトの名無しさん:2005/07/19(火) 21:31:07
mmxレジスタをxmmxレジスタに替えて同じことさせようとすると
少なくともおれの北森では早くなったためしが無いよ。

違うことやらせる場合は確かに有用なときもあるけど、
mmxの代わりにはならん

Pen4のSSEが速いっていうのはどっかの受け売り?
そうでなくて自分で叩いてそうなったのなら素晴らしい

928 :デフォルトの名無しさん:2005/07/19(火) 21:41:31
>>927

速度有利な点
・128ビット化されたL/Sユニットがmovdqa使用で効果を発揮

速度不利な点
・ただでさえ小さいライトバックバッファやL1の消費量が2倍になる


まぁ俺のPenMでも速くなった試しがない。デコーダがネックらしくYonahで改善されるらしいが。
あと、x64で使う場合にはレジスタが増えるぶんある程度緩和されるのでわ?

929 :デフォルトの名無しさん:2005/07/19(火) 21:44:53
64ビット仮想アドレスが必要なアプリケーションが数少ないように、
インラインアセンブリ使いまくりMMX使いまくりのアプリケーションも数少ないだろう。


930 :デフォルトの名無しさん:2005/07/19(火) 21:50:14
>>929
数は少ないだろうが、本当に速くなって欲しいアプリはそういうアプリだったりする。

931 :デフォルトの名無しさん:2005/07/19(火) 21:53:32
>>928
確証は無いがおれが思うに、一番の問題はMMX演算ユニットを
二回呼んでるふしがあること。

xmmxではレジスタの幅が倍になってるから、unpckやシャッフル
の手間も増えることになるが、それで演算に二倍時間がかかると
もうね、なんかね

これじゃ現状だとMMXで手動パイプラインやったほうが速いんだよ。
x64や新しいCPUではどうなんだろ?

932 :デフォルトの名無しさん:2005/07/19(火) 21:56:25
>>929
64ビット仮想アドレスが必要なアプリケーションよりもMMXを
使いたいアプリはたくさん無いか?

933 :デフォルトの名無しさん:2005/07/19(火) 21:58:35
Athlon64の場合は64ビット化された汎用ALUが3つ。
こいつでMMXなみのパック演算ができれば文句なしなんだが。

934 :デフォルトの名無しさん:2005/07/19(火) 21:59:38
ゲームや画像・音声関係はもろにMMX/SSE使ってる。

935 :デフォルトの名無しさん:2005/07/19(火) 22:03:14
質問
折角64bitなんで、2Gオーバーのファイルを1度に一気に読み込みたいんだけど
標準関数じゃ出来ないよね?


936 :デフォルトの名無しさん:2005/07/19(火) 22:04:37
数値演算関係も。
他でもないインテルのIPPパフォーマンスライブラリもw

937 :デフォルトの名無しさん:2005/07/19(火) 22:06:43
>>935
64bitのfreadって、パラメータ関連が64bit化されてるんじゃない?
そういう問題じゃないの?

938 :デフォルトの名無しさん:2005/07/19(火) 22:10:58
Yonahの場合μOPsフュージョンによりXMMX演算は2つのMMXユニットに同時に流すことで実現できるようだ
手動パイプライニングの手間が省けレジスタも浮かせることができてウマーかと妄想している。

って、ますますいらねぇなぁx64





ICCもMMX/SSEが効果を発揮しない部分だとVC++以下かと思ってしまう

939 :デフォルトの名無しさん:2005/07/19(火) 22:15:03
>>937
あれ?fread()で読めるの?
なんか、前に32bit以上を読み込むと不安定と言うのを良く見たんで・・・
うちではたまたま読めただけかな?と・・


940 :デフォルトの名無しさん:2005/07/19(火) 22:18:50
>>935
(仮想)メモリにマップしちゃえばいいんじゃない?

941 :デフォルトの名無しさん:2005/07/19(火) 22:22:06
>>939
すまん試したわけじゃないんだ。ただfseekとかoffsetが64bit化されてたの
どっかで見た気がするから、できるのかと。Win32だと32bitでもファイルサイズ
関連は涙ぐましい努力で64bit幅持たせていた気がする

942 :デフォルトの名無しさん:2005/07/19(火) 22:22:16
size_tだって64ビット化されているだろうから感覚的には平気そうな気もするけどな。

943 :デフォルトの名無しさん:2005/07/19(火) 22:26:53
>>938
>2つのMMXユニットに同時に流す
一回分の時間で済むんだよねw

>ICCもMMX/SSEが効果を発揮しない部分だとVC++以下
おれもそんな感触受ける。でMMX/SSEは_asmで作りこんじゃってる
もんだからVCの結果の方が良くなってしまうなあ

MMXの話が出ると盛り上がるスレですね

944 :デフォルトの名無しさん:2005/07/19(火) 22:27:45
Win64のメッセージ関連APIってどうなってるのかすら知らん。
てか、SendMessageのwParam/lParamに64ビットポインタ渡せるのかすら

移植のこと考えると頭痛いな

945 :デフォルトの名無しさん:2005/07/19(火) 22:29:24
お、インラインアセンブラマンセーネタに戻りましたね

946 :デフォルトの名無しさん:2005/07/19(火) 22:36:40
>>944
>wParam/lParam
64bit幅になってないと話にならないはず。キャストも(DWORD)ってやってたの
(WPARAM)、(LPARAM)に直して準備だけはしている

947 :デフォルトの名無しさん:2005/07/19(火) 22:37:42
>>944
UINT_PTRとLONG_PTRだから大丈夫じゃね?

948 :デフォルトの名無しさん:2005/07/19(火) 22:40:53
>>945
みんなMMXが好きなんですよ。SSEやSSE2じゃだめなんですよ。
SSEやSSE2なんて、MMXで組み込み忘れた命令の補完的な意味が
最重要なんですよ。

あ、単精度四つの並列掛け算は別ねw

949 :デフォルトの名無しさん:2005/07/19(火) 22:42:53
SSEって何で積和演算無いの?

950 :デフォルトの名無しさん:2005/07/20(水) 12:21:43
>>927
北森で、SSE2整数のスループット-レイテンシは、2-2。
MMXは2-1(を2回)。
メモリ操作もMMXとXMMで同じくらいのタイミングだから
絶対にXMMのが速いと思っていた。

psadbwでも使ってる?

951 :デフォルトの名無しさん:2005/07/20(水) 12:27:11
>>919
汎用レジスタでMMX命令が使えれば言うことなしなんだが。

>>938
μOPsフュージョンはデコード・スケジュール・リタイヤが軽くなる。
現状のPenMでもpaddとかは2つのALUを同時稼動して1clkでできるよ。

952 :デフォルトの名無しさん:2005/07/20(水) 13:02:06
>>950
そうなん?

組み方が下手なだけかもしれんが、xmmxだとホントに早く
ならんのよ。データシートのスペックはともかくとして、
Pen4 PenM(バニアス)どっちも遅くなった。

mmxでレジスタ二個使って手動パイプラインガリガリに最適化した
コードをxmmxで128bitレジスタにまとめて命令数の削減を図った
バージョンが確実に遅かった。

プレフィックスの分、機械語サイズを見ると半分というわけにも
行かないから、その点でもxmmx不利じゃないかな

>psadbwでも使ってる?
いやそれは使ってない。psadbwは命令の動作が納得いかないと
どこかに書いてあった気がする。

953 :デフォルトの名無しさん:2005/07/20(水) 13:14:01
PenMは、たしかXMMベース演算はComplexデコーダじゃないと通らないからこれがネックになってるのでは
YonahではSSEμOpsフュージョンのおかげでどのデコーダパスでも通せるようになるとの話。

954 :デフォルトの名無しさん:2005/07/20(水) 13:36:31
>>952
そうなんだ。PenMは自分でもやるけど遅くなることが多い。

実際に遅いんだから反論してもしょうがないかもしれないけど、
psadbw以外にXMMのが倍以上遅い命令ってあったかな。
プレフィックスも、Netburstならトレースキャッシュで関係ないと思うし。

キャッシュラインをまたぐ機会が増えるとか?

955 :デフォルトの名無しさん:2005/07/20(水) 13:52:50
ライトバックバッファのミスとか。
論理レジスタ増えれば退避の頻度も減るし、性能は上がりそう。

ASCIIのベンチによればSIMD系はx64で目に見えて性能あがってた(Prescottの話)

956 :デフォルトの名無しさん:2005/07/20(水) 14:08:29
>>955
それは僥倖
やはり物理的に数が増えれば効果あるのは、汎用レジスタと一緒か。
ちなみに目に見えて、は1割?

957 :デフォルトの名無しさん:2005/07/20(水) 14:10:54
>>955
>退避の頻度も減る
手で組むときは途中での退避一切なしだよ(SRCから読んで
DSTへ吐くだけ)

958 :デフォルトの名無しさん:2005/07/20(水) 16:08:34
俺もMMXがなおざりにされて悲しいクチだ。
上でもいわれてるよーにXMMだと現存のどのアーキテクチャでも
スループットが半分に落ちる。

ネトバで128ビットLoadが高速にできるというのがあるのだが
Hammerでも128ビットLoadはスループット1なのだな。

VC Toolkit x64 ってまだ入手可能だっけ?

959 :デフォルトの名無しさん:2005/07/20(水) 21:22:02
>>958
x64のコンパイラならPlatform SDKに入ってる

960 :デフォルトの名無しさん:2005/07/21(木) 00:06:07
メモリが無尽蔵にあると単純に性能や品質が上がるアプリある?

961 :デフォルトの名無しさん:2005/07/21(木) 00:09:35
メモリは、単純に快適にするためだけに存在するので
動画のエンコードくらいだな。


962 :デフォルトの名無しさん:2005/07/21(木) 00:22:11
エンコとデータベース意外キボンヌ

963 :デフォルトの名無しさん:2005/07/21(木) 00:25:50
俺は使ったことないから詳しくは知らないけど
フォトショップって、必ずスワップファイルを必要とするぐらいメモリ食うんじゃなかった?

とりあえず、それ系のレンダリングなんかにも有効なんじゃないかな。

964 :デフォルトの名無しさん:2005/07/21(木) 00:27:18
それと、メモリがあるほど性能が上がるものとして、OSというのもありますよ。
もちろん、ディスクキャッシュとしての用途が大半ですが。

965 :デフォルトの名無しさん:2005/07/21(木) 00:28:33
まぁ営業的な話もあるだろうから話半分に聞いたほうがいいだろうけど、
http://ascii24.com/news/i/topi/article/2005/07/20/657082-000.html
3Dアニメーション制作現場ではOpteronの導入が進んでいる!?
「国内ではフルデジタルが主流になっているもののセルアニメーションの
雰囲気を残すことが重視されている点を指摘。そのためには情報量の多い
背景のレイヤーを複数重ねるといった手法が取られることが多く、大量の
メモリーが必要となるため、64bit化が切望されている現状があるという。」

966 :デフォルトの名無しさん:2005/07/21(木) 02:03:21
現状の環境で、64bitのメリットを広大なメモリ空間が使える と言う点だけで考えると破綻するよ。

だって、64bitの枠。すなわち従来ファイルからチビチビ読み込んでたデータを、一気に読み込んで
2Gオーバーのデータを扱えるんだけど
現在の環境で64bitとは言え、そんなにメモリ積んでるマシンって無いから、2Gのデータを読み込むと確実にスワップを起こす
スワップという事は、結局HDDからチビチビ読み込んで使うのと変わらない、むしろ更にオーバーヘッドがあるわけ。

そう考えると、64bitでしか出来ない事、より64bitだから出来る計算の効率に頭をおいたほうが良い。

例えば、64bit以上の変数を持つエンコード・デコード とかな
数回に分けてた計算を1度に行える。

967 :デフォルトの名無しさん:2005/07/21(木) 03:13:04
物理アドレッシングと論理アドレッシングを混同して考えると破綻するよ?w

968 :デフォルトの名無しさん:2005/07/21(木) 04:05:50
それは概念の話
どちらにせよ、物理的に割り当てられてるメモリ容量が現状32bitも64bitも同じなのが殆どなのは確か
こればかりはどうしようもない。


969 :デフォルトの名無しさん:2005/07/21(木) 04:09:02
物理アドレッシングと論理アドレッシングの混同はともかく
だいたい>>966が言いたい事には同意かな

上の方でfread()で2Gオーバーのファイルを読み込むって話があったが
現在の環境で2Gオーバーのファイルを読み込むのは無茶としか…


970 :デフォルトの名無しさん:2005/07/21(木) 04:19:55
そうなんだよな
そこなんだよ、従来から実装次第でいくらでも領域の問題は解決出来たけど
実行環境が32bitと64bitで実メモリが現状変わらないことが殆どなのが大問題

たまに64bit宣伝する時のうたい文句で、大容量のデータを扱える!
とか書いてるけど、んなもん従来から扱えたっての

#実装上どうにでもなる事はユーザー側からすると出来る事と見なせる。
#ユーザーがコーディングを行うわけじゃないから、ユーザーは出来るか出来ないかだけで通常判断

だから、64bitならでわのソフトが中々でないとか言うが、あれは無茶な話でもある。

971 :デフォルトの名無しさん:2005/07/21(木) 04:35:39
>>970
扱うことは出来るかもしれないけど、データアクセスの速さ違うでしょ。

972 :デフォルトの名無しさん:2005/07/21(木) 08:52:19
http://sourceforge.net/project/showfiles.php?group_id=69528&package_id=145079

NASAのWorld Windだけど
これをx64用にコンパイルできた人居る?


973 :デフォルトの名無しさん:2005/07/21(木) 09:31:03
結論としては、インラインASMができるようにすべき、ということでFA?

974 :デフォルトの名無しさん:2005/07/21(木) 09:35:46
>>973
流れ読んでないだろ。正しいけどw

975 :デフォルトの名無しさん:2005/07/21(木) 09:36:22
必要ありません。
インラインアセンブラがほしければ、自分で作ってやってください。

976 :デフォルトの名無しさん:2005/07/21(木) 09:57:34
>>972
ライブラリのFrameworkが32bitへの決め打ちなんで、Framework64ディレクトリへ全部変更するのがめんどくさい
あと、古い関数使ってるんで、2つほどエラー出る。



977 :デフォルトの名無しさん:2005/07/21(木) 10:05:43
>>949
SSE3で初めてついたらしい。
ベクトルの内積をやりたかったら
1つのXMMレジスタにxyzwをいれるんじゃなくて
4つのXMMレジスタにxxxx、yyyy、zzzz、wwwwと入れて
内積しろよと。これがSSEのポリシーだったんだよね。
いまさらながら追加されたのはなぜ?

978 :デフォルトの名無しさん:2005/07/21(木) 10:11:39
フーリエ変換とかで複素数使うからじゃないかな。
でも今更だよな。なぜ最初から入れない。。

979 :デフォルトの名無しさん:2005/07/21(木) 10:31:22
SSE3でも積和命令なんてないでしょ。

980 :デフォルトの名無しさん:2005/07/21(木) 10:49:52
どっちだよ!

981 :977:2005/07/21(木) 11:13:00
ごめん、勘違いしてた。
単に水平方向の加減算がついただけだった。

982 :デフォルトの名無しさん:2005/07/21(木) 11:18:54
まあそういうわけで、整数と小数の違いもあってSSEはMMXの
代わりにはならんちゅーこってす。あとはXMMXの性能がまとも
になるかMMXの復活を待つしか

983 :デフォルトの名無しさん:2005/07/21(木) 11:35:14
>>966 とそのレスへ
メモリの値が下がったとはいえ、100G〜テラ級の容量が
民生用に降りてくることになると思いますか?

たとえばVHSやDVDプレーヤ。安くなってとはいえ1万以下
とか数百円にはならんでしょ。メモリも今くらいの均衡から
さらに大容量に動くのかな。HDはTへ行きそうだけど…

984 :デフォルトの名無しさん:2005/07/21(木) 11:51:21
>>983
>メモリの値が下がったとはいえ、100G〜テラ級の容量が民生用に降りてくることになると思いますか
必ずなるでしょう。
>たとえばVHSやDVDプレーヤ。安くなってとはいえ1万以下とか数百円にはならんでしょ。
すでに1万円は軽く切っているが、数百円はむずかしいでしょう。そうなる前にそれらは消えていると思われます。

985 :デフォルトの名無しさん:2005/07/21(木) 12:11:22
>必ずなるでしょう
現状のx64アーキテクチャやOSの概念がそのままの延長線上で、
という条件ではどうか

SVHSが大して注目されなかったように、市場の要求があるか
どうかも大事じゃね? 要は今の周りの状況から見るとホントに
必要なのかと言いたいのだ

その点が32bitに移ったときと決定的に違う

だから大量にメモリを使って嬉しいアプリを聞いてみたのだが、
民生用として誰もが使うだろうというのはなさげ

986 :デフォルトの名無しさん:2005/07/21(木) 12:25:37
>>964
むしろこれかもしれん。ただしディスクキャッシュとかではなくて、
OSの変革を促す足場になる可能性がないだろうか

有用かどうかは判断できないが、インターフェイスの完全な3D化
にはメモリ倍増は貢献できそうだ。CUIからGUIになったときのように。

OSの操作系が別物になればそこで動くアプリもそれに沿って
メモリを使うような外観へと変わっていくだろう。

まあ半分たわごとだな

987 :デフォルトの名無しさん:2005/07/21(木) 12:43:51
>>980
マニュアルくらい読めよ!

988 :デフォルトの名無しさん:2005/07/21(木) 13:57:05
次スレ立ててくれ!

989 :デフォルトの名無しさん:2005/07/21(木) 13:57:28
だから物理メモリの話をしても意味がないんですよ

1GBのメモリを積むのが夢だった遥か大昔から

32bitの論理アドレス空間は狭すぎてギスギスしてたの

物理アドレスが欲しいなら今はPAEで十分

64bit化する必要はない

そうじゃなくて

64bit化が必要なのは論理アドレス空間が足りないから

物理アドレスと論理アドレスを混同するなと言ってるんですよ

990 :デフォルトの名無しさん:2005/07/21(木) 14:07:02
>MMX派諸氏
SSE4以降でXMMレジスタで64bitの部分レジスタとMMX相当命令をサポートすれば万事解決とか思ってるのは俺だけ?
128ビットSIMDが普及しないけどw

991 :デフォルトの名無しさん:2005/07/21(木) 14:13:21
>>991
SSEはいつまで経ってもしょぼいし
捨てて
AltiVecのライセンス受ければいいのに

992 :デフォルトの名無しさん:2005/07/21(木) 14:17:09
>>958
> ネトバで128ビットLoadが高速にできるというのがあるのだが
> Hammerでも128ビットLoadはスループット1なのだな。

ネトバはストアも同時にできるが、浜ーは次のクロックサイクル待ち。

993 :デフォルトの名無しさん:2005/07/21(木) 14:20:37
x86の拡張の範囲内でSIMDだけ3オペランド演算ベースにするってのは
ライセンス云々より技術的に難しい。

SIMDだけ別プロセッサ作ったほうが良くなる。
それならむしろIPFとPentiumMのデュアルコアでもやってくれって思うよ

994 :デフォルトの名無しさん:2005/07/21(木) 14:22:14
>64bit化が必要なのは論理アドレス空間が足りないから
論理アドレス空間が足らない例キボン

データベースとエンコ以外で

995 :デフォルトの名無しさん:2005/07/21(木) 14:25:15
>>993
と結局Cellみたいなのが
最適解になっちゃうのかな?

996 : ◆TimpoiKAMI :2005/07/21(木) 14:27:06
間に合うか??

次スレ
【IA64】64bitプログラミング総合スレ【x86-64】2
http://pc8.2ch.net/test/read.cgi/tech/1121923597/l50

997 :デフォルトの名無しさん:2005/07/21(木) 14:27:14
>>994
レンダリング

998 :デフォルトの名無しさん:2005/07/21(木) 14:27:51
記念マキコ

999 :デフォルトの名無しさん:2005/07/21(木) 14:28:27
>>990
それだと32bitと64bitで違うasmコード書かないと行けなくなる
もうちょっと互換性ほしい

1000 :デフォルトの名無しさん:2005/07/21(木) 14:29:05
1000だったら人妻に中田氏

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

237 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)