Linuxカーネルでの浮動小数点の使用

RobertLoveの「LinuxKernelDevelopment」を読んでいて、次の文章に出くわしました。

浮動小数点の（簡単な）使用なし

ユーザースペースプロセスが浮動小数点命令を使用する場合、カーネルは整数モードから浮動小数点モードへの遷移を管理します。浮動小数点命令を使用するときにカーネルが実行する必要があることはアーキテクチャによって異なりますが、カーネルは通常、トラップをキャッチしてから、整数モードから浮動小数点モードへの移行を開始します。

ユーザースペースとは異なり、カーネルはそれ自体を簡単にトラップできないため、浮動小数点をシームレスにサポートするという贅沢はありません。カーネル内で浮動小数点を使用するには、他の可能な雑用の中でも、浮動小数点レジスタを手動で保存および復元する必要があります。簡単な答えは：それをしないでください！まれな場合を除いて、カーネルには浮動小数点演算はありません。

これらの「整数」モードと「浮動小数点」モードについては聞いたことがありません。それらは正確には何であり、なぜそれらが必要なのですか？この違いは、主流のハードウェアアーキテクチャ（x86など）に存在しますか、それともいくつかのよりエキゾチックな環境に固有ですか？プロセスとカーネルの両方の観点から、整数モードから浮動小数点モードへの移行には正確に何が必要ですか？

なぜなら...

• 多くのプログラムは浮動小数点を使用しないか、特定のタイムスライスで使用しません。そして
• FPUレジスタおよびその他のFPU状態の保存には時間がかかります。したがって、

... OSカーネルは単にFPUをオフにする場合があります。Presto、保存および復元する状態がないため、コンテキストの切り替えが高速になります。（これはモードの意味であり、FPUが有効になっていることを意味します。）

プログラムがFPU操作を試みると、プログラムはカーネルにトラップし、カーネルはFPUをオンにし、すでに存在する可能性のある保存状態を復元してから、FPU操作を再実行するために戻ります。

コンテキストスイッチ時に、実際に状態保存ロジックを通過することを認識しています。（その後、FPUが再びオフになる場合があります。）

ちなみに、LinuxだけでなくカーネルがFPU操作を回避する理由についての本の説明は...完全に正確ではないと思います。¹

カーネルはそれ自体にトラップすることができ、多くのことに対してそうします。（タイマ、ページフォルト、デバイス割り込み、他の人。）本当の理由は、カーネルは特にないということである必要があるFPUのOPSをしても、すべてのFPUなしのアーキテクチャ上で実行する必要があります。したがって、他のソフトウェアソリューションが常に存在する操作を実行しないことで、独自のFPUコンテキストを管理するために必要な複雑さとランタイムを回避するだけです。

カーネルがFPを使用したい場合、FPU状態を保存する必要がある頻度に注意するのは興味深いことです。。。すべてのシステムコール、すべての割り込み、カーネルスレッド間のすべての切り替え。たまにカーネルFPが必要だったとしても、²ソフトウェアでそれを行う方がおそらく速いでしょう。

一部のカーネル設計では、「カーネル」または「システム」タスクがタスクスイッチアウトされたときに浮動小数点レジスタが保存されません。（これは、FPレジスタが大きく、保存に時間とスペースの両方がかかるためです。）したがって、FPを使用しようとすると、値がランダムに「プーフ」になります。

さらに、一部のハードウェア浮動小数点スキームは、トラップを介して「奇妙な」状況（ゼロ除算など）を処理するためにカーネルに依存しており、必要なトラップメカニズムはカーネルタスクが現在実行しているよりも高い「レベル」にある場合があります。

これらの理由（およびその他のいくつかの理由）により、タスクで初めてFP命令を使用するときに、一部のハードウェアFPスキームがトラップされます。FPの使用が許可されている場合は、タスクで浮動小数点フラグがオンになります。そうでない場合は、銃殺隊に撃たれます。