IRQ 编号冲突
从： http://software.intel.com/en-us /articles/introduction-to-pc-architecture/
异常编号 10h 对应于“浮点错误”，但软件中断 10h 也对应于“视频支持”BIOS 中断（均在实模式下）。
我缺少什么？
From:
http://software.intel.com/en-us/articles/introduction-to-pc-architecture/
Exception number 10h corresponds to a "Floating Point Error" but software interrupt 10h also corresponds to "Video support" BIOS interrupts (both in real mode).
What am I missing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
好的，请查看这里，Watcom 的网站。我认为这是重要的部分，尽管关于 8087 的旧注释也很有趣。
OK, have a look here, on Watcom's site. This is the important part I think, although the old note about the 8087 is interesting too.
简单的答案是，
int 10h浮点错误是保护模式异常，而int 10hBIOS 视频服务是实模式中断。令人高兴的答案是，清除
CR0寄存器中的NE位将防止异常发生，并允许在 PM32 中将其用作简单中断（例如在32 位保护模式 BIOS 扩展器）。The simple answer is that the
int 10hFloating Point Error is a protected mode exception, while theint 10hBIOS Video Services is a real mode interrupt.The happy answer is that clearing the
NEbit in theCR0register will prevent the exception from occurring and allow it's use in PM32 as a simple interrupt (for example in a 32 bit protected mode BIOS extender).浮点故障是由错误条件生成的 CPU 中断。这与 IRQ 不同。
PIC（可编程中断控制器）可用于修改哪些 IRQ 将映射到哪个 CPU 中断。如果您以正确的顺序发送 PIC 的 IO 端口（使用 OUT 指令），则可以以不与来自浮点异常的 CPU 中断冲突的方式映射 IRQ。
另请参阅本文档。
编辑：但是现在我再次阅读了您的问题...我们不是在这里讨论 IRQ。 BIOS Int 10h 是一个完全不同的野兽......它是您的 BIOS 为视频例程实现的一些代码。如果您正在编写操作系统并想知道是否应该处理浮点错误，您可能应该忘记这个特定的 BIOS 中断的存在。 :-)
编辑 2：想想看，旧的 DOS 程序解决此问题的方法可能是备份 IVT 条目，将自己的异常处理程序放在其位置，执行一些浮点操作，并在以下情况下恢复旧的 IVT 条目： FPU 已经完成了。
The floating point fault is a CPU interrupt, generated by an error condition. This is different from an IRQ.
The PIC (Programmable Interrupt Controller) can be used to modify which IRQs will get mapped to which CPU interrupt. If you send the PIC's IO port the proper sequence (using the
OUTinstruction), you can map the IRQ in such a way that it doesn't conflict with the CPU interrupt from a floating point exception.See also this document.
EDIT: But now that I read your question again... We're not talking about IRQs here. BIOS Int 10h is a different beast altogether... It's some code that your BIOS has implemented for video routines. If you're writing an OS and wondering if you should handle floating point faults, you should probably forget this particular BIOS interrupt exists. :-)
EDIT 2: Come to think of it, probably the way old DOS programs worked around this was to backup the IVT entry, put their own exception handler in its place, did some floating point ops, and restored the old IVT entry when they were done with the FPU.
你没有遗漏任何东西。
8088 处理器（最初的 IBM PC 中使用的处理器）仅定义了异常 0、1、2、3 和 4。
因此 IBM 将 0x8 到 0xF 用于硬件中断处理程序，将 0x10 及以上用于 BIOS 例程。由于某种原因，IBM 忽略了这样一个事实：Intel 非常明确地为未来的处理器异常保留了编号 0x5 到 0x1F。
随着时间的推移，需要更多的例外，英特尔继续分配它们。大多数时候，旧版软件无论如何都不会触发这些异常，而较新的操作系统（在保护模式下运行的操作系统）可以分配不同的编号，以免与处理器异常发生冲突。
旧软件中添加了大量的技巧，以便在不破坏太多兼容性的情况下使用较新的处理器功能。虽然我不确定，但我怀疑较新的 BIOS 可能会尝试检测 INT10 是由软件中断触发还是由 INT10 处理程序中的协处理器触发。
仅供参考，来自 386 程序员手册：
You're not missing anything.
The 8088 processor (the one used in the original IBM PC) only defined exceptions 0, 1, 2, 3, and 4.
So IBM used 0x8 to 0xF for hardware interrupt handlers and 0x10 and above for BIOS routines. For some reason IBM ignored the fact that Intel had very clearly reserved numbers 0x5 to 0x1F for future processor exceptions.
As time went on, more exceptions were needed and Intel went ahead and assigned them. Most of the time, legacy software didn't trigger these exceptions anyway whilst newer operating systems (those that ran in protected mode) could assign different numbers so as not to clash with the processor exceptions.
There were plenty of hacks added to older software to gain some use of newer processor features without breaking too much compatibility. While I'm not sure, I suspect that perhaps newer BIOSes might have tried to detect whether INT10 was triggered by a software interrupt or by the coprocessor in their INT10 handler.
FYI, from the 386 programmers manual: