CPU瞒着内存竟干出这种事

还记得我吗，我是阿Q，CPU一号车间的那个阿Q。

今天忙里偷闲，来到厂里转转，负责这项工作的小黑正忙得满头大汗。

看到我的到来，小黑指着旁边的座椅示意让我坐下。

我一听来了兴趣，“小黑你给我说说你们的工作呗，地址翻译是怎么一回事儿，为什么怀念以前呢

小黑调整了下坐姿，咕噜咕噜喝了几口水说道，“这话说来可就话长了”

接下来小黑开始给我讲起了历史故事······

8086

原来咱们的祖先叫8086，小黑还给我看了他的照片

通过这些触角，CPU就可以跟内存打交道，获取指令和数据，辛勤的干活啦。

那个年代，条件比较差，能凑合的就凑合，能共用的就共用。这不，你看祖先CPU的地址总线针脚和数据总线针脚就共用了。

祖先是一个16位的CPU，数据(Data)总线就有16位，一次性可以传输16个比特位。和地址(Address)总线凑合着一起共用，于是就取名AD0-AD15。

不过祖先的地址总线却不止16个，还多出了A16-A19整整4个呢！这样有20个地址线，可以寻址1MB的内存了！

但是祖先的寄存器都是16位的啊，只能存放16位的地址。不过他们很聪明，发明了一个叫的方法，把内存划分为最大64KB的小块，为什么是64KB呢，因为16位地址最多只能寻址这么大了。然后又加了几个叫做段寄存器的东西，指向这些块的开头，这样，通过段地址+段内偏移地址的方式，就能访问更多的内存了。

到了80386时代，我们与外界通信的引脚就更多了，并且变成了32位的CPU，那个时候，生活条件就变好了，地址线和数据线再也不用共享引脚了。

先祖们为了此事殚精竭虑，终于想出了一个好办法，一直沿用至今。

他们提出了一个的东西，所有程序使用的地址都是一个虚拟的地址，在真正和内存打交道的时候，咱们CPU内部工作人员再给翻译成真实的内存地址，关于这事儿，内存那家伙一直被我们蒙在鼓里。

为此，在我们寄存器内部专门添置了一个新的寄存器CR3，用来指向一个地址翻译查询字典，字典划分了两级目录。我们把一个32位的地址划分了3部分，前面两部分分别指向两级目录中的条目，用来定位这个地址在物理内存的哪个页面，最后一部分就是指向物理内存页面的偏移，这样就完成了地址的翻译工作。

每个进程有不同的地址空间，切换进程的时候，把CR3的内容换一下就使用新进程的翻译字典，特别的方便。

我们把这种内存管理方式叫做。

真佩服先祖们的智慧，这样巧妙的把各个程序隔离开来，后来我们把这种工作模式叫做，把之前那种直接使用真实内存地址的工作模式叫做。

分页交换

人类变得越来越贪婪，程序变得越来越多，对内存的需求也越来越大。随着这些程序都不断申请内存页面，内存空间很快就要耗尽了。

我们看在眼里，急在心里，后来找操作系统协商，看看这问题该怎么办。

我们不仅从32位变成了64位，还从单核变成了多核，像我所在的CPU就有8个车间，8核并行执行，比起先祖那个年代简直有云泥之别。

彩蛋

和小黑闲谈间，我们车间的老K突然出现在了门口。

“阿Q原来你在这里，让我好找，赶快回去吧，隔壁二号车间的虎子说我们改了他们的数据，上门来闹事了······”

预知后事如何，请关注后续精彩······

往期热门回顾

完了！CPU一味求快出事儿了！

可怕！CPU竟成了黑客的帮凶！

哈希表哪家强大编程语言吵起来了！

内核地址空间大冒险4:线程切换

震撼！全网第一张源码分析全景图揭秘Nginx

一个整数＋1引发的灾难

一网打尽！每个程序猿都该了解的黑客技术大汇总

看过无数Java GC文章，这5个问题你也未必知道！

一个Java对象的回忆录：垃圾回收

谁动了你的HTTPS流量/p>

路由器里的广告秘密

一个HTTP数据包的奇幻之旅

我是一个流氓软件线程

来源：编程技术宇宙