`
coolerbaosi
  • 浏览: 722069 次
文章分类
社区版块
存档分类
最新评论

从程序员角度深入计算机系统的底层 内存地址转换与分段

 
阅读更多
本文是Intel兼容计算机(x86)的内存与保护系列文章的第一篇,延续了启动引导系列文章的主题,进一步分析操作系统内核的工作流程。与以前一样,我将引用Linux内核的源代码,但对Windows只给出示例(抱歉,我忽略了BSDMac等系统,但大部分的讨论对它们一样适用)。文中如果有错误,请不吝赐教。

在支持Intel主板芯片组上,CPU对内存的访问是通过连接着CPU和北桥芯片的前端总线来完成的。在前端总线上传输的内存地址都是物理内存地址,编号从0开始一直到可用物理内存的最高端。这些数字被北桥映射到实际的内存条上。物理地址是明确的、最终用在总线上的编号,不必转换,不必分页,也没有特权级检查。然而,在CPU内部,程序所使用的是逻辑内存地址,它必须被转换成物理地址后,才能用于实际内存访问。从概念上讲,地址转换的过程如下图所示:

63d47c286de8a76b33b540bc9d74975b.jpg




x86 CPU开启分页功能后的内存地址转换过程



此图并未指出详实的转换方式,它仅仅描述了在CPU的分页功能开启的情况下内存地址的转换过程。如果CPU关闭了分页功能,或运行于16位实模式,那么从分段单元(segmentation unit)输出的就是最终的物理地址了。当CPU要执行一条引用了内存地址的指令时,转换过程就开始了。第一步是把逻辑地址转换成线性地址。但是,为什么不跳过这一步,而让软件直接使用线性地址(或物理地址呢?)其理由与:“人类为何要长有阑尾?它的主要作用仅仅是被感染发炎而已”大致相同。这是进化过程中产生的奇特构造。要真正理解x86分段功能的设计,我们就必须回溯到1978年。


最初的8086处理器的寄存器是16位的,其指令集大多使用8位或16位的操作数。这使得代码可以控制216个字节(或64KB)的内存。然而Intel的工程师们想要让CPU可以使用更多的内存,而又不用扩展寄存器和指令的位宽。于是他们引入了段寄存器segment register),用来告诉CPU一条程序指令将操作哪一个64K的内存区块。一个合理的解决方案是:你先加载段寄存器,相当于说“这儿!我打算操作开始于X处的内存区块”;之后,再用16位的内存地址来表示相对于那个内存区块(或段)的偏移量。总共有4个段寄存器:一个用于栈(ss),一个用于程序代码(cs),两个用于数据(dses)。在那个年代,大部分程序的栈、代码、数据都可以塞进对应的段中,每段64KB长,所以分段功能经常是透明的。


放一些老式的8086级别的寄存器描述架构图


dd09efff6d698abd71fb48f32f4a7ff3.jpg



c099d07b15ad9fed89c6f1bcf947ac85.jpg



可以很明显的看出来,在8088设备上的段寄存器属于一种存储器影射控制设备。这是否让我们联想到了现在的[size=-1]物理地址扩展(PAE)技术?



现今,分段功能依然存在,一直被x86处理器所使用着。每一条会访问内存的指令都隐式的使用了段寄存器。比如,一条跳转指令会用到代码段寄存器(cs),一条压栈指令(stack push instruction)会使用到堆栈段寄存器(ss)。在大部分情况下你可以使用指令明确的改写段寄存器的值。段寄存器存储了一个16位的段选择符(segment selector);它们可以经由机器指令(比如MOV)被直接加载。唯一的例外是代码段寄存器(cs),它只能被影响程序执行顺序的指令所改变,比如CALLJMP指令。虽然分段功能一直是开启的,但其在实模式与保护模式下的运作方式并不相同的。

在实模式下,比如在引导启动的,段选择符是一个16位的数值,指示出一个段的开始处的物理内存地址。这个数值必须被以某种方式放大,否则它也会受限于64K当中,分段就没有意义了。比如,CPU可能会把这个段选择符当作物理内存地址的高16位(只需将之左移16位,也就是乘以2^16)。这个简单的规则使得:可以按64K的段为单位,一块块的将4GB的内存都寻址到。遗憾的是,Intel做了一个很诡异的设计,让段选择符仅仅乘以24(或16),即左移4bit(总计20 bit Addr =1MB Space),从而一举将寻址范围限制在了1MB,还引入了过度复杂的转换过程。下述图例显示了一条跳转指令,cs的值是0x1000

2fceff6a5cbd35fa7a763ff33c061579.jpg



实模式分段功能



实模式的段地址以16个字节为步长,从0开始编号一直到0xFFFF0(即1MB)。你可以将一个从00xFFFF16位偏移量(逻辑地址)加在段地址上。在这个规则下,对于同一个内存地址,会有多个段地址/偏移量的组合与之对应,而且物理地址可以超过1MB的边界,只要你的段地址足够高(参见臭名昭著的A20线)。同样的,在实模式的C语言代码中,一个远指针far pointer)既包含了段选择符又包含了逻辑地址,用于寻址1MB的内存范围。真够“远”的啊。随着程序变得越来越大,超出了64K的段,分段功能以及它古怪的处理方式,使得x86平台的软件开发变得非常复杂。这种设定可能听起来有些诡异,但它却把当时的程序员推进了令人崩溃的深渊。

32位保护模式下,段选择符不再是一个单纯的数值,取而代之的是一个索引编号,用于引用段描述符表中的表项。这个表为一个简单的数组,元素长度为8字节,每个元素描述一个段。看起来如下:


510c697b8c95052bdb06e8a12bffd988.jpg



段描述符



有三种类型的段:代码,数据,系统。为了简洁明了,只有描述符的共有特征被绘制出来。基地址base address)是一个32位的线性地址,指向段的开始;段界限limit)指出这个段有多大。将基地址加到逻辑地址上就形成了线性地址。DPL是描述符的特权级(privilege level),其值从0(最高特权,内核模式)到3(最低特权,用户模式),用于控制对段的访问。

这些段描述符被保存在两个表中:全局描述符表GDT)和局部描述符表LDT)。电脑中的每一个CPU(或一个处理核心)都含有一个叫做gdtr的寄存器,用于保存GDT的首个字节所在的线性内存地址。为了选出一个段,你必须向段寄存器加载符合以下格式的段选择符:


e3f97741e54688660ae674f17d97a2f1.jpg



段选择符



GDTTI位为0;对LDTTI位为1index指出想要表中哪一个段描述符(译注:原文是段选择符,应该是笔误)。对于RPL,请求特权级(Requested Privilege Level),以后我们还会详细讨论。现在,需要好好想想了。当CPU运行于32位模式时,不管怎样,寄存器和指令都可以寻址整个线性地址空间,所以根本就不需要再去使用基地址或其他什么鬼东西。那为什么不干脆将基地址设成0,好让逻辑地址与线性地址一致呢?Intel的文档将之称为“扁平模型”(flat model),而且在现代的x86系统内核中就是这么做的(特别指出,它们使用的是基本扁平模型)。基本扁平模型(basic flat model)等价于在转换地址时关闭了分段功能。如此一来多么美好啊。就让我们来看看32位保护模式下执行一个跳转指令的例子,其中的数值来自一个实际的Linux用户模式应用程序:

c0c19c1ca537feab8abb229ed89c0227.jpg



保护模式的分段



段描述符的内容一旦被访问,就会被cache(缓存),所以在随后的访问中,就不再需要去实际读取GDT了,否则会有损性能。每个段寄存器都有一个隐藏部分用于缓存段选择符所对应的那个段描述符。如果你想了解更多细节,包括关于LDT的更多信息,请参阅《Intel System Programming Guide3A卷的第三章。2A2B卷讲述了每一个x86指令,同时也指明了x86寻址时所使用的各种类型的操作数:16位,16位加段描述符(可被用于实现远指针),32位,等等。

Linux上,只有3个段描述符在引导启动过程被使用。他们使用GDT_ENTRY宏来定义并存储在boot_gdt数组中。其中两个段是扁平的,可对整个32位空间寻址:一个是代码段,加载到cs中,一个是数据段,加载到其他段寄存器中。第三个段是系统段,称为任务状态段(Task State Segment)。在完成引导启动以后,每一个CPU都拥有一份属于自己的GDT。其中大部分内容是相同的,只有少数表项依赖于正在运行的进程。你可以从segment.hLinux GDT的布局以及其实际的样子。这里有4个主要的GDT表项:2个是扁平的,用于内核模式的代码和数据,另两个用于用户模式。在看这个Linux GDT时,请留意那些用于确保数据与CPU缓存线对齐的填充字节——目的是克服冯·诺依曼瓶颈。最后要说说,那个经典的Unix错误信息“Segmentation fault”(分段错误)并不是由x86风格的段所引起的,而是由于分页单元检测到了非法的内存地址。唉呀,下次再讨论这个话题吧。


Intel巧妙的绕过了他们原先设计的那个拼拼凑凑的分段方法,而是提供了一种富于弹性的方式来让我们选择是使用段还是使用扁平模型。由于很容易将逻辑地址与线性地址合二为一,于是这成为了标准,比如现在在64位模式中就强制使用扁平的线性地址空间了。但是即使是在扁平模型中,段对于x86的保护机制也十分重要。保护机制用于抵御用户模式进程对系统内核的非法内存访问,或各个进程之间的非法内存访问,否则系统将会进入一个狗咬狗的世界!在下一篇文章中,我们将窥视保护级别以及如何用段来实现这些保护功能。

分享到:
评论

相关推荐

    从程序员角度深入计算机系统的底层

    从程序员角度深入计算机系统的底层,非原创,但是不知道作者是谁,如果侵犯到您的权益请告知。写得不错,系统总结了系统引导的过程。从硬件自举--MBR--Bootloader--引导分区---内核装载。

    程序员角度深入理解计算机系统

    原名: Computer Systems A Programmer’s Perspective 只需更少的资源分

    深入理解计算机系统(程序员角度的计算机系统)(原书第2版).part07

    本书从程序员的视角详细阐述计算机系统的本质概念,并展示这些概念如何实实在在地影响应用程序的正确性、性能和实用性。这是其中第七章

    以程序员视角来看计算机系统

    一本非常好的从程序员角度出发讲解计算机系统的书籍。从此书中我们可以看到计算机计算的本质到底是什么,如何构成的,各部分的协作,程序语言到机器语言,程序优化设计等等。

    《深入理解计算机系统》每个程序员都必备

    个人觉得这是每个程序员必须研读的一本书,对程序的理解会更加到位,不懂计算机的程序员是假程序员

    从程序员视角理解计算机系统

    计算机基础课程入门讲义《从程序员视角理解计算机系统》。 内容包括:helloword程序、计算机基本组成、存储系统的性能对别。

    从程序员的视角详细解读计算机系统.rar

    本书从程序员的视角详细阐述计算机系统的本质概念,并展示这些概念如何实实在在地影响应用程序的正确性、性能和实用性。全书共12章,主要内容包括信息的表示和处理、程序的机器级表示、处理器体系结构、优化程序性能...

    程序员终身必读-深入理解计算机系统(带笔记).part1

    这本书有多经典就不再赘述了。由于是图片书,所以有点大。不过效果还可以,上面有一些我个人的笔记,相信对阅读有些帮助。建议阅读3遍以上,多多益善。可以作为程序员终身发展的陪伴读物,良友啊。

    深入理解计算机系统精通底层的机制

    深入理解计算机系统精通底层的机制,使程序员了解底层的开发

    深入理解计算机系统2

    深入理解计算机系统 中文 pdf 版,也叫从程序员角度理解计算机系统,我当年可是花了很多银子买的纸质图书,很....... 对不起大家,我也需要积分!

    深入理解计算机系统(清晰版)

    本书主要介绍了计算机系统的基本概念,包括最 深入理解计算机系统各个版本 ...此书以程序员的视角全面讲解了计算机系统,深入浅出地介绍了处理器、编译器、操作系统和网络环境,是这一领域的权威之作。

    深入理解计算机系统(中文版)

    此书以程序员的视角全面讲解了计算机系统,深入浅出地介绍了处理器、编译器、操作系统和网络环境,是这一领域的权威之作。 本书适合作为计算机及相关专业的本科生教材,同时也适用于编程人员参考阅读。

    深入理解计算机系统-中英文

    《深入理解计算机系统》(英文版)主要介绍了计算机系统的基本概念,包括最底层的内存中的数据表示、流水线指令的构成、虚拟存储器、编译系统、动态加载库,以及用户应用等。书中提供了大量实际操作,可以帮助读者更好...

    国家软考 程序员考试计算机系统知识

    程序员考试 计算机系统知识 计算机系统知识 最新教材讲解,值得一看

    从程序员的角度看ELF.rar

    这篇文档从程序员的角度讨论了linux的ELF二进制格式。介绍了一些ELF执行 文件在运行控制的技术。展示了如何使用动态连接器和如何动态装载ELF。 我们也演示了如何在LINUX使用GNU C/C++编译器和一些其他工具来创建...

    深入理解计算机系统(英文原版)

    主要介绍了计算机系统的基本概念,包括最 深入理解计算机系统各个版本 ...此书以程序员的视角全面讲解了计算机系统,深入浅出地介绍了处理器、编译器、操作系统和网络环境,是这一领域的权威之作。

    深入理解计算机系统-中文版-ppt6b

    本书主要介绍了计算机系统的基本概念,包括最底层的内存中的数据表示、流水线指令的构成、虚拟存储器、编译系统、动态加载库,以及用户应用等。书中提供了大量实际操作,可以帮助读者更好地理解程序执行的方式,改进...

    深入理解计算机系统-中文版-ppt5

    本书主要介绍了计算机系统的基本概念,包括最底层的内存中的数据表示、流水线指令的构成、虚拟存储器、编译系统、动态加载库,以及用户应用等。书中提供了大量实际操作,可以帮助读者更好地理解程序执行的方式,改进...

Global site tag (gtag.js) - Google Analytics