[過去ﾛｸﾞ] Visual Studio 2008 Part 22 (314ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
222: 2018/09/16(日)15:42 ID:haV9TZ8e(8/12) AAS
>>220
いや、まだまだ興味深い。
ここで終わらせずにもっと徹底して追及すべきだ。
223: 2018/09/16(日)15:48 ID:zL1WUjLu(6/27) AAS
>>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.
> 外部ﾘﾝｸ[aspx]:msdn.microsoft.com
とはいえ無理矢理やってみた。警告は出るがコンパイルは通る。
結果は、どこに置いても、Debug/Releaseでも、常に 0x9001f が読み出される。
ただし、これは上記の仕様からして、当てにならない。
224(1): 2018/09/16(日)15:49 ID:zL1WUjLu(7/27) AAS
>>218
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);
省12
225(2): 2018/09/16(日)15:51 ID:zL1WUjLu(8/27) AAS
>>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]
}
省20
226: 2018/09/16(日)15:51 ID:zL1WUjLu(9/27) AAS
>>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]
}
}
省4
227(1): 2018/09/16(日)16:02 ID:haV9TZ8e(9/12) AAS
>>225
をを。やはり、ある意味ではVCが間違ったアセンブリコードを出していたよ。
それだと、
fnstcw [EBP+08]
という意味になってしまって、
fnstcw pCW
の意味になっている。つまり：
pCW = control_word;
あなたが、やりたいのは、
*pCW = control_word;
省9
228(2): 2018/09/16(日)16:06 ID:zL1WUjLu(10/27) AAS
すまん、間違いの修正
>>224
× > どうやらこれが原因の可能性が出てきた。（はっきり言って俺のバグだが）
× > まあこれに当たっているのなら確実に俺のバグだし、これなら辻褄は合ってしまうのだが。
今回は俺はあくまで俺の本番コードのデバッグを念頭に置いていて、この発言だった。
ただし>>191の再現コードで『不定スタック領域』を掴んでいるわけもなく、
一応IDE起動とコマンドプロンプト起動での挙動の違いを再現出来ているわけだから、
これだけが問題ではないのも事実だ。
俺にとっては一つ新しい知見として、
・IDEから起動した場合、スタックが初期化されるっぽい
省6
229(1): 2018/09/16(日)16:11 ID:haV9TZ8e(10/12) AAS
>>225
>正直、/7の意味が分からないのだが、
ModRM とは、
mod reg r/m
76 543 210
のようなオペランドを指しているのだけど、/7 は、regの部分を2進数の111、
10進数の「7」にするという意味。このタイプのマシン語は、
mod ttt r/m
とも書かれる。tttの部分は、命令の主幹部分(ニモニック部分)によって変わる。
普通は、レジスタ番号を入れるところに、命令の種類を表す3BITの値を入れる
省12
230(1): 2018/09/16(日)16:17 ID:haV9TZ8e(11/12) AAS
>>228
>ただし>>191の再現コードで『不定スタック領域』を掴んでいるわけもなく、
>一応IDE起動とコマンドプロンプト起動での挙動の違いを再現出来ているわけだから、
>これだけが問題ではないのも事実だ。
そうだよ。精度が変わるのはあなたの間違いではない。スタック領域が0クリア
されようがれまいが、あなたのコード自体には特に不安定さはない。
非初期化領域を参照しているコードは見当たらないし。
231(3): 2018/09/16(日)16:20 ID:haV9TZ8e(12/12) AAS
逆アセンブラ結果を見てないで言うけど、もし、sqrt() が call文で関数呼び出し
されているんだったら、そこで精度の違いが出てるかもしれない。
232(1): 2018/09/16(日)16:23 ID:zL1WUjLu(11/27) AAS
>>227
なるほど、了解した。
つまり、>>209は全面的に間違いで、正しくは、
・fpu control register は 0x027F で、IDEからも正しく読めている
だな。
俺がやるべきだったのは fnstcw [[cw]] なのだと思うが、これはSyntaxErrorだ。
そして、こんな命令はないから、
[]内に変数を書かず、レジスタ名にしろ、ということだったのだな。
全くもって了解だ。
VCの問題ではなくて、
省4
233(1): 2018/09/16(日)16:35 ID:LrdaMWHl(1/5) AAS
>>232
>俺がやるべきだったのは fnstcw [[cw]] なのだと思うが、これはSyntaxErrorだ。
ちょっと違う。あなたはやるべきことをちゃんと正しく、
fnstcw [cw]
と書いた。しかし、cw=[ebp+8]なので、これは、
fnstcw [[ebp+8]]
という「意味」になる。でも、x86/x64のマシン語にはこんな[ ]を二重にした
オペランドは存在しないので、VCが無断で勝手に[ ]を一重にして、
fnstcw [ebp+8]
に改変してしまった。
省4
234(1): 2018/09/16(日)16:36 ID:zL1WUjLu(12/27) AAS
>>229-230
了解だ。ありがとう。
>>231
その部分の逆アセンブラは以下の通り。
普通にcallされている。(行数オーバーなので切るが)
ただし、
> そこで精度の違いが出てるかもしれない
との繋がりがよくからない。
sqrt()でcallされると、スタックが改変される。おそらくデータ依存か？
なら未初期化のスタックを掴みに行っているコードが有ればバグる。
省2
235(4): 2018/09/16(日)16:37 ID:zL1WUjLu(13/27) AAS
>>231
逆アセンブラ
for (int i=0;i<num;i++) norm += (double)r[i] * (double)r[i];
00000033 33 D2 xor edx,edx
00000035 89 55 E8 mov dword ptr [ebp-18h],edx
00000038 90 nop
00000039 EB 03 jmp 0000003E
0000003b FF 45 E8 inc dword ptr [ebp-18h]
0000003e 8B 45 E8 mov eax,dword ptr [ebp-18h]
00000041 3B 45 FC cmp eax,dword ptr [ebp-4]
省19
236(1): 2018/09/16(日)16:37 ID:zL1WUjLu(14/27) AAS
>>231
逆アセンブラ（続き）
if (regulate) for (int i=0;i<num;i++) r[i] = (T)(r[i]/norm);
00000078 0F B6 45 08 movzx eax,byte ptr [ebp+8]
0000007c 85 C0 test eax,eax
0000007e 74 25 je 000000A5
00000080 33 D2 xor edx,edx
00000082 89 55 EC mov dword ptr [ebp-14h],edx
00000085 90 nop
00000086 EB 03 jmp 0000008B
省14
237(2): 2018/09/16(日)16:40 ID:LrdaMWHl(2/5) AAS
>>234
よく見ると、最小(?)の実験コードでは sqrt() が使われていなかった。
スマン。
238: 2018/09/16(日)16:42 ID:zL1WUjLu(15/27) AAS
>>233
ああ、なるほど、了解。
239(1): 2018/09/16(日)16:49 ID:zL1WUjLu(16/27) AAS
>>237
いや、俺が提供した>>191のソースなら使われてるぞ。
>>200のソースでは使われてないが。
ただまあ、彼(200)がsqrtを落としたのも分からなくはない。
誤差が生じる＝通常は桁落ちだから、この場合は当然積和部分が怪しい。
あらかじめ彼はそうなると分かっていてそれを落とし、予定調和的な結論にたどり着いてしまった。
それが彼の間違いだった、ということ。
俺は出来るだけ元のソースのままで追跡しようとしている。
元のソースの該当ケースと離れてしまっては意味がないから。
そして元ソースではsqrtを使っている。
240(8): 2018/09/16(日)16:53 ID:/oSJzlqn(1/5) AAS
たぶん2008の最適化ミスだと思う。
static double norm = 0;// ←"static"を追加する
にするとか、最適化オプションをいじると
Release/コマンドプロンプトからの起動でも
0x1ff68ddfb62221ddになる
241: 2018/09/16(日)16:54 ID:LrdaMWHl(3/5) AAS
>>237
ああ。また訂正。
sqrt()が使われていないのは、>>200 >>201 >>202 >>203 の場合で、
それは、ループ内にfprintf()を入れた場合と入れない場合とで、
x87 fpuレジスタのst(0)〜st(7)を使う「期間」が変わるために 80BITから
64BITへの書き戻し丸めの問題のために精度が変わっているだけだった。
一方、あなたが指摘した >>191 では、ちゃんと sqrt() 関数が使われていて、
それだと、IDEからの起動とコマンド・プロンプトからの起動とで、精度が変
わってくると。そして、その場合の逆アセンブル結果は >>235 のように
sqrt() 関数がその場で x87 fpu の fsqrt 命令を使わずに、call 文によって
省3
242(1): 2018/09/16(日)16:56 ID:LrdaMWHl(4/5) AAS
>>239
>いや、俺が提供した>>191のソースなら使われてるぞ。
> >>200のソースでは使われてないが。
了解。
問題を切り分けるため、sqrt() を使わなかった場合の Release版での、
IDE起動とコマンドｒライン起動の精度の違いを実験してみて欲しい。
243(1): 2018/09/16(日)17:02 ID:LrdaMWHl(5/5) AAS
ちょっとしばらく、ここを離れる。
244: 2018/09/16(日)17:22 ID:zL1WUjLu(17/27) AAS
>>240
現象確認した。こちらでも再現した。
逆アセンブルは、以下。(肝心のループ部分は次レス内）
正直、fld/fmul/fadd/fstpのループ部分は変わらず、
normのアドレスが [ebp-10h]（つまりローカル）から
ds:[00A4AD40h]（つまりグローバル）に変わっただけであり、
これで結果が変わるのはかなり奇妙な気もするが、何か見落としがあるのかも。
>>240逆アセンブル(static付加版）
template<typename T> static double calc_norm_and_regulate(int num, T* r, bool regulate){ // <float> for debug.
static double norm = 0;
省19
245: 2018/09/16(日)17:22 ID:zL1WUjLu(18/27) AAS
>>240逆アセンブル（続き）(static付加版）
00000031 FF 45 F0 inc dword ptr [ebp-10h]
00000034 8B 45 F0 mov eax,dword ptr [ebp-10h]
00000037 3B 45 FC cmp eax,dword ptr [ebp-4]
0000003a 7D 21 jge 0000005D
0000003c 8B 45 F8 mov eax,dword ptr [ebp-8]
0000003f 8B 55 F0 mov edx,dword ptr [ebp-10h]
00000042 DD 04 D0 fld qword ptr [eax+edx*8]
00000045 8B 45 F8 mov eax,dword ptr [ebp-8]
00000048 8B 55 F0 mov edx,dword ptr [ebp-10h]
省13
246: 2018/09/16(日)17:22 ID:zL1WUjLu(19/27) AAS
>>240逆アセンブル（続き）(static付加版）
if (regulate) for (int i=0;i<num;i++) r[i] = (T)(r[i]/norm);
0000007a 0F B6 45 08 movzx eax,byte ptr [ebp+8]
0000007e 85 C0 test eax,eax
00000080 74 28 je 000000AA
00000082 33 D2 xor edx,edx
00000084 89 55 F4 mov dword ptr [ebp-0Ch],edx
00000087 90 nop
00000088 EB 03 jmp 0000008D
0000008a FF 45 F4 inc dword ptr [ebp-0Ch]
省18
247(1): 2018/09/16(日)17:35 ID:zL1WUjLu(20/27) AAS
>>242
まだ異なった出力が得られた。
この意味では200がsqrtを外した判断は正しかった。
(彼はそこからさらにループ回数を固定してしまったのが間違いだった)
191ソースを以下に変更した。(sqrtをコメントアウト）
ついでに Console::Write(String::Format("{0:E6}, {0:E30}\r\n",norm)); の出力も付けておく。
ソース：
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];
省13
248: 2018/09/16(日)18:30 ID:HF0YmRsW(1) AAS
>>212
ほんそれ
249: 2018/09/16(日)20:54 ID:zL1WUjLu(21/27) AAS
>>240
さて再見したが、やはりstaticだけで直る理由は分からない。
なお、最適化ミスの場合は、逆アセンブラを読めば分かる。
今のところそれではない。
一応、>>191ソースのtemplate部の逆アセンブルを上げておく。（ただし重複するので頭のみ）
頭はこれ。続きが>>235,236。
template<typename T> static double calc_norm_and_regulate(int num, T* r, bool regulate){ // <float> for debug.
double norm = 0;
00000000 55 push ebp
00000001 8B EC mov ebp,esp
省16
250: 2018/09/16(日)21:25 ID:zL1WUjLu(22/27) AAS
>>219
>>221
/MTと/clrは同時に指定出来ないらしい。(error D8016)
/MTdも同じく無理。
もう一つ /MDd ってのがあるから試してみた。
/MDdの結果：
Releaseビルドでコマンドプロンプト起動の時のみ ****de、
ReleaseビルドでIDEからの起動だと ***dd。（Debugビルドは起動方法を問わずこっち）
(/MDと全く挙動は同じ)
これで有効な指摘については全て回答してるかな？
省8
251(2): 240 2018/09/16(日)21:43 ID:/oSJzlqn(2/5) AAS
.netの場合、デバッガ配下では(デバッグのため)違うコードを実行しているような気がする。
デバッガの逆アセンブル表示とかasm出力はあまり当てにならないような気もする。
ループ部分だけど、レジスタのみで処理するか、メモリを使用するかで精度が変わるのかも。
そもそも、どっちが正しいのかよくわからんけど...
ループ部分の関数を#pragma unmanagedすると結果が変わるでそれが正しいのかも。
上下前次1-新書関写板覧索設栞歴
あと 63 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.032s