Linux内核中浮点数的使用 [英] Use of floating point in the Linux kernel
问题描述
我正在阅读 Robert Love 的Linux 内核开发"，我看到了以下段落:
I am reading Robert Love's "Linux Kernel Development", and I came across the following passage:
没有(容易)使用浮点
当用户空间进程使用浮点指令时，内核管理从整数到浮点模式的转换.内核在使用浮点指令时必须做的事情因架构而异，但内核通常会捕获陷阱，然后启动从整数模式到浮点模式的转换.
When a user-space process uses floating-point instructions, the kernel manages the transition from integer to floating point mode. What the kernel has to do when using floating-point instructions varies by architecture, but the kernel normally catches a trap and then initiates the transition from integer to floating point mode.
与用户空间不同，内核没有对浮点的无缝支持，因为它不能轻易地自陷.在内核中使用浮点需要手动保存和恢复浮点寄存器，以及其他可能的杂务.简短的回答是:不要这样做！除非在极少数情况下，内核中没有浮点运算.
Unlike user-space, the kernel does not have the luxury of seamless support for floating point because it cannot easily trap itself. Using a floating point inside the kernel requires manually saving and restoring the floating point registers, among other possible chores. The short answer is: Don’t do it! Except in the rare cases, no floating-point operations are in the kernel.
我从未听说过这些整数"和浮点"模式.它们究竟是什么，为什么需要它们?这种区别是否存在于主流硬件架构(例如 x86)上，还是特定于一些更奇特的环境?从进程和内核的角度来看，从整数模式到浮点模式的转变究竟意味着什么?
I've never heard of these "integer" and "floating-point" modes. What exactly are they, and why are they needed? Does this distinction exist on mainstream hardware architectures (such as x86), or is it specific to some more exotic environments? What exactly does a transition from integer to floating point mode entail, both from the point of view of the process and the kernel?
推荐答案
因为...
- 许多程序不使用浮点数或不在任何给定的时间片上使用它；和
- 保存 FPU 寄存器和其他 FPU 状态需要时间；因此
...操作系统内核可以简单地关闭 FPU. Presto，无需保存和恢复状态，因此上下文切换速度更快.(这就是 mode 的意思，它只是意味着 FPU 已启用.)
...an OS kernel may simply turn the FPU off. Presto, no state to save and restore, and therefore faster context-switching. (This is what mode meant, it just meant that the FPU was enabled.)
如果程序尝试执行 FPU op，程序将陷入内核，内核将打开 FPU，恢复可能已经存在的任何保存状态，然后返回重新执行 FPU op.
If a program attempts an FPU op, the program will trap into the kernel, the kernel will turn the FPU on, restore any saved state that may already exist, and then return to re-execute the FPU op.
在上下文切换时，它知道实际执行状态保存逻辑.(然后它可能会再次关闭 FPU.)
At context switch time, it knows to actually go through the state save logic. (And then it may turn the FPU off again.)
顺便说一句，我相信这本书对内核(而不仅仅是 Linux)避免 FPU 操作的原因的解释......并不完全准确.1
By the way, I believe the book's explanation for the reason kernels (and not just Linux) avoid FPU ops is ... not perfectly accurate.1
内核可以陷入自身，并在很多事情上这样做.(计时器、页面错误、设备中断等.)真正的原因是内核并不特别需要 FPU 操作，并且还需要在完全没有 FPU 的架构上运行.因此，它通过不执行总是有其他软件解决方案的操作，简单地避免了管理自己的 FPU 上下文所需的复杂性和运行时间.
The kernel can trap into itself and does so for many things. (Timers, page faults, device interrupts, others.) The real reason is that the kernel doesn't particularly need FPU ops and also needs to run on architectures without an FPU at all. Therefore, it simply avoids the complexity and runtime required to manage its own FPU context by not doing ops for which there are always other software solutions.
有趣的是，如果内核想要使用 FP，FPU 状态必须多久保存一次 ... 每一次系统调用、每一次中断、每一次内核线程之间的切换.即使偶尔需要内核 FP，2 在软件中完成它可能会更快.<小时>1. 也就是说，大错特错.
2. 我知道有几种情况，内核软件包含浮点算法实现.一些架构在硬件中实现传统的 FPU 操作，但将一些复杂的 IEEE FP 操作留给软件.(想想:非正规算术.) 当一些奇怪的 IEEE 极端情况发生时，它们会陷入软件，该软件包含可以陷阱的操作的迂腐正确仿真.
It's interesting to note how often the FPU state would have to be saved if the kernel wanted to use FP . . . every system call, every interrupt, every switch between kernel threads. Even if there was a need for occasional kernel FP,2 it would probably be faster to do it in software.
1. That is, dead wrong.
2. There are a few cases I know about where kernel software contains a floating point arithmetic implementation. Some architectures implement traditional FPU ops in hardware but leave some complex IEEE FP operations to software. (Think: denormal arithmetic.) When some odd IEEE corner case happens they trap to software which contains a pedantically correct emulation of the ops that can trap.
这篇关于Linux内核中浮点数的使用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
