[過去ﾛｸﾞ]
Visual Studio 2008 Part 22 (314ﾚｽ)
Visual Studio 2008 Part 22 http://mevius.5ch.net/test/read.cgi/tech/1413180800/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
202: デフォルトの名無しさん [] 2018/09/16(日) 07:53:20.79 ID:SOVIz+sV ?-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, 0x000
0000000000000, 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; } http://mevius.5ch.net/test/read.cgi/tech/141318
0800/202
203: デフォルトの名無しさん [] 2018/09/16(日) 08:02:12.99 ID:SOVIz+sV ?-2 ﾃﾞﾌｫﾙﾄ設定(Release) ↓このｺｰﾄﾞの逆ｱｾﾝﾌﾞﾙｺｰﾄﾞ https://ideone.com/4j12ib 【実行結果】 ↓実行結果を書き込めないからこっちに書き込んどいた https://ideone.com/gOqtki 0x0007F2C44DFFF8F1:1.1053482540585101e-308 http://mevius.5ch.net/test/read.cgi/tech/1413180800/203
204: デフォルトの名無しさん [] 2018/09/16(日) 08:05:50.92 ID:SOVIz+sV ?-1 最適化無効 (/Od)（Release） ※ ｺｰﾄﾞは?-1（>>200）と同じ ↓このｺｰﾄﾞの逆ｱｾﾝﾌﾞﾙｺｰﾄﾞ https://ideone.com/cONCAx 【実行結果】 0x0007F2C44DFFF8F1:1.1053482540585101e-308 http://mevius.5ch.net/test/read.cgi/tech/1413180800/204
205: デフォルトの名無しさん [] 2018/09/16(日) 08:09:59.78 ID:SOVIz+sV ?-2 最適化無効 (/Od)（Release） ※ ｺｰﾄﾞは?-2（>>202）と同じ ↓このｺｰﾄﾞの逆ｱｾﾝﾌﾞﾙｺｰﾄﾞ https://ideone.com/kuRt3w 【実行結果】 ※ ?-2（>>203）と同じ 0x0007F2C44DFFF8F1:1.1053482540585101e-308 http://mevius.5ch.net/test/read.cgi/tech/1413180800/205
206: デフォルトの名無しさん [] 2018/09/16(日) 08:20:27.67 ID:SOVIz+sV ?-1、?-2の逆ｱｾﾝﾌﾞﾙの出力結果を比較すると原型をとどめてないぐらいｸﾞﾁｮｸﾞﾁｮに違う（最適化のせいと考えられる） ?-1、?-2の逆ｱｾﾝﾌﾞﾙの出力結果を比較すると差異はほとんどない（?は両方ともまったく最適化されてないから当然） ?-1と?-1の逆ｱｾﾝﾌﾞﾙの出力結果を比較すると原型をとどめてないぐらいｸﾞﾁｮｸﾞﾁｮに違う（?-1のｺｰﾄﾞ(>>200)ははげしくｳﾝｺ最適化されてると考えられる） ?-2と?-2の逆ｱｾﾝﾌﾞﾙの出力結果を比較すると差異はほとんどない（?-2のｺｰﾄﾞ(>>202)
はあまり最適化されてないと考えられる） はっきりいって、これ以上見る気もしないしﾃｷﾄｰだが ｳﾝｺみたいな最適化で演算の順序が入れ替わったせいで、誤差が発生しているものと考えられる http://mevius.5ch.net/test/read.cgi/tech/1413180800/206
207: デフォルトの名無しさん [sage] 2018/09/16(日) 08:28:37.25 ID:zL1WUjLu >>198以降、 すまん、入れ替わりになるかもしれんが後で確認する。 まず>>194その他について回答する。 >>194 SSEは /arch:SSE または /arch:SSE2 でないと出ないことになっており、勿論設定はしていない。 また、逆アセンブル結果では x87 命令のみであるのも確認している。 ただ今回の問題は、本当にReleaseビルドのバイナリを逆アセンブルしているか怪しい事だが。 >>195 小さい値なのは偶々だ。 辿って行ってそれが1回目にヒットする入力
データだっただけのこと。 >>196 .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) ただ当たり前だが、書式を変えたところで計算結果は変わらないし、 精度の問題には関係ない。 http://
mevius.5ch.net/test/read.cgi/tech/1413180800/207
208: デフォルトの名無しさん [sage] 2018/09/16(日) 08:29:03.14 ID:zL1WUjLu >>194 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方向への切り捨て http://mevius.5ch.net/test/read.cgi/tech/1413180800/208
209: デフォルトの名無しさん [sage] 2018/09/16(日) 08:29:57.53 ID:zL1WUjLu >>194 直後のみに配置： 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（コマン
ドプロンプト） 以上が>>194その他に対する回答。 これから>>198その他について確認する。 http://mevius.5ch.net/test/read.cgi/tech/1413180800/209
210: デフォルトの名無しさん [sage] 2018/09/16(日) 12:52:37.56 ID:haV9TZ8e >>209 興味深い結果だ。 http://mevius.5ch.net/test/read.cgi/tech/1413180800/210
211: デフォルトの名無しさん [sage] 2018/09/16(日) 13:21:26.16 ID:haV9TZ8e >>209 >命令自体は 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 ); を使ってみたらどうなる？ http://mevius.5ch.net/test/read.cgi/tech/1413180800/211
212: デフォルトの名無しさん [sage] 2018/09/16(日) 13:31:15.50 ID:Q5j4SiHR win32コンソールなら結果が同じ。 もう理由は分かったのに何が問題なんだ？こんなの何の影響もないだろう。 http://mevius.5ch.net/test/read.cgi/tech/1413180800/212
213: デフォルトの名無しさん [sage] 2018/09/16(日) 13:33:14.92 ID:zL1WUjLu >>198 再現実験ありがとう。 しかし色々問題がある。 1. 俺は起動方法による違いについてフォーカスしているが、 君はRelease/Debugの違いにフォーカスしている。 2. VC++2008では再現しない。(VC++2010では再現する） 3. ソース改変しすぎ。それでは意味がない。 4. >>206の結論は間違い。 まず問題なのはソースの改変だ。 ループ回数を16回と決め打ちしたことで 8*2 に展開されている。 その結果、元のソース（俺が遭遇した状況）では発生しえないこと
が発生している。 これでは意味がない。 そして、君の結論は間違いだ。 × > ｳﾝｺみたいな最適化で演算の順序が入れ替わったせいで、誤差が発生しているものと考えられる 逆アセンブルを追えば分かるが、演算順序は入れ替わっていない。 原因は、Debugでは fld/fmul/fadd/fstp と毎回64bitに整形されるのに対し、 Releaseでは (fld/fmul/fadd)*8 + fstp と整形が8回に1回と減り、 8回は80bit(拡張倍精度）で演算されるからだ。 (こうなったのは君が16回ループ決め打ちコードに改変したから) ただしIDE上の fpu control registor の値は 相変わらず0
x027F(倍精度）となっており、 IDEのこの表示が当てにならない事は分かる。 なおVC++2008では再現しなかった。 俺の環境では、16回決め打ちコードでも 8*2 に展開されず、Debugと同じコードだからだ。 勿論結果も同じだった。 http://mevius.5ch.net/test/read.cgi/tech/1413180800/213
214: デフォルトの名無しさん [sage] 2018/09/16(日) 13:33:48.22 ID:zL1WUjLu >>198 問題は、俺の環境で俺が提供したコード>>191だと、 同様に展開されないにも関わらず、『起動方法によって』結果が異なってしまう点だ。 俺の環境での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 F
F6C3098 --- > 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関連のことはこちらも知っている上で、質問している。 http://mevius.5ch.net/test/read.cgi/tech/1413180800/214
215: デフォルトの名無しさん [sage] 2018/09/16(日) 13:53:17.67 ID:haV9TZ8e >>213 なるほど、全く別の2つの理由で、精度が変わっている可能性（というより多分、確実）があると。 それは以下の2つ： 1. Debug版とRelease版では、最適化の結果、x87 FPU命令の使われ方が変わる。 x87では、メモリに書き戻さずに st(0)〜st(7)レジスタに入っている途中では、 拡張倍精度の80BITで計算されるが、書き戻すとdoubleの場合でも64BITに丸め られる。なるべくメモリに書き戻さずにレジスタった方が高速なので、Release版 では、80B
ITで計算される「期間」が多くなる。そのため、Debug版とRelese版では 結果が僅かに違ってくる。 2. fpu control word が違っていて、st(0)〜st(7)に入っていても、計算が 80BITか、64BIT、32BITのどれで計算されるか異なったり、丸め方が四捨五入 か、正負二種類の方向の切り捨てなどが変わっている。 そして、IDEから起動した場合と、コマンドラインから起動した場合で結果が違う のは、「2.」の理由によるものではないかと。そして、実際に、インラインアセンブラ で fpu control word を読み取ってみると、不安定な値が読み出され
たと。 http://mevius.5ch.net/test/read.cgi/tech/1413180800/215
216: デフォルトの名無しさん [] 2018/09/16(日) 13:58:15.86 ID:haV9TZ8e まず、 __asm{ fnstcw [cw]; } ではなく、_control87() を使ってみて欲しい。 インラインアセンブラは、独立した *.asm で書くより危険な場合が あるかも知れないので。特にC関数の引数、今の場合は、「cw」を インライン・アセンブラで用いた場合、正しいコードが出ているかどうか は注意が必要。 http://mevius.5ch.net/test/read.cgi/tech/1413180800/216
217: デフォルトの名無しさん [sage] 2018/09/16(日) 14:05:28.41 ID:haV9TZ8e >>208 よく見ると、それは、かなり複雑な事情が絡みそうなコード。 以下のようにした方が安心。なお、「cw」という短すぎる引数名 も長年のプログラミング経験からすると、インラインアセンブラでは 怖い。また、 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 http://mevius.5ch.net/test/read.cgi/tech/1413180800/217
218: デフォルトの名無しさん [sage] 2018/09/16(日) 14:17:40.34 ID:haV9TZ8e あ、後、インライン・アセンブラで実験する場合は、関数名の inline は 「取った」方がいい。つまり、以下の方が安心： #pragma unmanaged void fpu_getcw(unsigned short *pCW) { __asm{ mov edx,pCW fnstcw [edx]; } } #pragma managed http://mevius.5ch.net/test/read.cgi/tech/1413180800/218
219: デフォルトの名無しさん [sage] 2018/09/16(日) 15:23:18.78 ID:h8nMbN0G また基本に戻るが、>>192で/MDになってるので /MTや/MTdでも発生するかしてみた方がいい http://mevius.5ch.net/test/read.cgi/tech/1413180800/219
220: デフォルトの名無しさん [sage] 2018/09/16(日) 15:37:02.44 ID:Q5j4SiHR .netはx87コンテキストをすべて保持しませんって分かったんだからもう十分。 win32かx64にすれば解決。そもそも問題になる仕様バグじゃない。 http://mevius.5ch.net/test/read.cgi/tech/1413180800/220
221: デフォルトの名無しさん [sage] 2018/09/16(日) 15:40:56.17 ID:haV9TZ8e >>219 ホントだ。/MDだと、Runtime Library として DLL のものを使ってしまう。 これは、今回の現象に非常に重要な影響を与えているかも知れない。 http://mevius.5ch.net/test/read.cgi/tech/1413180800/221
222: デフォルトの名無しさん [sage] 2018/09/16(日) 15:42:36.82 ID:haV9TZ8e >>220 いや、まだまだ興味深い。 ここで終わらせずにもっと徹底して追及すべきだ。 http://mevius.5ch.net/test/read.cgi/tech/1413180800/222
223: デフォルトの名無しさん [sage] 2018/09/16(日) 15:48:45.63 ID:zL1WUjLu >>211 それはどうやら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
が読み出される。 ただし、これは上記の仕様からして、当てにならない。 http://mevius.5ch.net/test/read.cgi/tech/1413180800/223
224: デフォルトの名無しさん [sage] 2018/09/16(日) 15:49:44.99 ID:zL1WUjLu >>218 218のコードで試してみた結果、209で言った不安定さはなくなり、 全てにおいて 0x027f が安定して読み出せるようになった。 ただしその過程で気づいたが、 IDEから起動した場合はReleaseビルドであっても、「未初期化のスタック値」も0x00が読み出せるようだ。 どうやらこれが原因の可能性が出てきた。（はっきり言って俺のバグだが） コードは以下の通りだが、 unsigned short fpu_cw, fpu_cw_after; // fpu_getcw(&fpu_cw); double norm = calc_nor
m_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でもしているのか？ まあこれに当たっているのなら確実に俺のバグだし、これなら辻褄は合ってしまうのだが。 http://mevius.5ch.net/test/read.cgi/tech/1413180800/224
225: デフォルトの名無しさん [sage] 2018/09/16(日) 15:51:01.50 ID:zL1WUjLu >>218 なお、逆アセンブルでコードバイトを表示させて確かめることは出来る。 正しいコードは出ている。(ただし不安定） 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の一部しか使えない、ということか？ http://mevius.5ch.net/test/read.cgi/tech/1413180800/225
226: デフォルトの名無しさん [sage] 2018/09/16(日) 15:51:25.16 ID:zL1WUjLu >>218 218のコードだと、 00381002 EC in al,dx __asm{ mov edx,pCW 00381003 8B 55 08 mov edx,dword ptr [pCW] fnstcw [edx]; 00381006 D9 3A fnstcw word ptr [edx] } } 00381008 5D pop ebp 00381009 C3 ret D9 3A ならまんま fnstcw [edx] だ。 理由は分からんがこちらだと安定しているので、結果としてはこのやり方が正しい。 http://mevius.5ch.net/test/re
ad.cgi/tech/1413180800/226
227: デフォルトの名無しさん [sage] 2018/09/16(日) 16:02:47.64 ID:haV9TZ8e >>225 をを。やはり、ある意味ではVCが間違ったアセンブリコードを出していたよ。 それだと、 fnstcw [EBP+08] という意味になってしまって、 fnstcw pCW の意味になっている。つまり： pCW = control_word; あなたが、やりたいのは、 *pCW = control_word; だったのだから、アセンブリ・コードが間違ってる。 あなたが指示したのは、 fnstcw [pCW] だった。実際に生成されたコードは、 fnstcw pCW だった。 VC のインラインアセンブラは、エラーも出さずに間違
ったコードを 出すことが証明された。 これと、精度が不安定な問題とは全く別ではあるけれど。 http://mevius.5ch.net/test/read.cgi/tech/1413180800/227
228: デフォルトの名無しさん [sage] 2018/09/16(日) 16:06:05.39 ID:zL1WUjLu すまん、間違いの修正 >>224 × > どうやらこれが原因の可能性が出てきた。（はっきり言って俺のバグだが） × > まあこれに当たっているのなら確実に俺のバグだし、これなら辻褄は合ってしまうのだが。 今回は俺はあくまで俺の本番コードのデバッグを念頭に置いていて、この発言だった。 ただし>>191の再現コードで『不定スタック領域』を掴んでいるわけもなく、 一応IDE起動とコマンドプロンプト起動での挙動の違いを再現出来ているわけだから、
これだけが問題ではないのも事実だ。 俺にとっては一つ新しい知見として、 ・IDEから起動した場合、スタックが初期化されるっぽい ということが分かった。とはいえOSは0fillしてから各プロセスにメモリを与えるので、実際は、 ・コマンドプロンプト起動ならmain前に設定した続きでそのまま実行、 ・IDE起動ならmain前に色々やって0fillして実行、 或いはmain前に色々やることが多く、スタックが進み、(例えばデバッガをアタッチする為) 結果的にOSが初期化済みの領域から始動 となって違いが発生するというところか。 http://mevius.5ch.net/tes
t/read.cgi/tech/1413180800/228
229: デフォルトの名無しさん [sage] 2018/09/16(日) 16:11:52.18 ID:haV9TZ8e >>225 >正直、/7の意味が分からないのだが、 ModRM とは、 mod reg r/m 76 543 210 のようなオペランドを指しているのだけど、/7 は、regの部分を2進数の111、 10進数の「7」にするという意味。このタイプのマシン語は、 mod ttt r/m とも書かれる。tttの部分は、命令の主幹部分(ニモニック部分)によって変わる。 普通は、レジスタ番号を入れるところに、命令の種類を表す3BITの値を入れる 仕様になっている。 あなたがインラインアセンブラでVCに出させたか
ったコードは、意味的には、 fnstcw [[EBP+08]] なのだが、[ ] を二重にしたようなそんなx86/x64命令は存在しないので VC がエラーも出さずに勝手に一重の fnstcw [EBP+08] にしてしまった、という事。本当は、 mov edx,[EBP+08] fnstcw [edx] というコードにしなくてはならなかったのに、VCがある意味では間違った。 これが、単独の *.asm ではなく、VC の asm {・・・} が危険な理由。 VC の asm は特に危険。 http://mevius.5ch.net/test/read.cgi/tech/1413180800/229
230: デフォルトの名無しさん [sage] 2018/09/16(日) 16:17:02.07 ID:haV9TZ8e >>228 >ただし>>191の再現コードで『不定スタック領域』を掴んでいるわけもなく、 >一応IDE起動とコマンドプロンプト起動での挙動の違いを再現出来ているわけだから、 >これだけが問題ではないのも事実だ。 そうだよ。精度が変わるのはあなたの間違いではない。スタック領域が0クリア されようがれまいが、あなたのコード自体には特に不安定さはない。 非初期化領域を参照しているコードは見当たらないし。 http://mevius.5ch.net/test/read.cgi/
tech/1413180800/230
231: デフォルトの名無しさん [sage] 2018/09/16(日) 16:20:22.27 ID:haV9TZ8e 逆アセンブラ結果を見てないで言うけど、もし、sqrt() が call文で関数呼び出し されているんだったら、そこで精度の違いが出てるかもしれない。 http://mevius.5ch.net/test/read.cgi/tech/1413180800/231
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 83 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.022s