Visual Studio 2008 Part 22

1 名前：デフォルトの名無しさん mailto:sage [2014/10/13(月) 15:13:20.18 ID:yFRqmPNp.net] ■公式 ttp://www.microsoft.com/japan/msdn/vstudio/default.aspx ■前スレ Visual Studio 2008 Part 21 peace.2ch.net/test/read.cgi/tech/1290969016/ ■リンク Visual Studio 2008に搭載された17の新機能 ttp://www.atmarkit.co.jp/fdotnet/special/visualstudio2008_01/visualstudio2008_01_01.html 5000個のバグと戦った、MSが「Visual Studio 2008」RTM出荷 ttp://www.atmarkit.co.jp/news/200711/20/vs.html ■関連 Visual Studio 2013 part4 peace.2ch.net/test/read.cgi/tech/1404333757/ Visual Studio 2012 Part8 peace.2ch.net/test/read.cgi/tech/1392639689/ Visual Studio 2010 Part21 peace.2ch.net/test/read.cgi/tech/1412136476/ Visual Studio 2005 Part 27 peace.2ch.net/test/read.cgi/tech/1291513609/ その他テンプレ>>2-5 131 名前：デフォルトの名無しさん [2017/05/18(木) 08:52:36.67 ID:thYMhZbz.net] >>61 eメールのアカウントが必要 132 名前：デフォルトの名無しさん [2017/05/18(木) 09:02:35.23 ID:thYMhZbz.net] dll 133 名前：デフォルトの名無しさん [2017/05/18(木) 09:03:37.43 ID:thYMhZbz.net] >>125 コメント内容 パソコンの周りをきれい委にする。 134 名前：デフォルトの名無しさん [2017/05/18(木) 09:04:21.32 ID:thYMhZbz.net] 今の時代、パソコンでテレビが見れないとだめなのか。 135 名前：デフォルトの名無しさん [2017/05/18(木) 09:12:17.83 ID:thYMhZbz.net] .iso 136 名前：デフォルトの名無しさん mailto:sage [2017/06/03(土) 19:22:27.66 ID:cZuYHM9v.net] 古い奴だとお思いでしょうが、古い奴こそ新しいものを欲しがるもんでございます。 どこに新しいものがございましょう… 「傷だらけの人生」 藤田まさと作詞・吉田正作曲 137 名前：デフォルトの名無しさん [2017/06/15(木) 00:13:00.81 ID:0Bo/JfNC.net] KB957507って現在は入手不可能？ 138 名前：デフォルトの名無しさん mailto:sage [2017/07/06(木) 07:11:13.84 ID:6wMkdZx/.net] 温故知新（おんこちしん） 139 名前：デフォルトの名無しさん [2017/10/03(火) 08:49:19.60 ID:dPWSl44k.net] >>136 https://support.microsoft.com/ja-jp/hotfix/kbhotfix?kbnum=957507&kbln=ja-jp 出典は lsair.html.xdomain.jp/a/e/list-of-vs2008-hotfix.html いつものHotFixの画面だったから大丈夫かと・・・ 試してはいないけどw 140 名前：デフォルトの名無しさん mailto:sage [2018/01/20(土) 12:54:23.17 ID:bSTKludV.net] VC++2008にユーザプリプロセッサを噛ませる方法ってある？ 関連質問は以下。 mevius.2ch.net/test/read.cgi/tech/1514025223/395 VC++2017相当のラムダをVC++2008で使いたい。 MSVCのプリプロセッサだけでは多分無理っぽい。 自前のプリプロセッサをまず通し、結果をVSでコンパイルすれば確実にいけるのだが、 これをやる方法ってある？ (自前のプリプロセッサはスクリプト言語で書く) 141 名前：デフォルトの名無しさん [2018/01/20(土) 13:28:02.32 ID:5zEZap2N.net] .cppじゃなくて.cupみたいなソース書いて .cup->.cppにするならいける 142 名前：デフォルトの名無しさん mailto:sage [2018/01/20(土) 13:37:19.70 ID:bSTKludV.net] >>140 多分カスタムビルドツールだよね？今それを見ていたところ。 https://msdn.microsoft.com/ja-jp/library/hefydhhy.aspx とりあえずこれから試してみる。ありがとう。 143 名前：デフォルトの名無しさん [2018/01/20(土) 13:44:14.42 ID:5zEZap2N.net] 最近の人はmake書いたこと無いんか 144 名前：デフォルトの名無しさん mailto:sage [2018/01/20(土) 14:14:17.24 ID:bSTKludV.net] >>142 手動makeか。まあその手もあるか。 145 名前：デフォルトの名無しさん [2018/01/20(土) 14:25:54.52 ID:Hc/lJP5p.net] Makefile家や 146 名前：デフォルトの名無しさん [2018/01/20(土) 14:27:12.33 ID:4AOaXNlF.net] make書いたら負け 147 名前：デフォルトの名無しさん mailto:sage [2018/01/20(土) 14:40:08.73 ID:bSTKludV.net] まあどっちでもいいと思うが。 Cマクロで出来れば一番簡単だが、どうやらこれは無理。 ならば次善策は自前でのスクリプティングであり、 主な手間はmakefile/カスタムビルドツール設定ではなく、 スクリプトを作成することなんだから、この際起動はどっちでもいいだろ。 148 名前：デフォルトの名無しさん [2018/01/20(土) 15:02:15.30 ID:4AOaXNlF.net] Dで書いてobjリンクする 149 名前：デフォルトの名無しさん mailto:sage [2018/01/20(土) 15:57:47.74 ID:bSTKludV.net] ちなみに、以下確かに動くのだが、これってどうなん？ https://stackoverflow.com/questions/472667/lambda-expressions-support-in-vs2008-sp1 (超絶簡単なソースしか試してないが) ・コンパイルは c:\windows\microsoft.net\framework\v2.0.50727\system.dll : warning C4945: が出つつも通る。 ・F5でのデバッグ実行が出来ない。「デバッガのプロトコルがデバッグされる対象と互換性がありません｣ ・IntellisenseはVC++/CLIでも機能している。 >>147 なおラムダはGUIからの機能選択部で使うので、 結構な頻度で追加/書き換えしており、ソースは分離したくない。 普通に考えればVC++2017に上げればいいだけではあるが、 環境を変更すると色々他の問題が発生するかもしれないのでちょっと無理しようとしている。 150 名前：デフォルトの名無しさん mailto:sage [2018/01/20(土) 16:02:31.52 ID:5zEZap2N.net] 本質と関係ない話題の方が盛り上がるのが2ch 151 名前：デフォルトの名無しさん [2018/01/20(土) 16:09:16.48 ID:5zEZap2N.net] >>148 >確かに動くのだが、これってどうなん？ 動くならそれでいいんじゃない？ 同じレス内で >環境を変更すると色々他の問題が発生するかもしれないので っていうのとは真逆の態度だとは思うが 152 名前：デフォルトの名無しさん mailto:sage [2018/01/20(土) 23:47:48.29 ID:bSTKludV.net] まだカスタムビルドには組み込んでいないが、スクリプトを作成し、動作することを確認した。 知恵を絞ってくれた人はありがとう。現在の解決策は以下。 ・#define LAMBDA でインラインの展開を行う。 ・クラ� 153 名前：X宣言部はスクリプトで作成し、これをincludeする。 VS2017に上げてもLAMBDAマクロ宣言部だけの変更(1行)で済む予定なので、まあまあかと。 とりあえずこれで様子見します。 [] [ここ壊れてます] 154 名前：デフォルトの名無しさん [2018/04/10(火) 07:51:46.77 ID:25Me0atb.net] 最終列車に乗り遅れるな VC++2008Expressサポート切れまであと1日。 2018年4月11日（水）でサポート終了。 修正パッチの入手の終わってない人は忘れないように。 155 名前：デフォルトの名無しさん [2018/04/10(火) 14:36:15.41 ID:JIHFaEMv.net] GJ 156 名前：デフォルトの名無しさん [2018/04/11(水) 01:33:09.61 ID:PizNPnSY.net] 必死だなぁｗ 157 名前：デフォルトの名無しさん mailto:sage [2018/04/11(水) 13:05:30.31 ID:Gexxa1fK.net] https://forest.watch.impress.co.jp/docs/news/1116235.html 「Microsoft Visual Studio 2008」のサポートが終了 〜無償版「Express Edition」も 「Microsoft SQL Server Compact 3.5」なども対象 158 名前：デフォルトの名無しさん [2018/04/11(水) 13:06:06.48 ID:bG1z7LTF.net] ああ終わったか 乙でした 159 名前：デフォルトの名無しさん [2018/04/11(水) 13:26:11.45 ID:bG1z7LTF.net] てｓｔ 160 名前：デフォルトの名無しさん [2018/04/12(木) 14:51:25.15 ID:nqXIWDjI.net] 《 後継開発環境のご案内 》 LinuxMintのダウンロードはこちらから。 Main Page - Linux Mint https://linuxmint.com/ https://linuxmint.com/download.php --------- AGK無料試用版の配布開始(リンク先にWindows､Mac､Linux版のファイルが直接置いてある) AppGameKit - Free Trial Version https://www.appgamekit.com/trial 無料試用版 AppGameKit無料トライアル版は､AppGameKitの主要な領域すべてにアクセスできるため､ 完全に評価することができます｡完全版の有料版には､次の主要機能が含まれています｡ ･ Android､iOS､HTML5にプロジェクトをエクスポートする ･ アプリをデバイスに直接ブロードキャストする ･ コンパイルされたプロジェクトからウォーターマークを削除する 161 名前：デフォルトの名無しさん [2018/04/16(月) 00:56:57.36 ID:CadfvnK3.net] WineでPassmarkとHDbenchを試したところ、シングルスレッド性能はWindowsより若干高く、マルチコア性能は半分程度に留まった。 おそらくWine内部処理の都合と言うことにｗ また、DirectXテストは通らなかった。GDIクラスのみ。 162 名前：デフォルトの名無しさん [2018/04/22(日) 03:49:49.80 ID:CAx4oxnE.net] …って言う訳で、早速Linuxのパフォーマンステスト。 64x64ピクセルの2Dスプライトの表示枚数をカウントして、パフォーマンスを計測してみよう。 ダウンロードは以下のリンクからどうぞ。 upload.saloon.jp/src/up27011.zip Firefoxブラウザの右上にダウンロードマーク（↓）の付いたアイコンをクリックして、ファイル アイコンをクリックすると、zipファイルの入ったフォルダが表示されるので、右クリックして 「 Extract Here 」 を選ぶ。 次に、「 agk_sample 」 と言うフォルダが作成されるので、ダブルクリックする。 フォルダの中に 「 abc 」 と言う拡張子のないファイル、「 media 」 と言うランタイムの入った フォルダが作成されている。 「 abc 」 と言う拡張子のないファイルが、実行ファイルで、これを迷わずダブルクリックすれ ばよいｗ だいたい2分ぐらいで最大表示枚数が安定する。 プログラムの終了は [ ESC ] キー。 Celeron G1820 + Intel HD無印 で1500枚程度。 163 名前：デフォルトの名無しさん [2018/05/23(水) 19:42:34.90 ID:Au5e7VGg.net] 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方 役に立つかもしれません グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』 CRP7I 164 名前：デフォルトの名無しさん mailto:sage [2018/05/24(木) 10:53:48.52 ID:cPlRxlDn.net] CRP7I 165 名前：デフォルトの名無しさん [2018/05/25(金) 19:20:37.97 ID:TsdeULHr.net] ではではｗ Intel Pentium G5 CoffeeLake 総合スレ anago.open 2ch.net/test/read.cgi/jisaku/1526884213/ 166 名前：デフォルトの名無しさん [2018/07/04(水) 22:48:21.01 ID:gFgZc5FG.net] TJH 167 名前：デフォルトの名無しさん mailto:sage [2018/07/06(金) 12:24:57.09 ID:uTPDH9XV.net] TJH 168 名前：デフォルトの名無しさん mailto:sage [2018/08/23(木) 09:04:57.51 ID:by5uxKdK.net] VC9 SP1 Hotfix For The vector<function<FT>> Crash がダウンロードできないのですが、 どなたかアップロードしていただけないでしょうか？ https://blogs.msdn.microsoft.com/vcblog/2008/12/17/vc9-sp1-hotfix-for-the-vectorfunctionft-crash/#9234449 169 名前：デフォルトの名無しさん mailto:sage [2018/09/13(木) 23:46:46.29 ID:MPXnmy/B.net] 起動の仕方で浮動小数点演算に誤差が発生するのだけど、理由が分かる人居ますか？ 今のところ、 A. Debugビルドのバイナリをダブルクリックして起動 B. Releaseビルドのバイナリをダブルクリックで起動 C. DebugビルドまたはReleaseビルドでF5で起動 の3種類出来てる。それぞれ微妙な誤差だ。(doubleの下位ビット） AとBの違いについては諦めていたのだが、(なお両方とも/fp:precise) 実はCもあると気づいてしまった。 なお、バイナリをダブルクリックして起動、それにIDEをアタッチしても結果は変わらない。 それぞれAまたはCが出る。 何かIDEの設定を間違っているのだと思うのだけど… 170 名前：デフォルトの名無しさん [2018/09/14(金) 12:43:29.26 ID:5xDSXwp0.net] 0fillしてないんだろ 171 名前：デフォルトの名無しさん mailto:sage [2018/09/14(金) 13:05:12.93 ID:XcO59d50.net] 再現性は100%なので、初期化のミスではない。（と思っている） 演算途中の結果を double なら16進16桁でテキストにダンプしている。 数値だけではないが500MB程度のファイルが出力され、 diff を取ることによりレグレッションテストをしている。 今のところ、A/B/Cの3種類しか出ない。 初期化忘れならこうはならない。(はず) 172 名前：デフォルトの名無しさん mailto:sage [2018/09/14(金) 13:09:49.07 ID:Qw2nkUqU.net] MSのエンジニアを信じるか、再現可能なソースも示さず問題だ問題だ言ってるとこの馬の骨とも知れない奴を 信じるかって言われたら迷うことなく前者を信じるw 173 名前：デフォルトの名無しさん mailto:sage [2018/09/14(金) 14:43:10.29 ID:XcO59d50.net] 俺はIDEのバグだとは思っていない。 何かIDEの設定があって、俺がそれを適切にやってないのだと思っている。 色々見た限り、俺は /fp:precise しか発見出来なかった。 ただしこれは一応適切に設定されている。 他にないかな？ということ。 174 名前：デフォルトの名無しさん [2018/09/14(金) 15:49:43.21 ID:cyu8WCuc.net] IDEじゃなくてコマンドラインからコンパイラで直接コンパイルしても一緒？ 175 名前：デフォルトの名無しさん mailto:sage [2018/09/14(金) 16:14:47.18 ID:XcO59d50.net] どういう意味？ (どれとどれの違いにフォーカスしろと？) 俺はバイナリに問題があるとは思っていない。 何らかの理由で浮動小数点のモードが切り替えられたりしてないかを疑ってる。 だからIDEの設定とか、そっちを見てる。 Release/Debugのバイナリは当たり前だが違ってる。 /O2と/Od等だ。 ただそれでも /fp:precise の場合は 浮動小数点の演算順序を入れ替えない範囲で最適化される事になっている。 逆アセンブラは見たけどちょっとグチャグチャすぎてよく分からなかった。 (見た範囲では演算順序の入れ替えはないように思えた） 176 名前：デフォルトの名無しさん mailto:sage [2018/09/14(金) 16:25:44.73 ID:2giHKuhd.net] 177 名前：="reply_link">>>167 double型を使っていても、SSEのXMMレジスタなどを使う場合、昔のfld, fst, fmulなどを使う場合より基本的には精度が落ちる。 丸めの方向も四捨五入、正負どちらかの方向への丸めや切り捨てなどの他、確か、精度を気にしない、なんてオプションもあった気がする。ゲームで使うことを想定しているらしい。 SSE用に最適化を掛けると、速度は上がるが精度は落ちるかも知れない。 [] [ここ壊れてます] 178 名前：デフォルトの名無しさん mailto:sage [2018/09/14(金) 17:45:18.51 ID:XcO59d50.net] >>174 今の範囲ではSSEは使っていない（はず) 「拡張命令セットを有効にする」は「設定無し」になっている。（多分デフォのまま） 見た目全部x87が出てたし。 やっぱRelease/Debugの違いから攻めろって感じか？ 俺もF5起動で結果が異なるってのは全く予想してなかったし。（ただしこちらの問題だろうけど） 演算部分は場合によってはSSEのアセンブラに差し替えるので、 問題になる場合には、Release/Debugの違いはこれで吸収するつもりだった。 (これは１ヶ月後にやるかも） 179 名前：デフォルトの名無しさん mailto:sage [2018/09/14(金) 17:48:23.40 ID:HVgt1gkj.net] 浮動小数点の誤差を考慮に入れてないというイージーな仕様バグですね。 180 名前：デフォルトの名無しさん [2018/09/14(金) 21:39:03.40 ID:fXySkelb.net] 再現するｺｰﾄﾞをみないとなにもわかるわけがない 低学歴知恵遅れが書くｺｰﾄﾞなんかなにをやってるか分からないからな ごちゃごちゃいってないで再現するｺｰﾄﾞをあげなさい 181 名前：デフォルトの名無しさん mailto:sage [2018/09/15(土) 06:26:55.94 ID:/OsufeBT.net] 月並みな意見だけど、 「症状を再現できる最小のソースと初期データ、それとコンパイル環境」 まで切り詰めてみるのが早道じゃないかな。 ちょくちょく発生する事例なら、解決策を知ってる誰かが教えてくれてるかと。 週末、より多くの人が質問を見ることを期待して待つ手もあるけど。 182 名前：デフォルトの名無しさん mailto:sage [2018/09/15(土) 08:56:57.28 ID:9ZmI9OgI.net] より基本に立ち返ろう そもそも誤差はあるのか？ 計算結果を何を使ってどう出力しているかだけでもソースを見せてくれ 183 名前：デフォルトの名無しさん mailto:sage [2018/09/15(土) 13:36:34.65 ID:heijdb7v.net] >>175 x87でも誤差を丸める方法を fpu control word で設定できる事は出来る。 四捨五入と切り捨てなどを切り替えられる。 184 名前：デフォルトの名無しさん mailto:sage [2018/09/15(土) 13:42:47.95 ID:heijdb7v.net] fpu control word で、丸め方法と、精度の二つを独立に設定できる。 この精度の設定で、メモリ上の表現がdouble型でも、計算時のfpuの内部精度が変わってくる。 普通は64bit doubleに対して、fpu内部では80bitの精度で計算する。仮数部のbit数は、確か、それぞれ、53BIT、64BITだったかな。 185 名前：デフォルトの名無しさん mailto:sage [2018/09/15(土) 14:05:09.61 ID:heijdb7v.net] Intel® 64 and IA-32 Architectures Software Developer’s Manual [Vol 1] 11.6.8 Compatibility of SIMD and x87 FPU Floating-Point Data Types SSE and SSE2 extensions operate on the same single-precision and double-precision floating-point data types that the x87 FPU operates on. However, when operating on these data types, the SSE and SSE2 extensions operate on them in their native format (single-precision or double-precision), in contrast to the x87 FPU which extends them to double extended-precision floating-point format to perform computations and then rounds the result back to a single-precision or double-precision format before writing results to memory. Because the x87 FPU operates on a higher precision format and then rounds the result to a lower precision format, it may return a slightly different result when performing the same operation on the same single-precision or double-precision floating-point values than is returned by the SSE and SSE2 extensions. The difference occurs only in the least-significant bits of the significand. 186 名前：デフォルトの名無しさん mailto:sage [2018/09/15(土) 14:14:58.92 ID:heijdb7v.net] >>182 書いてある意味は、 「SSEやSSE2だと、float(32BIT)やdouble(64BIT)のまま計算するが、x87 fpuだと、もっと高い精度であるところの 　　『double extended-precision floating-point format（拡張倍精度浮動小数点フォーマット:80BIT)』 で計算を実行して、丸めてから、floatやdoubleに戻す。 そのため、SSE/SSE2 と x87 fpuでは結果が変わることがある。 しかし、その場合でも結果の違いは、仮数部の LSB (最も価値の小さいBIT)の1BITにだけ現れる。」 というような事。 187 名前：デフォルトの名無しさん mailto:sage [2018/09/15(土) 16:09:28.75 ID:aC3C7hdp.net] 揚げ足取りだけどLSBを「最も価値が小さい」って直訳はいかがなものかなw 普通に最下位ビットじゃないの？ ところで > the least-significant bits これ何で複数形なのかね 188 名前：デフォルトの名無しさん [2018/09/15(土) 16:14:15.89 ID:AVfR6YnT.net] 2の0乗だから実際価値が低い 上はMVBで 189 名前：デフォルトの名無しさん mailto:sage [2018/09/15(土) 17:07:56.98 ID:UR1d6CKz.net] >>183 ありがとう。 ただ一応それは知ってて、その上で、IDEの環境設定等を疑っている。 >>178 とはいえ地道に辿って、同様の再現コードを作ることに成功しそうだ。 もう少し調べて、多分今晩か明日午前中に上げる。 190 名前：デフォルトの名無しさん mailto:sage [2018/09/15(土) 17:12:32.47 ID:heijdb7v.net] >>184 「The difference occurs only in the least-significant bits of the significand.」 これは、SSE の場合の LSB と、x87 FPU の場合の FPU の2種類を頭の中に想定していると思われる。 SSE: a1 = 1.xxxxxxxxz * 10^b x87 : a2 = 1.yyyyyyyyw * 10^c つまり、LSB は、↑のように、z と w で、2つあるので、LSBs という英語になる。 191 名前：デフォルトの名無しさん mailto:sage [2018/09/15(土) 17:15:04.14 ID:heijdb7v.net] 誤：これは、SSE の場合の LSB と、x87 FPU の場合の FPU の2種類を 正：これは、SSE の場合の LSB と、x87 FPU の場合の 2種類を 192 名前：デフォルトの名無しさん mailto:sage [2018/09/15(土) 17:18:55.19 ID:heijdb7v.net] >>184 >揚げ足取りだけどLSBを「最も価値が小さい」って直訳はいかがなものかなw >普通に最下位ビットじゃないの？ 整数の場合は、「最下位ビット」というと、本当にBITの位置が一番右にあるようなイメージもある。 一方、浮動小数点数の場合は、右にあるとかより、仮数部において、一番価値の小さいビット、というニュアンスを使えたかった。 IEEEでは、それは確かに一番右にあるビットであって、マシン語レベルの表現では、BIT0ではあるのだが。 ニュアンス的に。 193 名前：デフォルトの名無しさん mailto:sage [2018/09/15(土) 17:29:56.92 ID:aC3C7hdp.net] >>187 それは俺も思ったけど、それならsignificandの方も複数じゃないとおかしいような... 194 名前：デフォルトの名無しさん mailto:sage [2018/09/15(土) 20:35:40.44 ID:UR1d6CKz.net] 同様の症状を再現出来るようになったので上げる。 完全再現は出来てないが、使い物にはなるはず。興味がある人はよろしく。 症状： 単独で起動した場合と、IDEから起動した場合で、結果が異なる。 環境： VS++2008ExpressEdition 再現方法： 1. 新規プロジェクトを作成。(CLRコンソールアプリケーション。オプション等は全てデフォのまま) 2. mainを以下ソースと差し替える。 3. Releaseビルドで実行する。(Debugビルドでは再現しなかったので注意） 結果： 0.000000, 0x1ff68ddfb62221dd (IDEからの起動(F5)) 0.000000, 0x1ff68ddfb62221de (コマンドプロンプトからの起動) 最後の2bitが異なる。(誤差は1bit） 備考： 俺が遭遇しているのとはやや異なる。(俺の場合、Debugビルドでもこれが発生する) この再現状況だと、単に 「DebugとReleaseでバイナリが異なり、 IDEから起動した場合は常にDebugバイナリを掴んでいるだけでは？」 とも取れるが、こちらで確認した限りはちゃんとReleaseバイナリを掴んでいる。 理由は、 1. Debug/Releaseの両方のバイナリがない状態で実行した場合、 　自動的に作成されるのはReleaseバイナリ。（当然だが） 　結果は****ddとなる。(ブレークポイント等で止めて確認する） 2. そのReleaseバイナリをコマンドプロンプトから起動すると、****deの結果が得られる。 195 名前：デフォルトの名無しさん mailto:sage [2018/09/15(土) 20:37:06.43 ID:UR1d6CKz.net] ソース： #include "stdafx.h" #include <math.h> using namespace System; template<typename T> static double calc_norm_and_regulate(int num, T* r, bool regulate){ // <float> for debug. double norm = 0; for (int i=0;i<num;i++) norm += (double)r[i] * (double)r[i]; norm = sqrt(norm); if (regulate) for (int i=0;i<num;i++) r[i] = (T)(r[i]/norm); return norm; } int main(array<System::String ^> ^args) { int count = 16; __int64 inputs_hex[16] = { 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x1fedb1530240aa54, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x1ff0af0d95025bc3, 0x1fc9353df6af376b, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000}; double* inputs = (double*)inputs_hex; double norm = calc_norm_and_regulate(count, inputs, false); Console::Write(String::Format("{0:F6}, 0x{1:x16}\r\n",norm, *(__int64*)&norm)); // Release build // 0.000000, 0x1ff68ddfb62221dd from IDE // 0.000000, 0x1ff68ddfb62221de from command prompt return 0; } 196 名前：デフォルトの名無しさん mailto:sage [2018/09/15(土) 20:42:48.06 ID:UR1d6CKz.net] オプション等(コマンドライン）：（全てデフォのままのはずだが一応） C/C++： 　/GL /D "WIN32" /D "NDEBUG" /D "_UNICODE" /D "UNICODE" /FD /EHa /MD /Yu"stdafx.h" /Fp"Release\test_floating_error4.pch" /Fo"Release\\" /Fd"Release\vc90.pdb" /W3 /nologo /c /Zi /clr /TP /errorReport:prompt /FU "c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll" /FU "c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll" /FU "c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.XML.dll" リンカ： /OUT:"MYPATH\test_floating_error4\Release\test_floating_error4.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"Release\test_floating_error4.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"MYPATH\test_floating_error4\Release\test_floating_error4.pdb" /LTCG /DYNAMICBASE /FIXED:No /NXCOMPAT /MACHINE:X86 /ERRORREPORT:PROMPT パスは$MYPATHと書き換えた。また、投稿の為に適宜改行を入れた。 このプロジェクト名は見れば分かるとおりtest_floating_error4。 197 名前：デフォルトの名無しさん mailto:sage [2018/09/15(土) 20:43:03.84 ID:UR1d6CKz.net] 備考2： なおこの方法で見える calc_norm_and_regulate 関数の『逆アセンブル』結果は 俺の環境での物とコールアドレス以外は一致していることを確認している。 一応、diff結果は以下。 8c8 < 0000000c cmp dword ptr ds:[00752E14h],0 --- > 0000000c cmp dword ptr ds:[007D2E14h],0 10c10 < 00000015 call 676F58B9 --- > 00000015 call 683C58B9 44c44 < 0000006a call FF0455E8 --- > 0000006a call FFD955E8 198 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 02:47:43.28 ID:wIV2HUNW.net] >>191 C++/CLR では、.Net を使っているから、起動方法が違うだけでも、 fpu control word の値や、使うCPU命令がx87 FPUなのか、SSE なのかが違ってくる可能性がある� 199 名前：ｩもしれない。 fpu control word は、main()関数に入る前の start up codeの中で 初期化される。 [] [ここ壊れてます] 200 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 03:19:36.22 ID:wIV2HUNW.net] >>192 // Release build // 0.000000, 0x1ff68ddfb62221dd from IDE // 0.000000, 0x1ff68ddfb62221de from command prompt それにしても、随分小さな値だね。ちなみに、浮動小数点表示 の場合の有効数字の桁数を上げたら、どのようになる？ 1.xxxe-yy 表示にして。 201 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 03:40:33.66 ID:wIV2HUNW.net] >>192 試しに、ソースの冒頭に #include <stdio.h> を追加してから、 Console::Write(String::Format("{0:F6}, 0x{1:x16}\r\n",norm, *(__int64*)&norm)); の部分を、 printf( "%30.30e, 0x%016X\n", norm, *(__int64*)&norm) ); としてみるとどうなる？ 202 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 03:42:01.82 ID:wIV2HUNW.net] >>197 誤： printf( "%30.30e, 0x%016X\n", norm, *(__int64*)&norm) ); 正： printf( "%30.30e, 0x%016X\n", norm, *(__int64*)&norm ); 203 名前：デフォルトの名無しさん [2018/09/16(日) 07:27:22.50 ID:SOVIz+sV.net] > 0x1ff68ddfb62221dd（Debug） > 0x1ff68ddfb62221de（Release） VS 2010 VC++ Express でも再現した 204 名前：デフォルトの名無しさん [2018/09/16(日) 07:38:10.70 ID:SOVIz+sV.net] ↓このﾙｰﾌﾟを抜けたあと、すでにReleaseﾋﾞﾙﾄﾞとDebugﾋﾞﾙﾄﾞでは 　normの値に差異が発生してることが確認できた for (int i=0;i<num;i++) norm += (double)r[i] * (double)r[i]; ↓この下に（ﾙｰﾌﾟ内に）fprintf文を入れるだけで 　ReleaseﾋﾞﾙﾄﾞとDebugﾋﾞﾙﾄﾞが同じ実行結果になることが確認できた norm += (double)r[i] * (double)r[i]; とりあえずまずこれだけは分かったから 低学歴知恵遅れが書いたｳﾝｺｺｰﾄﾞの問題箇所を限定する 205 名前：デフォルトの名無しさん [2018/09/16(日) 07:51:03.41 ID:SOVIz+sV.net] �@-1 ﾃﾞﾌｫﾙﾄ設定（Release） 【ｺｰﾄﾞ】 #include "stdafx.h" #include <stdio.h> #include <stdint.h> #include <math.h> int main(array<System::String ^> ^args) { 　　__int64 inputs_hex[16] = { 　　　　0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x1fedb1530240aa54, 　　　　0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x1ff0af0d95025bc3, 　　　　0x1fc9353df6af376b, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 　　　　0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000 　　}; 　　double* r = (double*)inputs_hex; 　　double norm = 0; 　　for (int i = 0; i < 16; i++) { 　　　　norm += (double)r[i] * (double)r[i]; //　　　　fprintf(stdout, "[1]0x%016llX:%.19lg\n", *(uint64_t*)&norm, norm); 　　} 　　fprintf(stdout, "0x%016llX:%.19lg\n", *(uint64_t*)&norm, norm); 　　return 0; } 206 名前：デフォルトの名無しさん [2018/09/16(日) 07:51:56.62 ID:SOVIz+sV.net] �@-1 ﾃﾞﾌｫﾙﾄ設定（Release） ↓このｺｰﾄﾞの逆ｱｾﾝﾌﾞﾙｺｰﾄﾞ https://ideone.com/Ryyxkl 【実行結果】 0x0007F2C44DFFF8F2:1.1053482540585106e-308 207 名前：デフォルトの名無しさん [2018/09/16(日) 07:53:20.79 ID:SOVIz+sV.net] �@-2 ﾃﾞﾌｫﾙﾄ設定（Release） #include "stdafx.h" #include <stdio.h> #include <stdint.h> #include <math.h> int main(array<System::String ^> ^args) { 　　__int64 inputs_hex[16] = { 　　　　0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x1fedb1530240aa54, 　　　　0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x1ff0af0d95025bc3, 　　　　0x1fc9353df6af376b, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 　　　　0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000 　　}; 　　double* r = (double*)inputs_hex; 　　double norm = 0; 　　for (int i = 0; i < 16; i++) { 　　　　norm += (double)r[i] * (double)r[i]; 　　　　fprintf(stdout, "[1]0x%016llX:%.19lg\n", *(uint64_t*)&norm, norm); 　　} 　　fprintf(stdout, "0x%016llX:%.19lg\n", *(uint64_t*)&norm, norm); 　　return 0; } 208 名前：デフォルトの名無しさん [2018/09/16(日) 08:02:12.99 ID:SOVIz+sV.net] �@-2 ﾃﾞﾌｫﾙﾄ設定(Release) ↓このｺｰﾄﾞの逆ｱｾﾝﾌﾞﾙｺｰﾄﾞ https://ideone.com/4j12ib 【実行結果】 ↓実行結果を書き込めないからこっちに書き込んどいた https://ideone.com/gOqtki 0x0007F2C44DFFF8F1:1.1053482540585101e-308 209 名前：デフォルトの名無しさん [2018/09/16(日) 08:05:50.92 ID:SOVIz+sV.net] �A-1 最適化無効 (/Od)（Release） ※ ｺｰﾄﾞは�@-1（>>201）と同じ ↓このｺｰﾄﾞの逆ｱｾﾝﾌﾞﾙｺｰﾄﾞ https://ideone.com/cONCAx 【実行結果】 0x0007F2C44DFFF8F1:1.1053482540585101e-308 210 名前：デフォルトの名無しさん [2018/09/16(日) 08:09:59.78 ID:SOVIz+sV.net] �A-2 最適化無効 (/Od)（Release） ※ ｺｰﾄﾞは�A-2（>>203）と同じ ↓このｺｰﾄﾞの逆ｱｾﾝﾌﾞﾙｺｰﾄﾞ https://ideone.com/kuRt3w 【実行結果】 ※ �@-2（>>204）と同じ 0x0007F2C44DFFF8F1:1.1053482540585101e-308 211 名前：デフォルトの名無しさん [2018/09/16(日) 08:20:27.67 ID:SOVIz+sV.net] �@-1、�@-2の逆ｱｾﾝﾌﾞﾙの出力結果を比較すると原型をとどめてないぐらいｸﾞﾁｮｸﾞﾁｮに違う（最適化のせいと考えられる） �A-1、�A-2の逆ｱｾﾝﾌﾞﾙの出力結果を比較すると差異はほとんどない（�Aは両方ともまったく最適化されてないから当然） �@-1と�A-1の逆ｱｾﾝﾌﾞﾙの出力結果を比較すると原型をとどめてないぐらいｸﾞﾁｮｸﾞﾁｮに違う（�@-1のｺｰﾄﾞ(>>201)ははげしくｳﾝｺ最適化されてると考えられる） �@-2と�A-2の逆ｱｾﾝﾌﾞﾙの出力結果を比較すると差異はほとんどない（�@-2のｺｰﾄﾞ(>>203)はあまり最適化されてないと考えられる） はっきりいって、これ以上見る気もしないしﾃｷﾄｰだが ｳﾝｺみたいな最適化で演算の順序が入れ替わったせいで、誤差が発生しているものと考えられる 212 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 08:28:37.25 ID:zL1WUjLu.net] >>199以降、 すまん、入れ替わりになるかもしれんが後で確認する。 まず>>195その他について回答する。 >>195 SSEは /arch:SSE または /arch:SSE2 でないと出ないことになっており、勿論設定はしていない。 また、逆アセンブル結果では x87 命令のみであるのも確認している。 ただ今回の問題は、本当にReleaseビルドのバイナリを逆アセンブルしているか怪しい事だが。 >>196 小さい値なのは偶々だ。 辿って行ってそれが1回目にヒットする入力データだっただけのこと。 >>197 .NETの書式指定はググり難いが以下。 https://docs.microsoft.com/en-us/dotnet/standard/base-types/standard-numeric-format-strings 概ねprintfと同じで、自動的にやってくれるのが増えている。 30桁欲しければ以下。 Console::Write(String::Format("{0:E6}, {0:E30}\r\n",norm)); // 出力は 1.051355E-154, 1.051355436595307800000000000000E-154 なおdoubleは16桁な。(15.9=53*log(10)2) ただ当たり前だが、書式を変えたところで計算結果は変わらないし、 精度の問題には関係ない。 213 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 08:29:03.14 ID:zL1WUjLu.net] >>195 FPU control registor については何故か安定した結果を得られていない。 インラインアセンブラは以下の通りで、 #pragma unmanaged inline void fpu_getcw(unsigned short* cw) { __asm{ fnstcw [cw]; } } #pragma managed これを norm = calc_norm_and_regulate( ... ) の直前/直後に配置して読み出し、 同様にコンソール出力すると、以下となる。 また、IDEで起動した場合は、「レジスタ」で見れる。 なお定義は以下の通り。 [9:8]に対し、 0x00 : 単精度(24bit) 0x01 : reserved 0x10 : 倍精度(53bit) 0x11 : 拡張倍精度(64bit) [11:10]に対し 0x00 : 最近値 0x01 : 切り捨て 0x10 : 切り上げ 0x11 : 0方向への切り捨て 214 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 08:29:57.53 ID:zL1WUjLu.net] >>195 直後のみに配置： 0x027F (倍精度） ＝　Debug(IDE起動）のIDE内表示、Release(IDE起動）のIDE内表示、 0x03a5 (拡張倍精度)　＝　Debug(IDE起動）、Release(IDE起動）、 0x3fdc (拡張倍精度） ＝　Debug（コマンドプロンプト）、 0xf280, 0xf290, 0xf160, 0xf010等、不安定　＝　Release（コマンドプロンプト） 直前のみに配置： 直後のみと同じ結果。（つまり『何故か』安定している） Release（コマンドプロンプト）は不安定なのも同じ。 直前と直後に配置： 直前側は当然不安定になる。 直後側は「直後のみ」の結果と同じ。(Release（コマンドプロンプト）は不安定なのも同じ) 雰囲気からすると、IDE内表示は当てにならず、 命令自体は rdtsc と同じで非同期に実行されている雰囲気だが、 rdtsc命令の注意書きにある「シリアル化命令ではない」という但し書きが無く、状況は不明。 正直、正しく読み出せているか怪しい。（あてにならない） これらから推測すると、暫定的には以下。 拡張倍精度　＝　Debug(IDE起動）、Release(IDE起動）、Debug（コマンドプロンプト）、 不明　＝　Release（コマンドプロンプト） 以上が>>195その他に対する回答。 これから>>199その他について確認する。 215 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 12:52:37.56 ID:haV9TZ8e.net] >>210 興味深い結果だ。 216 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 13:21:26.16 ID:haV9TZ8e.net] >>210 >命令自体は rdtsc と同じで非同期に実行されている雰囲気だが、 >rdtsc命令の注意書きにある「シリアル化命令ではない」という但し書きが無く、状況は不明。 >正直、正しく読み出せているか怪しい。（あてにならない） インラインアセンブラを使わずに、 _control87(), _controlfp() : Get and set the floating-point control word. unsigned int _control87( unsigned int new, unsigned int mask ); unsigned int _controlfp( unsigned int new, unsigned int mask ); を使ってみたらどうなる？ 217 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 13:31:15.50 ID:Q5j4SiHR.net] win32コンソールなら結果が同じ。 もう理由は分かったのに何が問題なんだ？こんなの何の影響もないだろう。 218 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 13:33:14.92 ID:zL1WUjLu.net] >>199 再現実験ありがとう。 しかし色々問題がある。 1. 俺は起動方法による違いについてフォーカスしているが、 　君はRelease/Debugの違いにフォーカスしている。 2. VC++2008では再現しない。(VC++2010では再現する） 3. ソース改変しすぎ。それでは意味がない。 4. >>207の結論は間違い。 まず問題なのはソースの改変だ。 ループ回数を16回と決め打ちしたことで 8*2 に展開されている。 その結果、元のソース（俺が遭遇した状況）では発生しえないことが発生している。 これでは意味がない。 そして、君の結論は間違いだ。 × > ｳﾝｺみたいな最適化で演算の順序が入れ替わったせいで、誤差が発生しているものと考えられる 逆アセンブルを追えば分かるが、演算順序は入れ替わっていない。 原因は、Debugでは fld/fmul/fadd/fstp と毎回64bitに整形されるのに対し、 Releaseでは (fld/fmul/fadd)*8 + fstp と整形が8回に1回と減り、 8回は80bit(拡張倍精度）で演算されるからだ。 (こうなったのは君が16回ループ決め打ちコードに改変したから) ただしIDE上の fpu control registor の値は 相変わらず0x027F(倍精度）となっており、 IDEのこの表示が当てにならない事は分かる。 なおVC++2008では再現しなかった。 俺の環境では、16回決め打ちコードでも 8*2 に展開されず、Debugと同じコードだからだ。 勿論結果も同じだった。 219 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 13:33:48.22 ID:zL1WUjLu.net] >>199 問題は、俺の環境で俺が提供したコード>>192だと、 同様に展開されないにも関わらず、『起動方法によって』結果が異なってしまう点だ。 俺の環境でのRelease/Debugの逆アセンブル結果のdiffは以下。 17c17 < 0000000c cmp dword ptr ds:[001C2E14h],0 --- > 0000000c cmp dword ptr ds:[00702E14h],0 19c19 < 00000015 call 68302BA9 --- > 00000015 call 683A5AB1 93c93 < 0000015a call FF6C3098 --- > 0000015a call FFCA57E8 98c98 < 0000016f push 0B5311Ch --- > 0000016f push 0D03188h 104,105c104,105 < 00000183 push 4F9D68h < 00000188 call FF6C30A4 --- > 00000183 push 2B71C0h > 00000188 call FFCA57F4 アドレスの変更だけであり、君の結果 「ループ回数を決め打ちしたことによりアンローリングされ、一部の演算がx87精度で計算される」には該当しない。 そして、この状況でも結果が異なってしまうことが問題なのだ。 君は君が勝手に新しく作り込んだ問題に対し、間違った結論でお茶を濁したにすぎない。 君が知っているFPU関連のことはこちらも知っている上で、質問している。 220 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 13:53:17.67 ID:haV9TZ8e.net] >>214 なるほど、全く別の2つの理由で、精度が変わっている可能性（というより多分、確実）があると。 それは以下の2つ： 1. Debug版とRelease版では、最適化の結果、x87 FPU命令の使われ方が変わる。 　 x87では、メモリに書き戻さずに st(0)〜st(7)レジスタに入っている途中では、 　拡張倍精度の80BITで計算されるが、書き戻すとdoubleの場合でも64BITに丸め 　られる。なるべくメモリに書き戻さずにレジスタった方が高速なので、Release版 　では、80BITで計算される「期間」が多くなる。そのため、Debug版とRelese版では 　結果が僅かに違ってくる。 2. fpu control word が違っていて、st(0)〜st(7)に入っていても、計算が 　80BITか、64BIT、32BITのどれで計算されるか異なったり、丸め方が四捨五入 　か、正負二種類の方向の切り捨てなどが変わっている。 そして、IDEから起動した場合と、コマンドラインから起動した場合で結果が違う のは、「2.」の理由によるものではないかと。そして、実際に、インラインアセンブラ で fpu control word を読み取ってみると、不安定な値が読み出されたと。 221 名前：デフォルトの名無しさん [2018/09/16(日) 13:58:15.86 ID:haV9TZ8e.net] まず、 __asm{ 　fnstcw [cw]; } ではなく、_control87() を使ってみて欲しい。 インラインアセンブラは、独立した *.asm で書くより危険な場合が あるかも知れないので。特にC関数の引数、今の場合は、「cw」を インライン・アセンブラで用いた場合、正しいコードが出ているかどうか は注意が必要。 222 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 14:05:28.41 ID:haV9TZ8e.net] >>209 よく見ると、それは、かなり複雑な事情が絡みそうなコード。 以下のようにした方が安心。なお、「cw」という短すぎ� 223 名前：驤�数名 も長年のプログラミング経験からすると、インラインアセンブラでは 怖い。また、 TTTT reg,引数名 や TTTT 引数名 は大丈夫でも、 TTTT reg,[引数名] や TTTT [引数名] は1命令では不可能な事をコンパイラに指示している事になるので ちょっと怖い。間接の間接、つまり、[[ebp+8]]みたいな事を要求 しているが、そんなオペランドが使えるアセンブリ命令はx86/x64 では存在しないので。 #pragma unmanaged inline void fpu_getcw(unsigned short *pCW) { 　__asm{ 　　mov edx,pCW 　　fnstcw [edx]; 　} } #pragma managed [] [ここ壊れてます] 224 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 14:17:40.34 ID:haV9TZ8e.net] あ、後、インライン・アセンブラで実験する場合は、関数名の inline は 「取った」方がいい。つまり、以下の方が安心： #pragma unmanaged void fpu_getcw(unsigned short *pCW) { 　__asm{ 　　mov edx,pCW 　　fnstcw [edx]; 　} } #pragma managed 225 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 15:23:18.78 ID:h8nMbN0G.net] また基本に戻るが、>>193で/MDになってるので /MTや/MTdでも発生するかしてみた方がいい 226 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 15:37:02.44 ID:Q5j4SiHR.net] .netはx87コンテキストをすべて保持しませんって分かったんだからもう十分。 win32かx64にすれば解決。そもそも問題になる仕様バグじゃない。 227 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 15:40:56.17 ID:haV9TZ8e.net] >>220 ホントだ。/MDだと、Runtime Library として DLL のものを使ってしまう。 これは、今回の現象に非常に重要な影響を与えているかも知れない。 228 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 15:42:36.82 ID:haV9TZ8e.net] >>221 いや、まだまだ興味深い。 ここで終わらせずにもっと徹底して追及すべきだ。 229 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 15:48:45.63 ID:zL1WUjLu.net] >>212 それはどうやらclrでは使えないらしい。 > These functions are ignored when you use /clr (Common Language Runtime Compilation) or /clr:pure to compile > because the common language runtime (CLR) only supports the default floating-point precision. > https://msdn.microsoft.com/en-us/library/e9b52ceh.aspx とはいえ無理矢理やってみた。警告は出るがコンパイルは通る。 結果は、どこに置いても、Debug/Releaseでも、常に 0x9001f が読み出される。 ただし、これは上記の仕様からして、当てにならない。 230 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 15:49:44.99 ID:zL1WUjLu.net] >>219 218のコードで試してみた結果、209で言った不安定さはなくなり、 全てにおいて 0x027f が安定して読み出せるようになった。 ただしその過程で気づいたが、 IDEから起動した場合はReleaseビルドであっても、「未初期化のスタック値」も0x00が読み出せるようだ。 どうやらこれが原因の可能性が出てきた。（はっきり言って俺のバグだが） コードは以下の通りだが、 unsigned short fpu_cw, fpu_cw_after; // fpu_getcw(&fpu_cw); double norm = calc_norm_and_regulate(count, inputs, false); fpu_getcw(&fpu_cw_after); Console::Write(String::Format("{0:D}, 0x{0:x4}\r\n",fpu_cw)); Console::Write(String::Format("{0:D}, 0x{0:x4}\r\n",fpu_cw_after)); 読み出しと書き出し(Console::Write)を両方ともコメントアウトするのが面倒なので、 色々試す際、読み出しだけコメントアウトし、不定を表示させて脳内で省略していたのだが、 IDEから起動した場合はReleaseビルドであっても必ず0x0000が表示される事に気づいた。 上記『初期化していない』 fpu_cw を Releaseビルドをコマンドプロンプトから実行： 不定 ReleaseビルドをIDEから実行： 常に0x0000 となる。 実行前にあらかじめスタック領域を0fillでもしているのか？ まあこれに当たっているのなら確実に俺のバグだし、これなら辻褄は合ってしまうのだが。 231 名前：デフォルトの名無しさん mailto:sage [2018/09/16(日) 15:51:01.50 ID:zL1WUjLu.net] >>219 なお、逆アセンブルでコードバイトを表示させて確かめることは出来る。 正しいコードは出ている。(ただし不安定） inline void fpu_getcw(unsigned short* cw) { 00DA1540 55 push ebp 00DA1541 8B EC mov ebp,esp __asm{ fnstcw [cw]; 00DA1543 D9 7D 08 fnstcw word ptr [cw] } } 00DA1546 5D pop ebp 00DA1547 C3 ret fnstcwは D9 /7 で 7D なら [EBP+disp8] となり、 7D 08 は [EBP+08] となる。 つまりスタックポインタ+8の領域に書き戻せ、となる。 [ebp+0]は元のebpが入っているから、(pushしているので） [ebp+4]にcallの戻り値アドレス [ebp+8]にcw（第一引数）が入っていることになる。 これは正しいコードだ。 しかし再度試したが、確かに不安定だ。何故かは分からん。 inline取ってみても不安定のまま。 > そんなオペランドが使えるアセンブリ命令はx86/x64 > では存在しないので。 正直、/7の意味が分からないのだが、説明は > /digit − 0 から7 までの数字で、命令のModR/M バイトがr/m（レジスタまたはメモリ）オペランドだけを使用することを示す。 > reg フィールドには、命令のオペコードを拡張する数字が入っている。(Intelのマニュアルより） となっているのだが、これはどういう意味だ？ ModR/Mバイトが全部使えるとすると [ebp+disp8]出来ることになる。そしてそのコードは出ている。 ただし、動作は怪しいのも事実。 ModR/Mの一部しか使えない、ということか？

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef