問題タブ [fpu]

これでFPUのCTRLレジスタをリセットできます：

http://support.microsoft.com/kb/326219

しかし、現在のレジスタを保存して後で復元するにはどうすればよいでしょうか?

それは.netコードからのものです..

私がやっていることは、.net dll を COM モジュールとして呼び出す Delphi からです。Delphi でレジスタをチェックCtrlすると 1 つの値が得られ、.net コードで controlfp をチェックすると別の値が得られます。私が必要としているのは、本質的にこれを行うことです：

したがって、.net コードでの浮動小数点計算はクラッシュしませんが、Ctrl戻るときにレジスタを復元したいと考えています。

多分私はしませんか？たぶん、Delphi は必要に応じてそれらをリセットしていますか? 私はこの問題についてここでブログを書きました。

小さな単純な浮動小数点演算から時折奇妙な結果が得られるソフトウェア プロジェクトがあります。私が見逃しているものがあると思います。次の問題をデバッグする方法についてのヒントが欲しいです。

(使用されるコンパイラは、Microsoft C コンパイラのバージョン 12 である MS VC 6.0 です)

最初の異常:

何らかの理由で、タイマーの評価が失敗し、時間指定されたコードが実行されませんでした。デバッガーでは、トリガー条件が実際に真であることを確認するのに問題はありませんでしたが、FPU は肯定的な結果を見つけることを拒否しました。次のコード セグメントは、同じ操作を実行しましたが、問題はありませんでした。この問題は、失敗する可能性のある偽の評価を挿入することで回避されました。

FPU の状態は、実行された以前の操作によって何らかの形で汚染されていると思いますが、役立つコンパイラ フラグがいくつかあるのでしょうか?

2番目の異常:

デバッガーは式を約 0.05 と評価しますが、結果は #IND です。#IND 値は、fld 命令を使用して 2.0F 値が FPU にロードされると、FPU スタックに表示されます。前の命令は、fild 命令を使用して、整数値 2000 を double float としてロードします。FPU スタックに #IND 値が含まれると、すべてが失われますが、デバッガーは数式を問題なく評価します。後で、これらの操作は期待される結果を返します。

また、関数呼び出しの直後に FPU の問題が再び発生します。各新しい関数の後に FPU 状態をクリアする浮動小数点演算を挿入する必要がありますか? 何らかの方法で FPU に影響を与える可能性のあるコンパイラ フラグはありますか?

この時点で、すべてのヒントとコツに感謝します。

編集:トップ関数でアセンブリ関数EMMSを最初に呼び出すことで、問題を回避できました。そうすれば、私のコードが呼び出された環境で作成された、または作成されなかった可能性のある MMX 関連のガベージが FPU からクリアされます。FPU の状態は当然のことではないようです。

//フランク

Windowsでfpu例外を処理したいのですが、次のようなものです:

しかし、窓に。MSDN を読んでみましたが、ドキュメントがまったくわかりません。x86 と amd64 の両方のアーキテクチャで、Visual Studio コンパイラでこれを行いたいと考えています。

私は C++ で例外を翻訳することに興味はありません。実際には、上記の例のように、計算後の FPU の状態を知ることだけで、FPU 例外にも興味がありません。

== 編集 ==

わかりました、実際にはもっと簡単に見えます: _clearfp を使用するだけで十分です:

例外、SEH、およびその他の移植性のないものを処理するよりもはるかに優れています:)

これはおそらく x86 FPU の専門家に対する質問です。

[最小、最大] の範囲でランダムな浮動小数点値を生成する関数を作成しようとしています。問題は、私の生成アルゴリズム (興味があるなら、浮動小数点 Mersenne Twister) が [1,2) の範囲の値しか返さないことです。つまり、包括的な上限が必要ですが、「ソース」で生成された値は排他的上限から。ここでの問題は、基になるジェネレーターが 8 バイトの double を返すことですが、必要なのは 4 バイトの float だけであり、デフォルトの FPU 丸めモードである Nearest を使用しています。

私が知りたいのは、この場合の切り捨て自体が、FPU 内部の 80 ビット値が十分に近い場合に戻り値が最大値を含む結果になるかどうか、または最大値に乗算する前に最大値の仮数をインクリメントする必要があるかどうかです。 [1,2) の中間ランダム、または FPU モードを変更する必要があるかどうか。もちろん、その他のアイデアも。

現在使用しているコードは次のとおりです。1.0f が 0x3f800000 に解決されることを確認しました。

違いがある場合、これは Win32 MSVC++ と Linux gcc の両方で動作する必要があります。また、SSE 最適化のいずれかのバージョンを使用すると、これに対する答えが変わりますか?

編集:答えはイエスです。この場合、double から float への切り捨ては、結果に max を含めるのに十分です。詳細については、Crashworks の回答を参照してください。

gdbを使用して、標準のC数学ライブラリ（-lm -march = pentium3 -mfpmath = 387）に標準のC sin（）関数を実装するアセンブラコードをステップ実行しました。そこにはたくさんのスタブがあり、なぜそれらがfsinアセンブラ命令を単純にインライン化していないのかわかりません。同じことが他の数学関数でも起こります。なぜ彼らは対応するFPU命令を呼び出さないのですか？

x87 の方が内部精度が高いことはわかっています。これは、おそらく x87 と SSE 操作の最大の違いです。しかし、x87 を使用する利点は他にあるのでしょうか? 私はどのプロジェクトでも自動的に入力する習慣があり-mfpmath=sse、x87 FPU が提供する他の機能が欠けているのではないかと考えています。

.net のプロセッサのハードウェアによってどのような数学メソッドが実装されているか知っている人はいますか? たとえば、atan を多用するアルゴリズムがあります。このためのルックアップ テーブルを簡単に作成できますが、math.net が fpu やその他のハードウェア拡張機能を使用してこれを実装する場合、その価値はありません。

I need to change the FPU control word from its default setting in a multithreaded application. Is this setting per-thread or per-process? Does it have different scopes under Mac OS X and Windows?

x87 FPU 制御ワード、具体的には精度制御フィールドのデフォルト設定を決定するものは何ですか? コンパイラはターゲット プロセッサに基づいて設定しますか? それを変更するコンパイラオプションはありますか?

Intel Core Duo プロセッサで Microsoft Visual C++ 2008 Express Edition を使用する場合、精度制御フィールドのデフォルト設定は「01b」で、倍精度 (53 ビット) を意味します。私は疑問に思っています-なぜデフォルトが「11」bまたは拡張（64ビット）精度ではないのですか?

(_controlfp を使用して変更できることはわかっています。)

ワンライナーC関数がありreturn value * pow(1.+rate, -delay);ます。これは、将来価値を現在価値に割り引くものです。分解の興味深い部分は

この関数をシングルステップで実行している間、gdbは次のように述べています（レートは0.02、遅延は2です。スタックで確認できます）。

そして後fld1：

この後、すべてが地獄に行きます。物事はひどく過大評価または過小評価されているので、私のfreeciv AIの試みに他のバグがなかったとしても、それはすべての間違った戦略を選択するでしょう。軍全体を北極圏に送るようなものです。（ため息をつく、もし私がそこまで到達していれば。）

fld1何か明らかなものが欠けているか、何かに目がくらんでいるに違いありません。それが失敗する可能性があるとは信じられないからです。ほんの一握りがこの関数を通過した後にのみ失敗するはずです。以前のパスでは、FPUは1をST（0）に正しくロードします。0x080555c6のバイトは確実にエンコードされfld1ます-実行中のプロセスでx/...でチェックされます。

何が得られますか？