为什么64位模式(长模式)不使用段寄存器？

Question

我是初学者级别的学生:)我正在研究英特尔架构,我正在研究内存管理,例如分段和分页.我正在阅读英特尔的手册,了解英特尔的架构非常好.

但是我仍然对一些基本的东西感到好奇.为什么在64位长模式下,所有段寄存器都会转到0位？为什么系统不再使用段寄存器？

因为系统的64位大小(例如GP寄存器)足以一次包含那些逻辑地址？保护是否在64位模式下正常工作？

我试图找到64位寻址但我在谷歌找不到.也许我有很糟糕的搜索技巧,或者我可能需要一些特定的先前知识来搜索谷歌.

因此,我想知道为什么16位段寄存器不会在64位模式下使用,以及如何在64位模式下正常工作.

谢谢!

Answer 1

从某种意义上讲,当您使用通用寄存器执行数组("索引")类型寻址时,您实际上与段寄存器完全相同.在8位和16位编程过去的糟糕时期,许多应用程序需要比16位地址更多的数据(有时更多的代码).

如此多的CPU通过具有比16位地址可达到的更大的可寻址存储空间来解决这个问题,并且通过"段寄存器"或类似方式使这些存储区域可访问.程序将"段寄存器"中的地址设置为(65536字节)16位地址空间之上的地址.然后,当执行某些指令时,它们会将指令指定的地址添加到适当的(或指定的)"段寄存器",以读取超出16位地址或16位偏移范围的数据(或代码).

但是,今天的情况正好相反!

怎么会这样？今天,64位CPU可以处理超过(不小于)所有可寻址存储空间.今天大多数64位CPU可以处理40位到48位物理内存.没错,没有什么可以阻止他们解决一个完整的64位内存空间,但是他们知道没有人(但是NSA)可以负担得起那么多内存,而且,在CPU总线上挂上那么多的内存会将其加载到电容上,并减慢CPU芯片外的所有内存访问速度.

因此,目前这一代主流CPU可以满足40位到48位的存储空间,这是市场有史以来想象的99.999%.请注意,32位是4千兆字节(有些人今天超过了2倍,4倍,8倍,16倍),但即使是40位也可以解决256*4GB == 1024GB == 1TB.虽然今天64GB的RAM是合理的,在极端情况下甚至可能是256GB,但除了大约0.001%的应用程序外,1024GB只是不必要的,并且无法启动.

如果您在0.001%的类别中,只需购买一个能够处理48位物理内存的CPU,并且您正在谈论256TB ...这当前是不切实际的,因为它会大大加载内存总线电容(甚至到内存总线停止完全停止工作的程度).

重点是这一点.当普通64位寄存器的正常寻址模式已经可以解决比计算机可以包含的内存更多的内存时,添加段寄存器的传统原因就会消失.

这并不意味着人们无法在64位CPU中找到段寄存器的有用用途.他们可以.有几种可能性很明显.但是,对于64位通用寄存器和64位地址空间,通用寄存器无法实现段寄存器的功能.通用寄存器有很多用途,段寄存器没有.因此,如果有人计划在现代64位CPU中添加更多寄存器,他们会添加通用寄存器(可以执行"任何操作"),而不是添加非常有限的用途"段寄存器".

他们确实有.您可能已经注意到,AMD和英特尔不断向SIMD寄存器文件添加更多[sorta]通用寄存器,并且AMD在设计64位x86_64 CPU(英特尔)时将[真正]通用寄存器的数量增加了一倍复制).

Answer 2

大多数关于 32/64 位世界中段寄存器无关性问题的答案总是围绕着内存寻址。我们都同意段寄存器的主要目的是绕过 16 位 DOS 世界中的地址空间限制。然而，从安全能力的角度来看，段寄存器提供了 4 个地址空间隔离环，如果我们使用 64 位长模式，例如对于 64 位操作系统，这是不可用的。这对于当前流行的操作系统（例如 Windows 和 Linux）来说不是问题，它们仅使用具有两个隔离级别的环 0 和环 3。环 1 和环 2 有时是内核的一部分，有时是用户空间的一部分，这取决于代码的编写方式。从隔离的角度来看，随着硬件虚拟化（相对于操作系统虚拟化）的出现，管理程序不太适合环 0 或环 1/2/3。

那么提出的重点是什么？如果有人正在设计具有 4 个隔离环的新安全操作系统，那么如果禁用分段，我们就会遇到问题。例如，我们为硬件复用代码、管理程序代码/容器/VM、操作系统内核和用户空间各使用一个环。因此，我们可以利用基于上述要求的分段提供的额外安全性。但是，Intel/AMD 仍然允许 F 和 G 段寄存器具有非零值（即不禁用段）。据我所知，没有任何操作系统利用这一希望为硬件虚拟化编写更安全的操作系统/管理程序。