序：

我之前在写完printf函数传参之后，所有的技术层面全在操作系统给我们提供的进程抽象之上，但是，作为一个决定挖坑到底的C程序员，我们继续讨论我们关于“内存”这个神坑。

下面是x86-64Linux操作系统给我们提供的，进程（逻辑）地址空间：

图片发自CSAPP

这个图很经典，刚入坑的朋友可以留个心眼，入坑已久的，不用我多说，自然是倒着也能画出来了。

这个图是结果，我们要找的是它的根，但是我们在下面的讨论，并不以x86-64Linux内核真正的内存映射方式为例，而是仅仅从分页技术的角度去讨论。至于原因，很简单我们是来填坑的，一旦使用了更大的技术，那么我们最终填的坑还不如挖的坑多，所以我们的目标很明确——填小坑。

1、对于内存：我们将内存抽象成一个连续的数组空间(关于内存的层次存储结构的坑，我在之后会填上)。

2、对于进程：由序中进程地址空间的结果可以知道，最终我们的操作系统给内存形成了一个连续的地址空间。

我们的最终结果是把内存和进程联系起来，当然，还有很多其他的引导思路的方式（重定位——静态重定位、静态重定位；对换技术；分区法）。当然我这里是引述的某本我觉得还行的书籍上的内容，我自己还没有形成体系。

呃呃呃，又扯远了。对了，上面的坑，我不负责填。

页表——内存和进程的桥梁

既然是桥梁，当然是这头连着进程，那头牵着内存。放下大图：

“喏，我们的桥就是这个样子”

1、桥梁存在的目的：

方便一个进程使用不连续的（物理）内存空间，想象一下，在内存不足的情况下，如果每个进程都使用连续的内存空间，那么我们的内存一次只能加载少量的进程，那么将消耗更多的时间从硬盘加载进程到内存，而在加载的时间我们的CPU极有可能处于空闲状态，那么我们的程序运行上就感觉很慢，客户体验极差。

我来翻译一下桥梁是怎么连接内存和进程的：

2、逻辑地址空间分页：

我们把进程最终的地址空间划分成相等的若干部分，我们称每一个部分为一页。每页都有一个地址编号，我们称为页号。且从0开始依次编排，如0，1，2，3...

3、内存空间分块：

我们把内存等分成与一个页相等的若干部分，每个部分称为内存块。同样，对他们进行编号，块号从0开始依次编排：0#块，1块，2#块，3#块...

页或块的大小是由硬件（系统）确定的，它一般被选择为2的若干次幂。例如，IBM AS/400规定的页面大小为512B，而Intel 80836的页面大小为4KB（即4096B）。所以不同的机器页面大小有所不同。

我们现在得到了几个零散的概念，我在这里再重新梳理一遍：

进程空间的页，内存空间的块，桥梁。

我们的空间页和内存块都是一段绝对连续的线性字节数组，我们要把空间页和内存块连接起来，现在猜测，有一种可能的方式：页表的任一项的一段保存某一空间页的首地址，另一段保存块的首地址。好像没有什么毛病，对吧。但是，这种方式并不利于我们的数据寻址。为什么不利于，这个坑，我也不填。

4、而实际上的联系

我们并不是在页表的每一项保存页和块的首地址，而是页号和页内地址。

例如：我们的进程中有一条代码的指令是：LOAD 1，500，它实现把500号单元的数据装到寄存器1中去。这里的500还是我们程序被编译好之后的可重定位地址，还是相对地址。我们首先从地址A(这里是500)，由分页地址映像硬件自动得到我们的页表项内容：页号和块号桥(p，d)。然后以页号p为索引去检索页表，得到我们的块号f，然后由块号f和页内地址d在内存空间中进行数据检索。下面是详细图：

每个作者有不同的理解方式，这是某本书原作者的内容

经过上述的步骤，我们的进程地址空间和内存空间就形成了一个良好的联系。再啰嗦一句，上面我只提到数据寻址，其实我们往内存中保存数据时就是这种方式，所以才能有我们数据寻址的结果。

页号p和页内地址d的求值方式

还是从某书的照片，我太懒了，直接看图吧

进程和内存的桥梁——页表技术(x86-64Linux下)

序：