当前位置：文江博客话题详情

程序员“隐形”怎么样？寄存器？

发布于 2024-08-25 14:54:28 字数 959 浏览 4 评论 0原文

这些是“程序员可见” x86-64 寄存器：

_{（来源：usenix.org）}

不可见的寄存器怎么样？刚才我了解到MMU寄存器，中断描述符表（IDT）使用这些不可见的寄存器。我正在艰难地学习这些东西。有没有任何资源（书籍/文档/等）可以立即让我了解完整情况？

我知道程序员可见的寄存器并且可以轻松地使用它们进行编程。我只是想了解隐形寄存器及其功能。我想得到一个完整的图片。我在哪里可以得到这些信息？

编辑：

我想得到一个完整的图片。我从哪里可以获得这些信息？

这两本书帮助我理解了所有这些底层细节。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

情绪 2024-09-01 14:54:28

IDT 是一个中断描述符表，从抽象的角度来看，它包含类似这样的内容，前 18 个中断由处理器保留，接下来的 18 个由 Intel 保留，用于未来验证芯片的架构......

Interrupt    Handler
   0         divide_by_zero_handler
   1         debug_handler
   ..           ...
   13        general_exception_handler
   14        page_fault_handler
   ..           ...
   18        machine_check_handler

在这种情况下，处理程序是玩具内核的一部分，并且每个处理程序都是在引导时、在加载用户态代码之前设置的。（BIOS 是 16 位代码，又名实模式代码），内核设置处理程序，切换到 32 位保护模式，当发出任何中断时，根据中断号执行相应的处理程序。例如，如果生成了中断14，内核将执行page_fault_handler，检查该页面是否脏并驻留在磁盘上，然后将该页面加载到内存中，修复地址并清除脏位，执行 IRET 中断返回指令以继续，清除标志...

这是 IDT 如何工作的抽象视图...幕后正在发生更复杂的事情...取决于关于内存管理的体系结构和类型，例如分页/平面/保护/虚拟模式寻址方案...

请查看英特尔文档，提供了英特尔编程的出色而全面的视图...

编辑：
回到 DOS 的旧时代（它是 16 位代码，而且不是很好，完全受内存保护），可以将中断处理程序重新路由到您自己的处理程序，从而覆盖原始 IDT，例如此类中断，Interrupt 9 这是使用 getvect(...) 和 setvect(...) 调用的键盘中断（在此上下文中为 BIOS 中断），您还可以处理一些（并非所有处理器中断，特别是 IDT 0 表示除以零）...尽管这些 BIOS 中断在外观上与处理器中断非常相似，但它们具有共同的功能，两者都具有中断向量表（如当时就知道了）。这就是 TSR（终止驻留）程序如何能够在 DOS 中保持重入，因为 BIOS 中断被重新路由到 TSR 的处理程序......

IDT is an Interrupt Descriptor Table, which contains something like this from an abstract view, first eighteen interrupts are reserved by the processor, the next eighteen are reserved by Intel for future proofing the architecture of the chip...

Interrupt    Handler
   0         divide_by_zero_handler
   1         debug_handler
   ..           ...
   13        general_exception_handler
   14        page_fault_handler
   ..           ...
   18        machine_check_handler

In this context, the handlers are part of a toy kernel, and each of the handlers are set up at boot time, prior to user-land code being loaded. (BIOS is 16 bit code aka real mode code), kernel sets up the handlers, switches to 32bit protected mode, when any of the interrupts are issued, the appropriate handler is executed depending on the Interrupt number. For example, if interrupt 14 was generated, the kernel will execute a page_fault_handler, check if the page is dirty and reside on disk, then load that page into memory, fix up the addresses and clear the dirty bit, executes an IRET Interrupt Return instruction to continue, clearing the flags....

That is an abstract view of how IDT works...There is more complex things going on behind the scenes...depending on the architecture and type of memory management such as paged/flat/protected/virtual mode addressing schemes...

Have a look here at the Intel documentation that gives an excellent and thorough view of the Intel programming...

Edit:
Back in the old days of DOS (which was 16bit code and not well, exactly memory protected), it was possible to re-route the interrupt handlers to your own handlers thus overlaying the original IDT, for an example of such an interrupt, Interrupt 9 which is the Keyboard Interrupt (BIOS interrupts in this context) using the getvect(...) and setvect(...) calls, you could also, handle some (not all of the processor interrupts, notably, IDT 0 for divide by zero)...although those BIOS interrupts were quite similar in appearance to the processor interrupts, they shared a common feature, both did have the table of interrupt vectors (as it was known back then). That was how TSR (Terminate Stay Resident) programs were able to keep re-entrant in DOS as a result of the BIOS interrupts re-routed to the TSR's handlers...

回复收藏 0 原文