原文出处：从裸机启动一个C++程序

本文是纯原创文章，在创作时分了16篇更新在笔者的个人CSDN博客上，为保护版权，图片 都有CSDN的水印，整理到KM上时直接引用了img.blog.csdn的图片链接。（因为创作的时候都是直接截图贴上去的，没有本地保留不带水印的版本「手动捂脸」「手动狗头」，如果页面配图有问题可以在附件里找原图）。

由于原本是分篇的，因此工程示例的文件编号可能还保留原本的章节号，笔者就懒得去一一更改了，大家能找到就好~~_

对于一个C++程序员来说，可能更多是是每天都在跟各种上层语义、设计模式、软件方法等等在打交道。但对于「一个C++程序是如何运行在机器上的」这件事可能会比较陌生。有时，遇到一些问题，在宏观角度看起来可能比较难以解释，但其实从底层出发，就能发现这个问题其实根本不算问题。类似的问题有：

1. 空指针到底能不能访问？(int *p = nullptr; *p = 5;)

2. 给一个变量取地址，取到的是不是物理地址？(int a; std::cout << &a;)

3. 操作一个常数地址是否合法？（*(int *)0xa0000 = 0x41;）

4. 全局变量、静态局部变量、字符串字面量等在内存中是如何布局的？

5. C/C++程序如何编译为内核代码，运行在内核态程序上？

6. gdb过程中，看到的寄存器是否是真实的？

上面这些疑问，有一些是被读者问到的，还有一些是笔者曾经思考过，但没有很快解决的。与此同时，笔者发现，中层、通用性的教程比比皆是，但高层和底层的、专精型的教程却是少之又少。很多问题可能其实很简单，但就是搜不到相关的教程。笔者也曾尝试到一些系统讲解底层的书籍中寻找答案，但也发现，它们在各自突出的领域中讲解地很详细，但对于上下层串联的部分却总是有缺失，导致各个领域的知识是破碎的，难以关联在一起，以建立一个更加宏观的体系。

于是在经过了一系列研究和实验之后，笔者决定起笔这一篇文章。在这篇文章中将会介绍：

1. x86体系的结构和启动过程

2. 如何编写一个简单的MBR(Master Boot Record)，然后进入内核程序

3. 如何从用C/C++来生成内核程序（包括编译、链接、转载的方法）

4. 站在内核的角度看到的内存结构是怎样的

5. C/C++程序的内存分布是怎样的，各部分加载到内存中的形态是怎样的

6. C代码和C++代码编译方式的异同

关于本文，有以下几点说明：

1. 本文的底层逻辑以x86体系为例，C/C++代码也会生成x86体系的机器码。

2. 虽然我们的项目是x86架构的，但即便你使用的是ARM架构的设备（例如搭载苹果自研M系列芯片的Mac）也没有关系，笔者会介绍可以在ARM版macOS上编译和运行x86程序的方法，会使用跨平台运行的模拟器。

3. 本文使用到的工具都是业界通用的、能轻易在网上下载到并且很容易找到对应说明文档的软件，不会使用笔者自研的黑盒程序，并且会详细介绍每一种工具的部署、使用方法，保证读者可以完成实验

4. 对于一些历史发展历程，和一些历史遗留问题的诞生，笔者会花一部分篇幅来「讲故事」，如果读者不感兴趣，则可以跳过相关的篇幅，直接看结论即可。

如果你准备好了的话，我们马上开始！

x86体系架构

相信读者对x86这个词肯定不陌生，那么它到底指的是什么呢？

指令集

对于一个CPU来说，其实就是一个高集成的逻辑电路。如果你玩过数字电路的话，一定会知道所谓的「与」「或」「非」门电路，用这些门电路组合起来，我们就可以实现更多更复杂的功能。

不过逻辑电路再复杂，无非也就是把「一组输入的电信号」转换为「一组输出的电信号」，这就是它最基本的功能。比如说，某一个芯片有3个输入引脚，2个输出引脚，当我给输入引脚分别给「高电平，高电平，低电平」的时候，它能在输出引脚给我「低电平，高电平」这样的信号。在刚才这段描述中，「芯片的输入、输出引脚个数」称为「芯片的接口规模」，而「当给XXX输入信号的时候，能给我YYY输出信号」则称为「芯片的逻辑功能」。

因此，我们把那些「可以用来输出的信号」就称作「指令」，而这个芯片能够支持的所有「指令」的集合，就称为「指令集」。因此，一个CPU的指令集直接决定了它的原始功能。

而x86体系架构使用的这种指令集，我们就可以叫他x86指令集，用来描述所有x86体系架构的CPU能够支持哪些指令。

当然，除了最核心的指令集以外，「体系架构」自然还包括CPU的其他部件要有哪些，以及跟外部硬件应当如何交互。总之，我们可以认为这是一套协议标准，当我们使用了x86体系的CPU以后，它一定会含有哪些部件、怎么给它指令它就能正常运行、外部的硬件应当如何布局等等这些问题就已经确定了。我们只需要按照它所规定的协议来编写程序，就可以在这个体系上正常运行了。

为什么叫x86？

解释完x86是什么了以后，相信一定会有读者好奇，这种架构为什么叫这个名字？它和我们现在市面上主流的硬件设备是什么样的关系？

故事要从1978年开始说起。1978年，Intel公司推出了一款CPU，型号叫8086（至于为啥叫这个数字，估计只能问Intel了……）。其实在当年，这款CPU也没激起多大的浪花，我们现在大家都去研究它，也不过是幸存者偏差罢了。所以我们只需要知道，20世纪70年代末，一个姓英的公司（英特尔）发布了一款芯片，型号为8086。

8086芯片没有太大的动静，这有一个非常关键的问题，就是它太贵了！因为它要卖360美元一个。注意！这仅仅是CPU的价钱，没有算其他的硬件。所以能用得起的一般都是极个别的企业，个人用户可谓望尘莫及了。而真正让这个系列的芯片火起来的是8088。

8088我们可以认为是8086的一个精简版，或者我们可以戏称为「8086 SE」~。1981年，IBM使用了8088芯片，生产了面相个人的PC，价格亲民，因此在全球范围内火了起来，也就带动了这个系列的芯片的销量。

此后，Intel就开始了这个架构的CPU的研发迭代，后续又推出了80186、80286、80386。它们都兼容8086的工作模式，但在这个过程中还是出现了一些小插曲（或者可以理解为小bug，这个后续章节会涉及）。

由于这个系列都以86结尾，因此就管这个系列叫做「x86」系列。但注意，「x86架构」则是专指80386以及以后的芯片，而不包括8086、80186和80286，原因我们会在后续章节解释。

直到1992年，本应叫「80586」的CPU诞生之前，Intel因为一些商标版权的问题，使得这个系列不得不改名，当时的80586上市时，名为「Pentium」，中文译作「奔腾」。

后续Intel又发布了「Celeron（赛扬）」系列，还有「Core（酷睿）」系列，以及「Xeon（至强）」系列，都沿用了x86架构，Intel将其称为「IA-32架构」，它们都保持着向下兼容。

x64和x86的关系

故事的转折点在2001年，那个时候有人觉得x86架构有缺陷，不应该继续沿用，于是推出了一款全新的架构，称之为「IA-64」架构，并推出了这个架构的处理器——「Itanium（安腾）」系列。

这里的IA指的是Intel Architecture，而64表示它的指令字长（后续会重点解释）。本来这个命名的目的也很明确，曾经的是「IA-32」，现在重新设计以后叫做「IA-64」。但是因为它并没有向下兼容IA-32，并且价格昂贵，因此在个人PC领域并没有溅起水花。而它主打的服务器领域则是没有拼过IBM的PowerPC，所以也没有太多市场。这也导致了安腾系列的CPU至今都不是很出名。

IA-64不成功，但另一个64位架构却火了，这就是AMD公司在1999年首次推出的AMD64架构。后续AMD64架构被广泛用于个人PC上。那么，AMD64的魅力在哪？其实就在于，它兼容了IA-32架构，并在此之上进行了扩展。因此，AMD64架构也被称为「x86-64」架构，也就是扩展64位的x86架构。

所以这里就有一个很有意思的现象，IA-64作为IA-32的继承者，并没有兼容IA-32，并且没落了。反而是AMD64夺得了王冠，向下兼容IA-32。由于AMD64架构的成功，后续也被Intel所使用，并将其命名为Intel 64。

其实Intel 64和AMD64基本没有区别，主要还是商业竞争中刻意区分了它们。但是硬件厂商的这些商业竞争，对于这些软件公司来说无足轻重，他们只关心，我的软件适配哪种架构，就够了。因此，他们无论描述为「AMD64」还是「Intel 64」，都似乎有站队的嫌疑，而又因为Intel64和AMD64其实就是同一套架构，因此这些软件厂商又把这种架构称为「x64架构」，其中「x」你自己脑补把，Intel也行，AMD也行。

因此我们总结一下：

1. x86架构又叫IA-32架构，是从Intel 80386芯片开始所使用的架构，向下兼容8086和80286架构

2. IA-64架构不兼容IA-32，仅用于Intel Itanium系列

3. x86-64架构向下兼容IA-32架构，又被称为AMD64架构和Intel 64架构，进而合称x64架构，目前市面上绝大多数的个人PC使用的就是这种架构（包括Intel的酷睿、至强，AMD的锐龙系列）

值得注意的是，由于x64是向下兼容x86的，因此在很多人口中，并不会区分它们，又因为x86架构已经过时很久了，现在很少有设备会去使用。因此有时我们听到「x86」其实指的就是x64架构，尤其是跟ARM架构放在一起描述的时候（比如我们经常会说，苹果从x86转向了ARM，但其实这里的x86指的是x64，而非真正的IA-32架构）。

所以为了避免混淆，笔者在本系列文章中，统一用「IA-32架构」和「AMD64」架构的名称，而不使用「x86」这种可能有二义性的词汇。

为什么选择AMD64架构？

因为这是当前市面上使用最多的架构。随处可见的Intel Core处理器，AMD Ryzen处理器使用的都是AMD64架构。并且，最常用作服务器的Intel Xeon处理器也是这个架构的，所以我们了解最主流的架构自然是不亏的。

另一方面，也正是因为这是目前的主流架构，因此它的相关资料也是最全、最好找的，黑盒较少，比较透明，所以学习门槛较低。计算机底层专业课程的各主流教材也都是选用了这个架构为例进行讲解的。

既然我们是为了理清程序的构建和运行相关知识，那么架构这里就不要让它成为我们的极大困难点，于是，笔者「毅然决然地」选择了它。（偷笑，其实是因为别无选择~）

搭建虚拟环境

了解完这个架构的情况以后，我们接下来要做的就是找机器，然后进行开发了。

硬件环境

既然是要给AMD64架构的设备进行开发，那么首先，我们得先有一个AMD64架构的硬件设备才行。首先最容易想到的，就是真实地搞一台AMD64架构的电脑。

这方法最直接，但是成本有点高，而且装载程序可能没那么方便。当然了，如果你手边正好有空闲的设备，或者已经不用的老设备，那自然无可厚非。你可以把程序直接运行在真机上，也会有一个不一样的体会，而且满满的仪式感，很酷！

虚拟环境

如果没有，那也没关系，因为我们可以用虚拟机。关于虚拟机的运行，通常有两种方式：

1. 通过虚拟化（Virtualization）技术运行

2. 通过软件模拟（Simulation）运行

这里~翻译必须出来背个锅了！Virtualization和Simulation是完全不同的两种虚拟技术，但这里的翻译似乎完全没有把它们区分开，「虚拟化」和「模拟」到底什么区别？反正，从字面上……我是区别不开…………

那么这两者究竟指什么呢？首先我们要知道，要想通过软件的方式模拟一台硬件设备，那这个「软件」应当是运行在已经良好运行的操作系统上了。换句话说，我们要用操作系统开启一个应用程序，然后在这个应用程序中，模拟出硬件设备的各种部件，再利用这种模拟出的部件来执行指令。

软件模拟方式

那么最容易想到的就是用「纯软件」的方式来模拟。比如说我设置一个变量，用来表示rax寄存器，设置另一个变量来表示rip寄存器。再设置一片内存空间来表示模拟器的内存空间。之后，当我接收到类似于「把0x10内存空间的值写到rax寄存器中」这样的指令时，就把对应内存空间中，偏移量是0x10的值，赋值给用于表示rax寄存器的变量中。大致上用简单的代码来表示就是：

uint64_t rax; // 用于模拟rax寄存器
std::byte mem[1024 * 1024]; // 用于模拟1MB的内存

// 执行将内存数据读取到rax中的指令
void load_mem_to_rax(std::ptrdiff_t address) {
  rax = *reinterpret_cast<uint64_t *>(mem + address);
}

由此方法，模拟出所有硬件部件和所有指令集中的指令，那么自然就可以模拟出硬件设备的运行情况。

上面这种模拟方式就称为「Simulation」方式，或者叫「软件模拟」方式。

这种方式的优点非常明显：

1. 不受目标机器架构的影响，也就是说，我们可以在ARM架构的电脑上运行AMD64架构的模拟器，反之亦然。

2. 可以实时观测和修改模拟硬件的值。这种优势更加明显，由于CPU的微指令更改的仅仅是CPU内部部件的值（比如说寄存器）或者内存某个数据的值。这些更改如果不能显示到屏幕上的话，我们就没法观测到。但如果我们用的是纯软件模拟的机器，那观察这些值就变得无可厚非了，因为它们本质上只是这个进程当中的变量而已。这个优点甚至是我们使用真机都无法比拟的。

当然，它的缺点也非常明显，那就是性能底下。试想，一条软件模拟的「内存读入寄存器」的指令，被软件模拟成了不同变量之间的赋值，这过程还有不少程序逻辑，还有本身OS的调度算法等等。中间隔了这么多层，CPU真实运行的指令早都不知道被扩大成多少条了。因此，这种方式的模拟器，它的性能下降幅度是指数型的。

虚拟化方式

随着虚拟机的使用越来越普遍，市面上主流的OS都开始重视了这个问题。因此，从OS层就已经包装了用于虚拟化的API。然后，「虚拟机」这个APP直接调用OS提供的虚拟化API来完成模拟。

这种技术并不是再完全使用软件模拟硬件情况了，而是会「尽可能多地」直接使用硬件。例如虚拟机中要执行「内存0x10数据读取到rax寄存器中」这样的指令，通过虚拟化API，CPU会真实地执行一条从内存中读取数据放到寄存器中的指令。只不过这片内存空间并非0x10（OS会做一层映射），这个寄存器也可能不是rax。

因此，通过虚拟化API运行的虚拟机软件，会被OS认为是一种特殊的进程，对内部执行的指令仅仅做简单的映射，就直接交给硬件去执行。但所以一条指令对于CPU来说可能只是会变成几条指令而已。它的性能下降幅度是线性的，如果优化的好的话，这种下降幅度可能会非常小。

由于这种方式依赖于OS所提供的「虚拟化API」，因此这种方式被称为「虚拟化」方式。

对比软件模拟方式，虚拟化方式的优点非常明显，那就是性能显著提升。但与之相对的就都是它的劣势了，比如说它不能跨架构模拟，也不容易直接观测到硬件的状态。

静态转义方式

其实还有一种模拟方式，它介于前面介绍的两种之间，适用于跨架构模拟。更准确地来说，并不是「模拟」，而是「转义」。

举例来说，我希望在ARM架构上运行AMD64架构的程序。那么在运行之前，我先读一遍原程序，比如说当它出现「把数据加载到rax寄存器中」指令的时候，我就想，嗯……虽然我的ARM架构中没有rax寄存器，但是，我可以用其他的寄存器来代替，比如说x0。那我就把所有要给rax中写数据的指令，都翻译成给x0寄存器中写数据。

形象点来说，就是在运行一个程序之前，先「读懂」这个程序，然后翻译成当前架构的新程序，然后再去运行。

这种模拟方式，性能损耗在「模拟」和「虚拟化」之间，如果优化的好也可以获得不错的性能。但它最大的缺点就在于，对这个「翻译软件」的要求太高了！通常只适用于运行APP，而不能用于运行OS。并且「翻译软件」不仅要对翻译前后的架构指令非常清楚，还要对OS的调度方式了如指掌才行。

这种方式有一个非常典型的例子，就是苹果公司的Rosetta，也只有苹果公司能够同时对新旧指令架构和macOS都了如指掌，所以他能做出Rosetta也就不足为奇了。

在主流平台上搭建虚拟环境

了解完虚拟环境之后，试问读者，我们应当用哪一种呢？

首先，咱们只是写一些非常简单的程序，目的是学习和梳理底层的知识，所以远到不了考虑虚拟机性能折损的情况。

其次，咱们需要观测到硬件的执行情况，需要随时了解寄存器和内存当中的数据。

最后，我相信还有不少小伙伴跟我一样，用的是苹果自研芯片的Mac，这玩意本身就不是AMD64架构或者IA-32架构的机器，必须进行跨架构模拟。

那么结论就显而易见了，我们将会使用「软件模拟」方式。用到的软件是bochs，这是一款AMD64模拟器，并且支持非常强大的调试指令，非常适合我们当前的诉求。接下来就为大家介绍如何在macOS和Windows系统上配置bochs。

在macOS上配置bochs

bochs是一个AMD64模拟器，我们可以在它上面运行AMD64架构、IA-32架构、80286架构甚至是8086架构的程序。但bochs本身是跨平台的软件，因此，无论你用的是Intel芯片的Mac还是苹果自研芯片的Mac，都可以安装bochs。

虽然我们也可以从bochs官网下载源工程然后构建安装，但是环境配置以及各种依赖软件搞起来太麻烦了，所以我们选取一种最简便的方式，使用Home Brew。

Home Brew是Mac上的开源软件管理器，类似于Debian中的apt-get和RedHat中的yum。但它并没有集成在macOS中，所以我们需要先安装它。

这是Home Brew的官网，但由于众所周知的原因，它的默认资源在中国大陆是访问不到的，所以我们需要使用镜像资源。有一个国内的大神制作了一个安装Home Brew，并将资源库替换为镜像资源的一个脚本，我们可以直接使用。

打开终端，执行下列命令：

/bin/zsh -c "$(curl -fsSL https://gitee.com/cunkai/HomebrewCN/raw/master/Homebrew.sh)"

会自动下载这个脚本，然后依据提示指定一个镜像源，输入系统密码，然后安装Home Brew。

由于Home Brew所在github的DNS有过一起污染事件，所以如果当你使用时出现类似于下面的这种报错时：

Warning: No remote 'origin' in /opt/homebrew/Library/Taps/homebrew/homebrew-cask, skipping update!

这时我们可以执行下面的指令来解决：

git config --global --add safe.directory /opt/homebrew/Library/Taps/homebrew/homebrew-core
git config --global --add safe.directory /opt/homebrew/Library/Taps/homebrew/homebrew-cask
git config --global --add safe.directory /opt/homebrew/Library/Taps/homebrew/homebrew-services

当安装好Home Brew以后，就可以通过下面的指令来安装bochs：

brew install bochs

安装完毕之后，我们执行：

bochs --help

如果能顺利打印出帮助信息，那么恭喜，bochs已经安装成功！

在Windows上安装bochs

同样地，由于bochs是跨架构、跨平台软件，因此也可以在Windows上正常运行，也包括了ARM架构的Windows（例如搭载了骁龙8cx芯片的电脑，就是ARM架构的）。下面介绍在Windows上安装bochs的方法。

首先在SourceForge网站上下载bochs的安装包。

下载完毕后双击进行安装。

安装过程中的选项保持默认即可。等安装完毕后，可以在开始菜单中找到bochs，这里我们不要直接运行，而是选择下面的Folder文件夹打开。

打开后我们选择bochsdbg.exe打开。注意，在Windows中的bochs默认是不带调试功能的，必须要运行bochsdbg才可以进行调试。本文后续所有要求运行bochs的地方，对于使用Windows的读者，都要换成boch sdbg。（包括命令行、makefile中填写的也应当是bochsdbg而不是bochs，请读者一定要注意！）

打开之后，可以选择左侧Load按钮加载bochsrc配置文件运行，后续如果我们用命令行加-f参数后则无需手动加载。现在暂时也可以不用加载配置文件，直接用默认方式执行，点击右侧的Start即可看到运行效果。

之后便可以看到bochs的运行状态，左侧是用于调试的命令行，右侧是虚拟机的显示效果。

运行在8086上的第一个程序

既然硬件环境已经就绪了，那接下来，就要想办法让它运行我们的程序了。不过在此之前，我们必须要了解一下8086的主要架构，以及执行程序的方式。

为什么要了解8086

话说，我们不是要研究AMD64架构嘛，干嘛要扯这几十年前的这款胡子都老白了的这款CPU爷爷呢？其实我们在前面介绍AMD64历史的时候就提到过，IA-32也好，AMD64也好，它本质上并不是完全新的架构，而是保持着向下兼容的。

一方面来说，IA-32和AMD64都是从8086模式开始启动的，在开机的那一瞬间，你的电脑其实就是8086，然后再通过一些配置，切换到286模式、386模式、AMD64模式等等的。因此，要想在AMD64架构的裸机开始加载程序，8086的工作方式我们是避不开的。

另一方面来说，从IA-32和AMD64架构中来看，其实它还是有很浓重的8086风格，主干框架并没有大的变动，因此，了解了8086以后，自然而然也就了解了AMD64的其中一部分了。

因此，我们有必要在那些额外扩展的环节之前，先来了解一下8086。

8086体系架构

我们要了解8086体系的计算机中的几大硬件，它们是：

1. CPU

2. 内存

3. BIOS

4. 硬盘

5. 显卡

6. I/O设备

CPU是核心，我们放后面来讲，先讲讲内存、硬盘（外存）和显卡。

内存和外存

「内存」这个词感觉在近年来，已经被移动设备行业的术语给“污染”了。因为我们常说的「手机内存」其实指的并不是计算机领域术语中的「内存」。

内存，全称「内部存储器」，英文名称是「Internal Memory」，又被称为「主存」。之所以叫「内」，这也是有历史原因的。因为早年，内存并不是一个独立的硬件，而是直接将内存颗粒焊死在主板上的。

所以，以这个核心的元器件作为边界，在「里面」的存储器就叫内存，然后在这个体系外部的就叫做了「外存」。

还有一个原因在于，内存是可以直接和CPU交互的，而外存则不可以，它必须通过I/O接口，将数据先通过内存，然后才可以被CPU处理。

内存一般使用的是电路方式存储，比如说由晶体管组成的双稳态电路，通过电路的电压来表示比特位的信号。这种存储方式的优点就是读写速度会很快（毕竟是电路实现），而缺点就是，依赖持续的电力。换句话说，如果断电了，数据就会丢失，重新上电以后，里面的数据是什么是不一定的（随缘，非常的薛定谔），得重新写入以后才会可用。

所以，移动设备行业里所谓的「手机内存」，指的显然不是这个意义上的内存。这其实也是划界的问题，因为手机内存中的「内」是相对于SD卡而言的，手机里自带的存储就叫了个「内存」。但计算机专业领域中的「内存」则是体系结构的内部。（后来也是因为手机内存这个称呼已经有了，再想提及手机里真正意义上的「内存」的时候，又不得不加定语，叫了个「运行内存」。所以用计算机专业领域的概念来说，「手机内存」其实是「外存」，「手机运行内存」才是「内存」）。

我们再来说说外存。外存自然就是前面说的那一套之外的存储设备咯，像是早期的软盘。你想想啊，机器里其实只有一个软驱的，要用的时候，把软盘插到软驱里，再来读取数据。所以，这个「软盘」不就是「计算机外部」的存储设备吗？这样解释可能更容易被接受。

当然，像是硬盘、光盘、U盘等等这些，也都属于外存，虽然硬盘一般是放在机箱里面的，不会频繁插拔，但不影响它在体系结构中的角色。

外存一般用非电路方式存储，像是软盘、机械硬盘采用的就是磁性存储，通过磁头去感应某一个位置磁粉的N极或S极来识别比特位。而光盘则是采用光返性质存储，驱动器来识别某一位置的反光性来识别比特位。再像是U盘（闪存盘）、固态硬盘这些则是用浮栅层来存储，通过栅格中的电子数来识别这一位置的比特位数据。

既然是非电路方式，那么它就不怕掉电，数据将会更长久地保存。不过相对地，它的读写速度就会慢很多。

显卡

显卡，全称「显示适配器」，英文是「Graphics Adapter」。顾名思义，就是用来把信号变成画面，呈现在显示器上的硬件。

在早期，显卡的作用仅仅是用来做信号转换，在内存当中会分配一片专属区域，供显卡来使用。显卡就是不断地读取这片内存区域的数据，然后把它按照一定的协议方式，转换成显示器上的图像。当需要变换显示的东西的时候，CPU就会改写这片内存空间，这样在下一帧的时候，显卡就会按照对应的要求，变换显示的图像。

在这套体系当中，图形的处理完全是由CPU来承担的，而用于显示输出的数据，也是由内存的一部分来承担的，我们把这片用于显示画面的内存区域叫做「显存」。

然而后来，随着人们对图形质量的要求越来越高，因此就想到专门搞一个用来处理图像数据的处理器，也就是GPU，GPU也需要自己的主存，也叫做「独立显存」。

稍微多扯几句，现在我们再说「显卡」，默认都是包含了GPU的显卡，而不再是单纯的显示适配器了。随着现代显卡的性能不断发展，在一些对图形性能要求不是那么高的设备上，就考虑不使用独立显卡，而是将显卡（包括GPU）继承在其他部件上，这种显卡也被称为「集成显卡」。将GPU集成在主板上的叫做「板载显卡」，将GPU集成在CPU中的叫做「核心显卡」。不过板载显卡已经被淘汰了，目前如果你的电脑中没有独显的话，那一定是核显。注意，这种情况只是GPU集成在了「CPU这个芯片」当中，但早已不是早期那种，没有GPU的情况了。

BIOS

前面我们介绍了内存和外存的特性，不知道读者有没有这样一个疑问：既然CPU只能操作内存，而内存又是断电后数据就消掉了，外存虽然可以长久保存，但是刚开机的时候，CPU又执行不到这里来。那么，开机后CPU到底要执行哪里的指令呢？

这确实是个很严重的问题，所以说，计算机需要一个「固化」下来的启动程序，做一些硬件自检的功能，然后把一份指令从外存读到内存中，再开始执行。承担这个任务的就是BIOS，全称Basic Input/Output System，中文译作「基本输入输出系统」。一般会用一种类似于FPGA的这种ROM，随着新机器的发型，直接固化在主板上了，当然后来也出了一些可升级固件的BIOS。

硬件的问题解决了，还有另一个问题，照理说，BIOS也不属于内存，那CPU要怎么执行到BIOS中的指令呢？Intel解决这个问题的方法叫做「统一编址」，简单来说，就是把一部分内存地址，映射给内存之外的部件，比如说BIOS。对于CPU来说，它会「认为」自己是在通过内存数据线来操作内存，但其实中间的一部分链接到了BIOS中。

因此，当计算机启动的时候，它会先执行BIOS中的指令，BIOS里会把一份代码从外存加载到内存中，然后再来执行它。由于这份代码是程序员完全可控的，因此接下来的事情就由这份代码来完成了。我们把BIOS加载的第一段程序叫做「MBR(Master Boot Record)」。

另外多啰嗦几句，前面介绍的BIOS也是计算机专业领域当中「BIOS」的概念，而现代我们常说的「BIOS」，里面有丰富图形界面，多种功能（甚至可以超频的那种），其实已经不是传统的BIOS了，而是UEFI(Unified Extensible Firmware Interface)。只不过因为它承担着与BIOS类似的作用，所以大家仍然习惯称之为「BIOS」，这一点希望读者悉知。笔者在后续描述中的「BIOS」特指计算机专业领域术语的BIOS，而对于UEFI则会单独称为「UEFI」。

CPU

终于讲到了核心的部件——CPU。CPU，全称「Central Processing Unit」，中文译为「中央处理单元」或「中央处理器」，但这个中文名用得不多，一般还是直接叫它CPU。

【注：为了简化问题，帮助读者快速上手，下面的CPU框架结构是简化版的，想知道完整、规范地8086CPU内部结构的读者可以在网上自行搜索。】

CPU有三个重要的部分：运算器（CU, Calculation Unit）、执行器（EU, Execution Unit）和寄存器（Register）。其他类似于缓存（Cache）之类的东西先不讲，因为我们暂时感知不到。

运算器，简单来说就是CPU的原子功能，比如说能做加减法运算之类的。它能做哪些运算取决于它的指令集。

执行器，由它来负责，当前要使用运算器的哪个功能，执行什么样的指令。

寄存器，则是CPU内部用来存放数据的地方，对于软件层面来说，我们主要操作的就是寄存器，因为其他部件都是按照自己的规则去执行的，我们只需要控制寄存器，就可以完成我们希望CPU执行的指令。

照理说，这个时候我应该介绍一下8086的14个寄存器的，但是笔者觉得，前面的铺垫有点太多了，读者可能已经迫不及待想写点程序运行运行了，所以，这些内容，等用到的时候再说吧~

让机器执行起来

啰里八嗦了那么多，总算是可以开始运行程序了！现在就请打开bochs，我们用debug模式来裸机运行一下，看看会发生什么。

对于Windows系统来说，直接运行bochsdbg.exe就可以了，暂时还不用加载配置文件，对于macOS来说，需要指定一下显示的配置。我们找一个工作路径（以后项目的代码都可以放到这个里面），例如~/code，再里面创建一个文件名为bochsrc，这是虚拟机的配置文件，然后编辑里面的内容如下：

display_library: sdl2

主要是因为，bochs的显示输出，默认用的并不是sdl2，这在macOS上是显示不出来的，所以我们需要指定到这个库。

如果你的机器上还没有安装，那么可以用brew install sdl2来安装。

保存完毕以后，在工作路径上通过这个配置文件来运行虚拟机：

bochs -qf bochsrc

即可启动虚拟机，命令行会保持在调试状态：

这时候我们可以输入c，回车，表示继续执行，不出意外的话，会弹出虚拟机的显示窗口：

可以看到，BIOS中的指令已经运行完毕了，但是由于它没有搜索到外存，所以最终停在了这里。

很好！接下来，我们只需要把指令给它加载到外存里就OK了吧！你可以想象，现在我们把程序写好了，放到一张软盘中，然后把软盘插到软驱里，再重启电脑，这样的话，BIOS就应当能检测到软盘中的内容，并自动加载到内存里了。

不过对于虚拟机来说，上面这套动作得靠配置文件来完成。打开我们刚才的bochsrc（如果你用Windows，之前没有建立的话，现在就该建立了！），加入以下内容（注意，macOS的话不可以删除sdl2的配置项哈！）：

boot: floppy ## 设置软盘启动
floppy_bootsig_check: disabled=0 ## 打开自检
floppya: type=1_44, 1_44="a.img", status=inserted, write_protected=0 ## 使用1.44MB的3.5英寸软盘，取镜像为a.img，开机默认已插入软驱，不开启写保护

这样再开机的时候，就可以读取软盘镜像了。那么接下来，我们只需要把要执行的指令，写成这个名为a.img的软盘镜像里就大功告成了。

那怎么创建软盘镜像呢？需要用到二进制编辑器。二进制编辑器很多，macOS上推荐使用Hex Fiend，可以直接在App Store中下载到：

对于Windows来说，可以使用ultra edit，请读者自行安装，如果你实在找不到合适的也无妨，因为我们不可能一直用编辑二进制的方式来写程序，下一章开始我们就改用其他方式了，可以看一下笔者的操作，领悟精神即可。

为了能看到执行效果，我们就把一个数写到一个寄存器里，然后通过bochs的调试指令来看看寄存器里的值，如果生效了，那么就证明我们的MBR已经加载并执行成功了。比如说，我们给ax寄存器中放一个数值6。关于ax寄存器是什么后面章节会讲，反正当前只要知道它是一个8086中的寄存器就好了。

那么，把6写入ax寄存器的命令是什么？这个可以通过查Intel手册知道，应当是：

B8 06 00

B8是指令码，表示给ax寄存器中存入数据。后面的06 00是操作数，因为ax是一个十六位寄存器，所以给它应该要放一个16位的操作数。那为什么是06 00而不是00 06呢？这是因为，8086体系使用小端序，也就是低字节放数的低位。但是在书写数据的时候，我们又习惯从低到高来写，所以就变成了06 00，看上去可能有点不适应，但是还是需要大家适应一下~

那是不是这样就OK了？并不是！虽然BIOS会自动加载数据，但是，BIOS有一个约定，它会检测这段数据的最后两个字节是否是55 AA，是才会认为这是一段合法的MBR，才会加载。至于为啥是这俩魔数……emmm……估计没人晓得~

由于BIOS只会加载512字节（也就是对于软盘来说的第一个扇区），又对后两个字节有标志检测，所以，MBR应当是不多不少正好512字节，并且要在软盘的第一个扇区，这样才能正确被加载。所以，我们补全到512字节，并且把后两个字节设置为55 AA，如下图：

保存成a.img，就可以使用了！

然后我们再执行bochs -qf bochsrc，（Windows可以先打开bochsdbg.exe，然后选择Load按钮加载bochsrc），注意，现在还不能无脑按c，因为我们的MBR里只有一条指令，黑着往下执行的话会观察不到。所以，我们需要打一个断点，让bochs执行到这个位置的时候停一下。

那么另一个问题来了，断点应该打在哪？这取决于，BIOS会把MBR加载到内存的哪一个位置。这里的约定是0x7c00的位置（同样，至于为什么是这个地址估计也没人知道了~总之是作为一种约定），那么我们就要在0x7c00的位置打断点，所以执行下面的调试指令：

pb 0x7c00

然后再按c，这样执行到这一位置的时候就会停下来：

停下来的时候，调试页面会显示这样的情况：

注意最下面一行，中括号里的就是当先执行指令的内存地址，也就是0x7c00，证明这个断点位置是对的，在继续执行之前，我们先来看一下当前ax寄存器的情况，输入r指令，回车可以看到通用寄存器的状态：

这里需要解释一下，由于bochs是AMD64架构的模拟器，所以这里的寄存器都是按64位显示的，它们的扩展情况将会在后续章节来介绍，目前我们只需要知道，要看ax寄存器的值，其实就是看rax的最后16位（也就是最后4位十六进制位），如上图红框里的，就是ax的值，现在是aa55。

然后，我们往下执行一条指令就好了，s命令是单条执行，只会向下执行一句指令。所以我们输入s，回车，再输入r来打印一下寄存器的情况：

OK，ax寄存器真的被改写成0006了，说明我们的指令已经成功运行了！

改用汇编语言

不知道会不会有读者跟笔者一样，第一次在裸机上运行一句指令以后会无比兴奋，仿佛打开了新世界的大门，恨不得现在就着手写一片江山上去！但是先别急！因为这种用二进制机器码直接编程的难度也忒大了。我得去记住所有的指令码和指令格式，万一错一个数字那就整个都不对了，况且它可读性也很差呀！谁能一眼看出来B80600是什么鬼？

当然了，要是退回到8086的年代，可能程序员真的是这么干的，但是现在，我们有了更方便的工具，这种仿古式的编程方法，稍微体验一下就OK啦。回到上面的指令，既然B80600是「给ax寄存器写入0006这个数」的含义，那么，能否有一个翻译器，把我的这种表意，转换成机器指令呢？

当然有！这就是汇编器，它可以把汇编语言转换成机器码。比如说：

mov ax, 0x06

表明给ax寄存器中传入0x06这个十六进制数，然后交由汇编器将其转换为B80600。这样的语言就叫做汇编语言，汇编语言看起来是比机器码要友好得多了吧？

不过成熟的汇编器除了做指令翻译以外，可能还会有一些更方便的功能，类似于编译器的预处理，做一些静态的数值转换之类的工作，但是不同的汇编器支持的汇编语言也会略有不同，业界比较常用的有两个：nasm和gas。

gas也就是GNU的asmmbly(汇编语言)，之所以比较常用，是因为gcc只能将C代码编译成gas格式，后续本篇的示例中，也会使用gcc编译器，编译后的就是gas格式。

nasm是一个比较被普遍认可的汇编器，全称Netwide Assembler。它的优点在于语法简洁易用。在本篇的示例中，对于需要直接手动开发的汇编语言部分，将会使用nasm。

接下来就来介绍如何安装nasm。

安装nasm汇编器

首先，登录nasm官网，点击当前最新的稳定版本（读者看到的时候有可能已经是高于截图的版本了，不过没关系，选择最新的稳定版即可）。

接下来，根据自己所使用的OS选择对应的文件夹，如果你用macOS，就选macosx，如果你用Windows，就选win64。注意，这里只区分操作系统，不区分你的实际硬件架构，即便你使用苹果自研芯片的Mac，或者搭载骁龙芯片的Windows，这里的软件也同样适用。

接下来Windows和macOS的步骤会有不同，笔者分别来介绍。

在Windows上安装nasm

由于Windows版本中提供了安装包，因此，比较方法的做法是下载这个installer，然后通过自带的安装程序安装到电脑中。当然，如果你对搭建环境比较熟的话，也可以直接下载下面的zip，解压缩后得到的直接是nasm程序本身。

如果你选择了安装器的版本，那么直接运行安装器，安装选项全部默认即可。

不过这里要注意一下安装路径，默认情况是C:\Program Files\NASM，Windows默认这个带空格的路径确实是一个饱含诟病的历史遗留问题，不过对于nasm来说影响不大，安装在默认路径下也是OK的，只不过我们要记住这个路径，保证能找到它。如果你没有用安装器，而是直接下载的zip然后解压缩的话，也请把整个文件夹放在一个合适的路径下，保证自己找得到。

等安装完毕后，nasm就已经躺在刚才的安装路径下了。但是每次都指定绝对路径去运行着实麻烦了一些，也不方便我们进行项目的迁移，因此，我们还要把它配置到环境变量里。按Win+R组合键，弹出「运行」窗口，输入sysdm.cpl，回车，即可打开系统属性设置。

在「系统属性」设置中，选择「高级」标签页，再点击下面的「环境变量」按钮。

接着，在环境变量中找到用户变量里的Path，这个变量决定了，如果你不指定绝对路径，而是直接输入一个命令的时候，系统会去哪些路径中找程序。我们希望的效果是，当我们想运行nasm的时候，直接输「nasm」就好了，而不是每次都要输「C:\ProgramFiles\NASM\nasm」，因此，就要把这个路径也配置到环境变量中。

选择Path后点击「编辑」，或者直接双击Path也可以，就可以编辑环境变量了。

在「编辑环境变量」的窗口中点击「新建」，然后把nams的安装路径写进去。注意，要写全路径，并且只需要写到NASM这层路径就好了，确保这个路径下有nasm.exe这个可执行程序。

环境变量设置好以后，我们就可以尝试运行一下nasm了。按Win+R打开「运行」，输入cmd，回车，即可调出控制台。

在控制台中输入nasm -v，如果能够看到打印出的nasm版本号信息，就说明我们已经安装配置完毕了！

在macOS上安装nasm

由于macOS版本的nasm没有安装包，所以我们只能下载源程序的压缩包。

解压缩之后，就已经是可以执行的程序了，不过一般情况下浏览器默认会把文件下到「下载」这个路径中，这里自然不合适放一个经常要用到的程序，所以请手动把它挪到一个妥当的位置。

我这里选择的是用户根路径，也就是~/。文件夹它默认带版本号，你可以改个名字，也可以不管它，只要确保里面有nasm这个可执行程序就好了。我这里的路径是~/nasm-2.16.01。

同样地，为了让我们使用时可以只输入nasm，而不是~/nasm-2.16.01/nasm，我们还需要把这个路径放入环境变量。

macOS最早默认使用的bash，后来换成了zsh，因为这个切换已经很久了，所以笔者介绍zsh的情况，如果你用的是其他版本的shell，就请自行解决环境变量的配置问题。

执行下面的命令，编辑zsh的配置文件：

vim ~/.zprofile

注意，即便你当前没有.zprofile这个文件也没关系，上面的命令执行会以新建文件的方式。

然后再编辑界面按「i」键，进入编辑模式，此时左下角会显示「INSERT」，表示在编辑模式。如果里面已经有一些配置了，无视就好，我们在文件最后加上：

PATH=$PATH:/Users/xxx/nasm-2.16.01

注意，由于我是放在~/里的，但这里要写全路径，所以你需要看一下全路径是什么，用波浪线有时可能会失效。

那一句的意思就是，在PATH这个变量后面，加上一个nasm的路径，所以这里要填写你的nasm所在路径。

由于.zprofile会在每次运行终端的时候自动执行，因此我们把命令写在这个文件里就不用每次手动配置了，但由于现在还没生效，所以你还需要执行一句：

source ~/.zprofile

或者干脆把终端关了，重新开一下，就生效了。

然后我们在控制台输入

nasm -v

如果能够看到版本信息，那么说明nasm已经安装配置成功。

编写MBR

上一章我们已经成功地在8086上运行了指令，同时也介绍了nasm汇编语言。那么接下来这一章，我们就来看看如何写BIOS自检后的第一道程序——MBR。

8086的14个寄存器

既然咱们已经决定要在8086上运行程序了，那么自然，现在是逃不过要了解一下8086 CPU的一些详细情况了。

值得注意的是，8086并不是只有14个寄存器，只不过这14个寄存器是对于程序来说直接打交道的。CPU内部自然还有一些用于体系自身运行的，对外不透明的寄存器，不过这些我们就不需要了解了（其实很多更详细的那些也属于Intel的商业机密，咱也没法了解）。

我先把要关注的这14个寄存器的名称列出来，然后再来解释：

需要强调一点，除了IP和FLAG以外，上面寄存器的名称所描述的本意，只是这个寄存器「通常」或「默认」用做的事情，并不是说该寄存器只可以用做这一种情况。寄存器是很珍贵的资源，因此实际操作的使用用法是灵活多样的，所以笔者并不想拿这些寄存器名称本身的含义去大书特书。大家其实需要知道，我们要关注这14个寄存器，记住它们的符号（因为汇编语言里要用到）就好了，在一些必须指定寄存器的场景，我们再单独去记忆就好了。

另外，上面这些寄存器都是16位的，这也就意味着，8086每个节拍处理的数据都是16位的，在8086这块CPU里，数据处理和传递的基本单位就是16bit，我们也称「8086的字长为16位」，也称「8086是16位CPU」。

8086的寻址方式

前面我们说，8086是16位CPU，这个仅仅是指它的字长，但并不对应它的最大寻址空间。一个CPU的最大寻址空间并不取决于它的字长，而是取决于它对外的地址总线的个数。

如果你玩过数字逻辑器件的话，应该知道有一种器件叫做「译码器」，例如下图展示的是74138，三线-八线译码器：

它的输入端（A~0~、A~1~、A~2~）就是地址总线，我们可以想象，这三根线接到了CPU上。后面的输出端（Y~0~~Y~7~）就是数据线，我们可以想象，这8跟线接到了内存的存储单元上。

当A~0~A~1~A~2~输入为010时，表示需要控制第2号地址，那么Y~2~会输出1。同理，当A~0~A~1~A~2~输入为101时，表示需要控制52号地址，那么Y~5~会输出1。依次类推

在上面所述的这种结构中，我们认为CPU有3根地址总线，那么寻址空间就是23=8，地址从000到111。

而在计算机体系中，存储单元一般不会按二进制位（bit）来编址，而是按照字节（Byte），也就是说，每8个bits为一组，编一个地址。那么地址总线是3的CPU，就可以访问8字节的内存空间。

而对于8086来说，它含有20根地址总线（注意，并不是16根！），那么，8086的寻址空间就是：

所以，8086最多支持1MB的内存空间，地址从20个0到20个1，不过用二进制表示会比较冗长，所以我们通常用十六进制表示内存地址，也就是0x00000到0xfffff。

前面我们提到过，类似于BIOS这样的部件，随不属于内存，但使用了统一编址的方式，因此，BIOS里的数据仍然会被包含在这1MB当中，因此实际可用的物理内存，是不足1MB的，但这件事对于CPU来说是无感知的，它会按照同样的方式，通过地址总线来操作外部硬件，无论它是内存还是BIOS。也正是由于这种编址方式，就是为了让CPU不去区分实质硬件，因此，对于统一编址的硬件来说，我们仍然称其地址为「内存地址」，虽然它压根不是内存。

那么另一个很严重的问题就出现了，8086是16位CPU，它的寄存器也都是16位的，但却有20根地址总线，那我们怎么表示一个内存地址呢？8086采用的方式是，用两个16位寄存器来拼成一个20位内存地址，示意图如下：

也就是说，把其中一个寄存器作为「段寄存器」，它的0~15地址线接给全加器的4~19位，作为第一个加数。再把另一个寄存器作为「地址寄存器」，它的0~15地址线接给全加器的0~15位，作为另一个加数。

上面的和作为输出地址。（当然，实际8086内部逻辑器件比这复杂的多，笔者仅仅是做一个示意）

那么用公式来表示就是：

其中s表示段寄存器中的值，d表示地址寄存器中的值。左移4位是指二进制位，效果相当于十进制 中的X16，相当于十六进制中的末尾补0。

举个简单的例子，如果s是0xf055，d是0xa003那么地址怎么来算呢？首先给s末尾补0（因为是十六进制的），然后跟d相加即可，也就是0xf0550 + 0xa003，等于0xfa553。

在8086中，可以用做段寄存器的有cs、ds、es和ss，而可以用做地址寄存器的有bx、di、si、bp和sp。如果你要问，为什么其他寄存器不可以呢？那也很好解释，因为只有这几个寄存器，有连接到译码器之前那个全加器上的电路，其他寄存器没有这个电路，自然也就不能直接用做此目的。

由于一个二十位的内存地址需要两个十六位操作数来表示，在汇编语言中，会采用冒号隔开，也就是s:d的方式。例如0xf055:0xa003表示了0xfa553这个地址。当然，我们也发现了，这种方式下，地址表示是不唯一的，例如0xfa00:0x0553也同样表示0xfa553这个地址。所以由于这个特性也会导致一些有趣的问题，我们将会在后面的章节来详细解释。

8086启动时发生的事情

前面我们已经体验过一次8086的启动了，不过那会笔者为了让大家能先快速有一个感性的认知，就没有介绍过多的内容。在继续编写MBR之前，我们还是有必要详细理解一下8086启动过程。

CPU在启动上电的瞬间之后，它只会机械性地做一件事，就是每个时钟周期，把指令读进来，执行，然后再读下一条指令，执行……如此循环往复。

那么，究竟要从哪个位置读指令呢？这是IP寄存器决定的，IP寄存器指向哪里，CPU就会读取哪里的指令。等指令结束后，IP会自动增加指令长度的数值，这样CPU就可以执行下一条指令了。

由于8086指令集属于CISC指令集（Complex Instruction Set Computer），它的指令长度是不同的，因此，每次执行指令后，IP的偏移数也不尽相同，这取决于刚才执行的那条指令的长度。不过我们不需要过多担心，指令长度这件事CPU会自己处理好。

这里还有一个问题，IP也是一个16位寄存器，它自己没法完整表示内存地址，还需要一个栈寄存器跟它组团。那么这个栈寄存器就是CS。

换句话说，CPU永远都会执行CS:IP处的指令，只要设置好这两个寄存器，CPU就能正常执行指令。

在8086上电的时候，CS寄存器被初始化为0xf000，而IP寄存器被初始化为0xfff0，所以自然，CPU执行的第一条执行在0xffff0这个位置。为了保证机器上电自检，以及MBR加载的事项能够顺利完成，那么这个位置已经会被映射到BIOS当中，这样保证机器上电后，可以自然而然地执行BIOS中的内容。

在8086中，BIOS会被映射到0xf0000到0xfffff的位置，这64KB的地址由BIOS来控制。

BIOS内部会具体执行哪些指令我们不得而知（虽然通过bochs确实能看到，但它用的BIOS也只是一个开源版本的固件罢了，真机上的BIOS内容并不开源，我们也没法知道），但BIOS一定会做一些约定好的事情，方便下一步的OS内核可以正常加载。比如说，BIOS会检测外存、I/O设备是否正常，并且如果发现了MBR（也就是外存中，第一个扇区的数据，以0xaa55结尾的），就会把这一扇区（512字节）的内容，加载到0x7c00的位置，然后把CS:IP设置为0x0000:0x7c00，保证下一条指令就是0x7c00处的指令。

回想一下前面章节中，我们给软盘的第一个扇区的第一行写了一个B80600，然后在0x7c00出打了断点，就可以看到ax寄存器确实变成了6，这就是因为，这一扇区的数据，被BIOS加载到了0x7c00的地方，然后把CS:IP设置为0x0000:0x7c00，这样，B80600就成了BIOS之后执行的首条指令了。

继续编写MBR

有了这些理论基础，我们就可以继续来编写MBR了。相信大家首先想做的，应该就是在屏幕上输出点东西吧！接下来我们就按照国际惯例，在屏幕上输出Hello World!。

在已经安装好nasm的前提下，我们在项目路径下新建一个文件，叫做mbr.nas，然后输入下面内容：

mov ax, 0xb800
mov ds, ax
mov [0x0000], byte 'H'
hlt
times 510-($-$$) db 0
dw 0xaa55

稍后我们再来解释代码，咱们现来看看效果。

首先，要把汇编代码转换为机器码，输入下面指令，通过nasm来进行汇编：

nasm mbr.nas -o mbr.bin

得到mbr.bin文件，然后将其重命名为a.img（可以直接用图形界面操作，也可以执行命令cp mbr.bin a.img），再启动bochs。（注意，这里复用了前面章节的工程路径，因此需要前面bochrc的配置文件，详情可以查看前面章节）

bochs -qf bochsrc

然后按c命令，即可看到输出结果。如果你也跟我一开始一样，盯着下面的Booting from Floppy...没反应，然后认为程序没有生效的话，那请你往最开头来看：

可以看到，这里原本应该是「Bochs」，但是第一个字母被我们改成了「H」，所以输出是成功了。这主要是因为BIOS在屏幕上输出了一些东西，然后并没有清屏，导致我们自己的输出被「淹没」在里面了。不过要清屏需要额外解释一些其他东西，为了循序渐进，所以咱们暂时先忍忍，知道要在这些乱七八糟的信息里去寻找我们的输出就可以了。

接下来我们聚焦到这几行汇编语句上，解释一下我们都做了什么。

mov ax, 0xb800

这一句，是给ax寄存器中赋值0xb800，mov指令其实更准确应该是「copy」，它会把右边的操作数赋值给左边，移动之后后面的操作数不会消失。后面一句

mov ds, ax

则是把ax的值赋值给ds寄存器，这样ds寄存器中也是0xb800了。

相信读者在这里一定会有疑惑，为什么我不能直接mov ds, 0xb800呢？何苦劳烦ax这样节外生枝？这就是我们编写汇编语言的时候必须要考虑的问题。汇编语言仅仅是把二进制的机器码，换了一种更加接近人类语言的方式展示而已，但它本质没有变，汇编器会把它转换成对应的机器码。所以，我们写的每一条汇编指令，都应该要有对应的机器指令才对，也就是机器能够支持的指令。而8086中的段寄存器并不可以直接通过立即数来赋值，因为8086体系根本没有这样的机器指令。

所以，在编写汇编语言的时候，我们要以CPU硬件的思维来思考，书写「指令」本身，而不是高层的抽象语义。用前面的例子来说，我们要达成「把0xb800这个数赋值给ds寄存器」的这个需求，要使用「mov ax, 0xb800和mov ds, ax」这两条指令来完成。当然，你换成bx、cx或者dx做中间量也是OK的，因为这几个寄存器都可以通过立即数来赋值。

这两行代码的含义已经清楚了，我们来解释一下目的。在前面的章节中笔者曾经介绍过「显存」的概念，显卡会按照每个刷新周期，读取某一片内存空间，然后按照一定的规则解析，并输出给显示器，这片内存空间就是「显存」。

在8086机器初始化时，会默认使用标准VGA协议，并且是80×25×16的文字模式。也就是说，在这种模式下，显示器可以显示25行，每行80个字符（ASCII字符），并且支持最多16种颜色。在这种模式下，对应的显存是0xb8000~0xb8f9f，一共4000字节的位置。每两字节对应一个字符显示位，低字节表示ASCII码，高字节表示颜色信息。

因此，0xb8000这个内存地址，对应的就是屏幕上第一行第一个字符对应的ASCII码，0xb8001对应的是它的颜色信息。同理，0xb8002对应第一行第二个字符的ASCII，0xb8003对应它的颜色……0xb80a0对应第二行第一个字符的ASCII，0xb80a1对应它的颜色……0xb8f9e对应第25行（最后一行）第80个字符（最后一个字符）的ASCII，0xb8f9f对应它的颜色。通过给显存中写入数据，就可以控制屏幕上的字符。

那么，颜色信息是怎样的呢？颜色信息的字节中，0~2位表示文字颜色的RGB，第3位表示是否高亮，4~6位表示背景色RGB，第7位表示是否闪烁。我们可以把颜色总结如下表：

配合上I位，前景色可以有16种颜色，分别是：

而背景色没有高亮位，因此只支持8种：

最后配合K位，表示是否闪烁。

这里建议大家想看那种颜色，可以做一些尝试，还可以配合一下位置来编写代码，比如说，我想在屏幕第一排第一个、第二排第二个、第三排第三个分别显示ABC，然后随便用上点颜色看看效果，就可以写成：

mov ax, 0xb800
mov ds, ax
mov [0x0000], byte 'A'
mov [0x0001], byte 0xF0
mov [0x00A2], byte 'B'
mov [0x00A3], byte 0x46
mov [0x0144], byte 'C'
mov [0x0145], byte 0x32

hlt

times 510-($-$$) db 0
dw 0xaa55

效果如下（注意，A是闪烁的，但截图显示不出来）：

我们继续来解释代码，中括号表示取内存地址，所以这里的[0x0000]表示取地址是0x0000的内存地址，在mov指令下，表示给内存写入数据。我们知道，一个完整的内存地址应该有两部分，而对于立即数寻址的方式来说，默认段寄存器是ds，也就是说，[0x0000]其实等价于[ds:0x0000]，这就是刚才我们之所以要先设置ds的原因。由于ds已经被设置为0xb800，因此[0x0000]就是[0xb800:0x0000]，自然也就表示了0xb8000的地址，也就是显存的第一个字节。

那为什么要写那个byte呢？当我们操作寄存器的时候，会按照寄存器的大小来识别操作数，比如说mov ax, 0x5，由于ax是16位的，因此，后面的0x5会自动补全为0x0005。但是，当我们操作内存的时候，就需要手动指定操作数的长度了。长度描述符有byte、word、dword和qword，分别表示1字节、2字节、4字节和8字节。注意，如果使用word或以上的形式，将会按照小端序来处理，例如mov [0], word 0xabcd则会在ds:0的位置写入0xcd，然后在ds:1的位置写入0xab。再多啰嗦一句，如果不写0x前缀或h后缀的话，将会按照十进制类解读。

综合一下，前三行代码：

mov ax, 0xb800
mov ds, ax
mov [0x0000], byte 'H'

表示的就是，在屏幕的最左上角的位置显示一个字母'H'，由于之前BIOS已经写入部分显存数据了，所以它的颜色会保持不变，当然，我们可以通过类似于mov [0x0001], byte 0x0f的语句把它的颜色变成白色。

大家可以尝试用这种方法在屏幕上输出各种各样的内容。

后面有一句

hlt

这是挂起指令，可以让CPU暂时先不要向下继续执行，直到响应中断（关于中断会在后续章节介绍）。这里写这行语句的目的在于，每次都给bochs打断点有点麻烦，而使用hlt指令就可以让CPU悬停再此处，方便我们观察输出，所以就不用打断点了。

最后一行的dw 0xaa55，这里的dw是伪指令，也就是说，它并不会翻译成机器指令，而是用于指导编译器做预处理用的，有点类似与C/C++中以#开头的语句。dw的意思就是按字面写2个字节，内容是后面的数，也就是0xaa55。前面我们说过，BIOS只有在检测第一个扇区的后两个字节是0x55和0xaa的时候，才认为是合法MBR，并加载。所以，这行语句就是干这件事的，我们可以看到汇编之后的二进制中，最后2个字符被写入成功了：

dw表示写2个字节，对应的还有db写1个字节，dd写4个字节，dw写8个字节，注意，都是小端序。所以上面的伪指令其实还可以改成db 0x55 0xaa，效果是一样的。

最后一个问题就是，0xaa55是这512字节的最后两个字节，但我们刚才也没写几句指令，这中间的部分咋整？可以补0，但得补多少0呢？这主要取决于，刚才我们写的所有指令占了多少字节。注意，汇编语言中的行号是没有执行层的含义的，因为对于CISC指令集来说，每条指令的长度都可能不一样，所以行数跟指令的字节数没有直接关系。

所以，计算指令长度的这件事也就交给汇编器了，times也是伪指令，表示后面紧跟的指令执行几次，比如说times 5 db 0就等价于db 0 0 0 0 0。而$和$$符号则是指令的偏移数，$表示当前位置的偏移数，$$表示首行的偏移数。注意，之所以首行也会有偏移数，这是有一种情况，就是当前文件的第一条指令并不一定加载到内存0的位置，虽然在本代码中$$就是0，但我们还是用$-$$来计算一下偏移量，而不直接用$。

所以，这一行的意义就很明确了，times 510-($-$$) db 0，就是从当前位置，一直补到第510字节，都补0。然后最后两个字节留给0x55和0xaa。

软中断

由于本系列文章并不是专业的8086汇编教程 ，因此不会过分纠结汇编语言的指令和编程技巧。但距离我们的目标——运行一个C++程序还有挺远的距离，就比如，BIOS只负责加载512字节的MBR，多的部分怎么办？另外还有一个非常令人困扰的问题，就是如何清屏？

当然了，显存的位置都已经清楚了，把他们全搞成空格符，自然也就相当于清屏了。只不过这种功能还不需要我们自己来写，用软中断的方式就可以解决。

要解决这些问题，首先我们需要了解一下软中断，在此之前，需要先了解一下中断。

中断机制

简单来说，中断机制解决的就是CPU和外部设备速度严重不匹配的问题。比如说，当你在键盘上按下一个按钮的时候，CPU是需要响应的，但是，CPU怎么知道你按没按下键盘呢？

一种方式就是主动监听，用大白话来解释就是，CPU要隔三差五去看一下，键盘有没有被按下，如果有，就响应，如果没有，就回来继续干活。

但这种主动监听的方式有一个非常严重的问题，就是速率不匹配。当代CPU的主频基本都是3GHz数量级，即便是最早的8086，主频也有4.77MHz。再想想你敲击键盘的速度，根据吉尼斯官方记录，世界冠军的打字速度也不过是每分钟807个字符，这个换算下来也就是13Hz左右。换句话说，你敲一下键盘，CPU已经干了50万次以上的工作了，由于这种速率不匹配，因此选用主动监听方式对资源是一种极大的浪费。

因此，人们就想了一个办法，设计了一个中断控制器，用来监听外部事项（例如键盘敲击信号），当需要CPU响应的时候，中断控制器再去「通知」CPU，“你把手上的活先停一下，有个事情要处理。”这种机制就叫中断机制。

对于中断信号，CPU要做出对应的处理，那么自然就要有一些用于处理中断的指令，当CPU收到对应的中断时，就去执行对应的指令即可。这种机制有点像Qt中的signal-slot机制，也有点类似于Vue中的@click绑定触发事件。总之，都是将一个事件（或者信号）跟一个函数相绑定，当收到事件信号时，执行对应的函数。

不过既然中断的处理过程就相当于一个函数的话，它自然也可以当做一个普通的函数直接调用，这种方式就被称为「软中断」。换句话说，软中断其实跟原本的中断机制没什么关系，它只不过利用了中断号，直接去执行了对应的中断响应函数罢了。

所以，软中断本质上就是函数调用。

通过BIOS中断来清屏

在BIOS内部，会实现存一些中断响应的流程指令，所以我们可以通过软中断调用方式，去执行BIOS所提供的一些功能。这些BIOS提供的功能也称为「BIOS中断」。

BIOS中断可以提供很多功能，详细的情况只能去查BIOS手册了，这里笔者只介绍咱们用得上的。首先，就来解决清屏的问题。

中断的调用需要配合固定的寄存器传入参数，之前我们说过，默认情况下显卡使用的是文字模式，那么只要重新再进入一次文字模式就可以自动清屏功能，需要al传入0x03，ah传入0x0，然后使用0x10号中断即可实现清屏（如果是其他显示模式，则会切换至文字模式）。

等等，al和ah寄存器是哪冒出来的？其实是这样的，对于ax、bx、cx和dx这4个寄存器来说，可以拆成高8位和低8位两个8位寄存器来使用。al就是ax的低8位，bh就是bx的高8位，以此类推。

所以，al=0x03，ah=0x0，效果跟ax=0x0003是一样的。

我们修改一下MBR的代码，首先清屏，然后再打印Hello,World!来看看效果：

mov al, 0x03
mov ah, 0x00
; 也可以写作 mov ax, 0x0003
int 0x10 ; 调用0x10号BIOS中断，清屏

mov ax, 0xb800
mov ds, ax
mov [0x0000], byte 'H'
mov [0x0001], byte 0x0f ; 黑底白字
mov [0x0002], byte 'e'
mov [0x0003], byte 0x0f
mov [0x0004], byte 'l'
mov [0x0005], byte 0x0f
mov [0x0006], byte 'l'
mov [0x0007], byte 0x0f
mov [0x0008], byte 'o'
mov [0x0009], byte 0x0f
mov [0x000a], byte ','
mov [0x000b], byte 0x0f
mov [0x000c], byte 'W'
mov [0x000d], byte 0x70 ; 浅灰底黑字
mov [0x000e], byte 'o'
mov [0x000f], byte 0x70 
mov [0x0010], byte 'r'
mov [0x0011], byte 0x70 
mov [0x0012], byte 'd'
mov [0x0013], byte 0x70 
mov [0x0014], byte '!'
mov [0x0015], byte 0x70 
hlt

times 510-($-$$) db 0
dw 0xaa55

效果如下：

这样看上去是不是顺眼多了？

跳转

前面我们介绍过，8086CPU总是在执行CS:IP所对应的内存位置的指令，一般情况下，会按照顺序一条一条执行。除非一种特殊情况——跳转指令。

所谓「跳转」，顾名思义，就是不要再继续向下执行，而是跳到某一个位置开始执行。因此，跳转指令就是要改变CS:IP的指向。

跳转指令主要分为两种，分别是「近跳」和「远跳」。不过笔者认为，这两个名字也起得不是特别恰当，其实他们跟远近并没有直接关系。

近跳

所谓「近跳」，我们可以理解为CS不变，IP做一个偏移，它的操作数是一个偏移量，比如说-3就表示向前跳转3字节、5就表示向后偏移5字节。

然而在汇编语言里，我们也不好手动去计算偏移量，因此这种时候就需要用到强大的汇编器预处理功能——标签。我们来看一个例子：

L1: 
mov ax, 1
jmp L2
mov bx, 2
L2:
mov cx, 8_

其中的L1:和L2:就是标签，它也是伪指令，并不会生成对应的机器码，而是会影响汇编器的预处理。标签名可以随便起，只要不跟汇编关键字冲突即可，后面的冒号也可以省略。

上面例程中的近跳指令是：

jmp L2

预处理时，汇编器会根据L2标签到当前位置（跳转指令的位置）之前的偏移量来给近跳指令添加操作数。以上面例程来说，实际的操作数正好是mov bx, 2这条指令的长度，也就是3，那么jmp L2就相当于jmp +3。

当CPU执行到近跳指令时，则会将IP寄存器与近跳指令的操作数相加，然后去执行对应位置的指令，进而达到跳转的目的。

远跳

所谓「远跳」，其实是给CS和IP都给一个绝对值，它的操作数是一个绝对的内存地址，而不是偏移量。例如：

jmp 0x0820:0x0000

这条指令执行完后，CS会赋值为0x0820，IP会赋值为0x0000，接着就会执行0x08200位置的指令。

这里需要强调的是，汇编语言指导的是机器指令，它不具备高等语义，因此，汇编器不会去检查0x08200这个地址在不在你当前操作的源文件里，也不会去管那个位置到底会不会加载合法的指令，这一切都应该由程序员自行负责。

当然，使用远跳指令时也可以使用标签，只不过此时的标签会使用「相对于文件头」的偏移量。比如说：

mov ax, 0
mov bx, 1
L1:
mov cx, 2
jmp 0x0000:L1

上面例程中jmp 0x0000:L1就是远跳指令，这时的L1就会解析为这个标签相对于文件头的偏移量，实际上也就是mov ax, 0和mov bx, 1的指令长度和，也就是6。那么这条指令其实应该是jmp 0x0000:0x0006。

这里再次强调重点：近跳指令不改变CS，操作数是偏移量；远跳指令会改变CS，操作数是绝对数。这一点在8086模式下可能看上去没那么重要，但当后面我们切换到286模式时，这一点会非常重要，所以请读者一定要记住。

多加载几个扇区

到目前为止，我们的程序都挤在软盘的第一个扇区里，指望BIOS自动加载。不过显然这区区512字节的空间很容易捉襟见肘，那么如何把软盘中的其他扇区内容也加载到内存中呢？在8086模式下，BIOS中断可以替我们搞定。

; 加载一个扇区到0x08000的位置
mov ax, 0x0800
mov es, ax
mov bx, 0 ; 软盘中的内容会加载到es:bx的位置
mov ah, 2 ; ah=2, 使用读盘功能
mov al, 2 ; ah表示需要读取连续的几个扇区（读2个就是1KB的大小）
mov ch, 0 ; ch表示第几柱面
mov dh, 0 ; dh表示第几磁头
mov cl, 2 ; cl表示第几扇区
mov dl, 0 ; dl表示驱动器号，软盘会在0x00~0x7F，硬盘会在0x80~0xFF
int 0x13  ; 执行0x13号中断的2号功能（读盘功能）

对于老式机械硬盘、软盘来说，它们都属于「磁盘」的一种。根据其机械结构分为柱面(Cylinder)、磁头(Head)、扇区(Sector)，一般表示为CHS，柱面和磁头从0开始，扇区从1开始标号。

BIOS如果设置为软盘启动，就会加载0号驱动器的C0-H0-S1到内存的0x07c00的位置。如果设置为硬盘启动，就会加载0x80号驱动器的C0-H0-S1到内存的0x07c00的位置。

那么现在，我们承担MBR角色的程序，就需要再把其他数据也加载到内存中。不过这时的内存选址就由我们随意了，并不一定要紧接着MBR加载的位置，上面例程中选择了0x08000的位置，你也可以选择其他位置，但要主要，不能占用BIOS预留的位置，也不能占用显存位置。通常8086的内存布局如下：

从上表可知，0x00500到0x9fbff这638.75KB的空间都是可用的，但是由于MBR占用了其中的512B，剩下的部分我们可以自由支配。

下面我们就编写一个程序，前512B作为MBR，加载两个扇区（1KB）的数据到0x08000的位置，然后再跳转至该位置，执行指令：

; C0H0S1
; 调用0x10号BIOS中断，清屏
mov al, 0x03
mov ah, 0x00
int 0x10 
; 加载一个扇区到0x08000的位置
mov ax, 0x0800
mov es, ax
mov bx, 0 ; 软盘中的内容会加载到es:bx的位置
mov ah, 2 ; ah=2, 使用读盘功能
mov al, 2 ; ah表示需要读取连续的几个扇区（读2个就是1KB的大小）
mov ch, 0 ; ch表示第几柱面
mov dh, 0 ; dh表示第几磁头
mov cl, 2 ; cl表示第几扇区
mov dl, 0 ; dl表示驱动器号，软盘会在0x00~0x7F，硬盘会在0x80~0xFF
int 0x13  ; 执行0x13号中断的2号功能（读盘功能）

jmp 0x0800:0x0000 ; 这里写成0x0000:0x8000也OK，只是CS和IP的值会不同，但CS:IP是相同的

times 510-($-$$) db 0 ; MBR剩余部分用0填充
dw 0xaa55

; 现在已经是C0H0S2的内容了
begin:
mov ax, 0xb800
mov ds, ax
mov [0x0000], byte 'H'
mov [0x0001], byte 0x0f
mov [0x0002], byte 'e'
mov [0x0003], byte 0x0f
mov [0x0004], byte 'l'
mov [0x0005], byte 0x0f
mov [0x0006], byte 'l'
mov [0x0007], byte 0x0f
mov [0x0008], byte 'o'
mov [0x0009], byte 0x0f
hlt

times 1024-($-begin) db 0 ; 补满2个扇区

可以确认一下，此时的mbr.bin变成了1536B，当然，它现在叫「MBR」已经不太合适了，它应当是包含了MBR和内核程序的一个总包。暂时我们先忽略这个叫法的问题，稍后再来看如何将MBR和内核程序分离。

同样，将其重命名为a.img，然后打开bochs看运行效果：

这证明，后面扇区的内容也加载成功了，跳转指令也完成了正确的跳转。

另外，当我们程序有稍微的规模了的时候，大家可以考虑用单步执行命令来做调试。例如启动后，我们先在0x7c00处打断点，然后c执行BIOS的指令，然后按n开始跳过调用流程的单步调试（s是单纯的单步调试，但是会把BIOS中断中的指令也显示出来，按n则不会）。大概效果如下：

而在经历一些加载数据功能后，我们还可以用x命令来查看对应内存位置，例如当执行完0x13中断后，我可以看一下0x08000位置的内存，到底有没有写入数据：

也可通过r和sreg指令查看寄存器的值，比如在跳转指令前后，查看CS和IP的值。跳转前：

然后执行n，完成跳转指令后，再看一下CS和IP的值：

大家可以根据需要进行调试观察自己的程序。

改为硬盘启动

BIOS中断的局限性

照理说，按照前面一节的方法，利用BIOS中断加载软盘中的数据到内存中再去执行，在8086下貌似是没什么问题的。但这不是长久之际，8086下只有640KB不到的内存空间供我们支配，自然用当前的这种方式没什么问题，但毕竟8086模式只是过渡，后续我们要切换到32位模式以支持4GB内存，还要切换到64位模式支持更大的内存。

虽然BIOS中断是很方便的工具，相当于基础系统提供了一些库函数供我们使用，但它毕竟依赖BIOS，BIOS中提供的指令都是16位实模式（8086模式）的指令，一旦后续我们切换为i286模式、i386模式后，这些BIOS中断就无法使用了（因为指令集不匹配）。

其实，向显存写入数据的这种需求，也是可以通过BIOS中断来完成的，但笔者并没有介绍这种方法，而是使用直接操作显存的方式，目的也就在此，因为我们不可能一直停留在8086模式。同理，加载外存中的数据这种需求，也应当有它原始方法。

I/O设备的操作

前面我们介绍过I/O，有一些是统一编址的（比如显存），也有一些是独立编址的，CPU会通过专用的指令，控制I/O控制器（或者也可以叫南桥芯片）来管理这些I/O设备。

I/O设备会映射成一个端口号，CPU向对应的端口号发送或读取数据，间接通过I/O控制器来控制外围的I/O设备。软驱也是其中的一员，我们可以控制几个软驱控制器（例如DOR、FDC）来读取和写入软盘中的内容。不过软驱的控制方法比较麻烦（只支持CHS模式，不支持LBA模式。LBA模式在后面章节详细介绍），又因为3.5英寸软盘只有1440KB的限制，迟早不够使，因此，我们姑且就不去详细研究软驱的控制方法了。接下来，我们要将我们的模拟器环境，改为用硬盘启动。

配置硬盘启动

配置硬盘，需要修改bochsrc的内容，我们将软盘启动相关配置注释掉或删除掉，改为以下内容：

## boot: floppy ## 设置软盘启动
## floppy_bootsig_check: disabled=0 ## 打开自检
## floppya: type=1_44, 1_44="a.img", status=inserted, write_protected=0 ## 使用1.44MB的3.5英寸软盘，取镜像为a.img，开机默认已插入软驱，不开启写保护

ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14 ## 主盘端口映射为1f0，从盘映射为3f0，中断号设置为14（虽然这几个参数都可以定制化，但这个参数是业界标准的，不建议更改）
ata0-master: type=disk, mode=flat, path=a.img, cylinders=1, heads=1, spt=1 ## 主盘位置加载一块规格为C1H1S1的硬盘，镜像使用a.img
boot: disk ## 设置为硬盘启动

这里需要注意一下，硬盘的规格我们暂时设置的是1柱面1磁头1扇区，也就是只有512字节的硬盘，那么对于a.img来说，超过512B的部分是不会加载进去的。（暂时这样设置一下，后面肯定会改的。）

首先先来测试一下MBR能否正常加载，所有我们把之前MBR中写的那些跳转语句、还有512B后面的部分都先删除，打印几个文字来验一验效果：

; 调用0x10号BIOS中断，清屏
mov al, 0x03
mov ah, 0x00
int 0x10 

mov ax, 0xb800
mov ds, ax
mov [0x0000], byte 'H'
mov [0x0001], byte 0x0f
mov [0x0002], byte 'e'
mov [0x0003], byte 0x0f
mov [0x0004], byte 'l'
mov [0x0005], byte 0x0f
mov [0x0006], byte 'l'
mov [0x0007], byte 0x0f
mov [0x0008], byte 'o'
mov [0x0009], byte 0x0f
hlt

times 510-($-$$) db 0 ; MBR剩余部分用0填充
dw 0xaa55

将其编译为mbr.bin，确认一下它的大小是512字节：

然后把它复制为a.img，再启动一下看看效果：

能看到输出，说明我们已经成功切换成硬盘启动了。那么接下来就是如何加载后面扇区的数据的问题了。

通过操作I/O加载硬盘数据

前面我们用了CHS方式来编号硬盘，但除了CHS以外，还有另外一种方式，叫做LBA，也就是Logical Block Address。这种方式下，硬盘会直接按照连续的扇区进行编号，对磁头和柱面不再感知。

LBA28是一种比较原始的方式，28表示用28位编号，也就是0x0000000~0xFFFFFFF的扇区号，注意，0号是预留位，真正的扇区是从1号开始的。

用于控制硬盘的设备会有对应的端口号，在前面我们bochsrc中也有对应的配置，比如当前使用了默认值，也就是0x01f0，从这个端口向后的若干端口都是用来操作硬盘的。因此，我们要按照一定的顺序，向对应的端口中写入数据，来指导硬盘控制器读取硬盘数据。

首先要配置的是需要读取的端口数，这个数据要写入0x01f2端口中：

; 设置读取扇区的数量
mov dx, 0x01f2
mov al, 2 ; 读取连续的几个扇区，每读取一个al就会减1
out dx, al

然后我们来配置起始扇区号。1号扇区就是MBR，已经加载进来了，所以我们从第2号扇区开始加载。虽然只是一个简单的2号，但其实LBA28模式下扇区号是有28位的，因此我们要拆分成4次，分别写入不同的端口中。0x01f3需要传入扇区号的0~7位，0x01f4需要传入扇区号的8~15位，0x01f5需要传入扇区号的16~23位，0x01f5则拆分为3部分，低4位是扇区号的24~27位，第4位表示主从盘，高3位表示扇区编号的模式。

这部分的代码如下，笔者已经加入了详细的注释，请读者仔细阅读：

; 设置起始扇区号，28位需要拆开
mov dx, 0x01f3
mov al, 0x02 ; 从第2个扇区开始读（1起始，0留空），扇区号0~7位
out dx, al
mov dx, 0x01f4 ; 扇区号8~15位
mov al, 0
out dx, al
mov dx, 0x01f5 ; 扇区号16~23位
mov al, 0
out dx, al
mov dx, 0x01f6
mov al, 111_0_0000b ; 低4位是扇区号24~27位，第4位是主从盘（0主1从），高3位表示磁盘模式（111表示LBA模式）

接下来要配置操作命令，我们要做「读盘」操作，对应的命令号是0x20，它要写入0x01f7端口：

; 配置命令
mov dx, 0x01f7
mov al, 0x20 ; 0x20命令表示读盘
out dx, al

一切就绪之后，控制器就会开始读盘了，但这需要一定的时间，所以此时程序要等待驱动器工作完成。0x01f7端口如果使用in命令，读取到的是硬盘控制器的状态数据，其中第7位表示是否忙碌，第3位表示是否就绪。那么也就是说，当第7位是0且第3位是1的话，说明驱动器已经完成，否则就要持续等待：

wait_finish:
; 检测状态，是否读取完毕
mov dx, 0x01f7
in al, dx ; 通过该端口读取状态数据
and al, 1000_1000b ; 保留第7位和第3位
cmp al, 0000_1000b ; 要检测第7位为0（表示不在忙碌状态）和第3位是否是1（表示已经读取完毕）
jne wait_finish ; 如果不满足则循环等待

当驱动器就绪后，我们就可以通过0x01f0端口来加载数据到内存了。这个端口是个16位端口，因此每次可以读2字节。这里我们用一个循环语句来完成，循环语句的循环次数要写在cx中，每次循环时cx会自动减1，直到cx为0则跳出循环。

所以，如果我们需要加载2个扇区的数据，那么就是1024字节的内容，而循环次数就是512，所以把这个数配到cx中：

mov cx, 512 ; 一共要读的字节除以2（表示次数，因为每次会读2字节所以要除以2）

还是按照一开始的规划，我们把屏幕打印的部分放到第二扇区，然后把它加载到0x08000的内存位置：

mov dx, 0x01f0
mov ax, 0x0800
mov ds, ax
xor bx, bx ; [ds:bx] = 0x08000
read:
in ax, dx ; 16位端口，所以要用16位寄存器
mov [bx], ax
add bx, 2 ; 因为ax是16位，所以一次会写2字节
loop read

最后通过跳转指令跳转过去，查看是否加载成功。下面给出完整代码：

; C0H0S1
; 调用0x10号BIOS中断，清屏
mov al, 0x03
mov ah, 0x00
int 0x10 

; LBA28模式，逻辑扇区号28位，从0x0000000到0xFFFFFFF
; 设置读取扇区的数量
mov dx, 0x01f2
mov al, 2 ; 读取连续的几个扇区，每读取一个al就会减1
out dx, al
; 设置起始扇区号，28位需要拆开
mov dx, 0x01f3
mov al, 0x02 ; 从第2个扇区开始读（1起始，0留空），扇区号0~7位
out dx, al
mov dx, 0x01f4 ; 扇区号8~15位
mov al, 0
out dx, al
mov dx, 0x01f5 ; 扇区号16~23位
mov al, 0
out dx, al
mov dx, 0x01f6
mov al, 111_0_0000b ; 低4位是扇区号24~27位，第4位是主从盘（0主1从），高3位表示磁盘模式（111表示LBA）
; 配置命令
mov dx, 0x01f7
mov al, 0x20 ; 0x20命令表示读盘
out dx, al

wait_finish:
; 检测状态，是否读取完毕
mov dx, 0x01f7
in al, dx ; 通过该端口读取状态数据
and al, 1000_1000b ; 保留第7位和第3位
cmp al, 0000_1000b ; 要检测第7位为0（表示不在忙碌状态）和第3位是否是1（表示已经读取完毕）
jne wait_finish ; 如果不满足则循环等待

; 从端口加载数据到内存
mov cx, 512 ; 一共要读的字节除以2（表示次数，因为每次会读2字节所以要除以2）
mov dx, 0x01f0
mov ax, 0x0800
mov ds, ax
xor bx, bx ; [ds:bx] = 0x08000
read:
in ax, dx ; 16位端口，所以要用16位寄存器
mov [bx], ax
add bx, 2 ; 因为ax是16位，所以一次会写2字节
loop read

jmp 0x0800:0x0000 ; 这里写成0x0000:0x8000也OK，只是CS和IP的值会不同，但CS:IP是相同的

times 510-($-$$) db 0 ; MBR剩余部分用0填充
dw 0xaa55

; 现在已经是C0H0S2的内容了
begin:
mov ax, 0xb800
mov ds, ax
mov [0x0000], byte 'H'
mov [0x0001], byte 0x0f
mov [0x0002], byte 'e'
mov [0x0003], byte 0x0f
mov [0x0004], byte 'l'
mov [0x0005], byte 0x0f
mov [0x0006], byte 'l'
mov [0x0007], byte 0x0f
mov [0x0008], byte 'o'
mov [0x0009], byte 0x0f
hlt

times 1024-($-begin) db 0 ; 补满2个扇区

注意，由于我们已经把扇区扩展到了3个，因此bochsrc里面 也需要修改一下硬盘的规模：

ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14 ## 主盘端口映射为1f0，从盘映射为3f0，中断号设置为14（虽然这几个参数都可以定制化，但这个参数是业界标准的，不建议更改）
ata0-master: type=disk, mode=flat, path=a.img, cylinders=1, heads=1, spt=3 ## 主盘位置加载一块规格为C1H1S3的硬盘，镜像使用a.img
boot: disk ## 设置为硬盘启动

最后通过汇编生成mbr.bin，复制为a.img，再启动bochs就可以看到执行效果：

此时也可以通过调试指令来验证0x8000的内存中确实加载了对应的指令：

由此殊途同归，我们没有使用BIOS中断，也同样完成了硬盘加载的工作。

把MBR和内核源码拆开

拆分MBR和Kernel

前面章节中我们已经可以成功把硬盘里除第一扇区外的其他扇区正常加载到内存中了，但之前的做法是把后续的代码和MBR源码挤在同一个文件中，这显然是不方便后续管理的。

从架构设计的角度上来说，MBR以外的这些代码属于OS内核，因此对于「MBR」和「OS内核」这两部分的内容，还是应该拆开的。MBR由BIOS引导，而内核由MBR引导。

做法也很简单，把MBR和内核的代码分别拆到两个文件中：

mbr.nas:

; 调用0x10号BIOS中断，清屏
mov al, 0x03
mov ah, 0x00
int 0x10 

; ...省略中间代码...
jmp 0x0800:0x0000 ; 跳转到内核代码

times 510-($-$$) db 0 ; MBR剩余部分用0填充
dw 0xaa55
; 到此，只会有512字节的二进制文件生成

kernel.nas:

begin:
mov ax, 0xb800
mov ds, ax
mov [0x0000], byte 'H'
; ...省略中间代码...
hlt

times 1024-($-$$) db 0 ; 由于begin已经在此文件中定投了，所以这里改成了$$

它们可以分别汇编成独立的二进制，使用如下指令：

nasm mbr.nas -o mbr.bin
nasm kernel.nas -o kernel.bin

从而生成mbr.bin和kernel.bin两份二进制。接下来的问题就在于，如何把这两份二进制拼成一份完整的磁盘镜像（a.img）。如果有读者在前面对于笔者总是要节外生枝，把mbr.bin复制一份作为a.img的行为不理解的话，相信此时应该能够理解了。

考虑到后续可能发展到不止两个二进制，而且文件体积会变大，因此，我们采取的方式是，先生成一个空的磁盘镜像文件，再向这个镜像文件的合适位置里写入二进制。（想象真机的场景，我们应当是首先拥有一块硬盘或者软盘，然后再往这个硬盘中写入数据。而不是直接拿着数据去定制生产一块硬盘。）

这里我们使用bximage工具来创建磁盘镜像，这个工具是bochs自带的，所以只要正确安装了bochs，就不需要单独安装它。

使用以下命令来创建磁盘镜像：

bximage -q -func=create -hd=16M a.img

这里的-q表示安静模式，如果参数错误会直接报错，而不是进入交互模式。-func-create表示创建镜像。-hd=16M表示创建一个大小是16MB的硬盘（注意这里最小是16M）。最后的a.img是文件名。

默认情况下，扇区大小是标准的512B，所以我们相当于生成了一个C/H/S=32/16/64规格的硬盘，控制台也会有提示：

哎？不是说S=64嘛，怎么变63了？这就是前面我们提到过的有一个小问题，就是说0号扇区是留空的，真正的扇区要从1号开始。所以如果表示扇区号的寄存器预留了6位，那么实际可用的扇区应该是个。因此用bximage工具的时候，实际生成的磁盘大小会比我们输入的值略小，也就是每个柱面都会少一个扇区。

所以这里按照C/H/S=32/16/63来计算，磁盘大小应该是才对。

注意在macOS中，数据单位的换算是按1000来换算的（不知道苹果为什么这么搞……），所以会显示16.5MB，因此不要信任这个数字（Windows中的换算是对的），而是应当看实际以「字节」为单位的数字是否正确。 生成好磁盘镜像以后，我们使用dd工具，把MBR和内核的二进制分别写在磁盘镜像的第一个和第二、三个扇区中：

dd if=mbr.bin of=a.img conv=notrunc
dd if=kernel.bin of=a.img bs=512 seek=1 conv=notrunc

这里的if参数是输入文件，of参数是输出文件，conv=notrunc表示不改变输出文件的大小。bs=512 seek=1表示扇区大小是512B，跳过1个扇区后开始（因为内核要从第二个扇区开始写）。

由于dd是类UNIX自带指令，使用macOS的话可以直接使用，而如果使用Windows则需要额外安装（下一节介绍Windows上安装dd的方法）。

由于这里磁盘镜像的结构发生了变化，所以我们同步调整bochsrc，如下：

ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14 ## 主盘端口映射为1f0，从盘映射为3f0，中断号设置为14（虽然这几个参数都可以定制化，但这个参数是业界标准的，不建议更改）
ata0-master: type=disk, mode=flat, path=a.img, cylinders=32, heads=16, spt=63 ## 主盘位置加载一块规格为C32H16S63的硬盘，镜像使用a.img
boot: disk ## 设置为硬盘启动

启动bochs可以看到效果：

bochs -qf bochsrc

证明我们的加载是成功的。

在Windows上安装dd工具

macOS和Linux中有很多非常方便的工具，毕竟他们同属于类UNIX家族。但Windows和他们并不同源，所以需要单独来安装。当然，Windows上也有原生的同作用的工具可用，如果读者熟悉的话当然没问题。但本篇文章为了保证多平台的一致性，还是会使用dd工具，因此这里介绍一下如何在Windows上安装dd工具。

在chrysocome官网上下载dd工具，注意这里下载列表里的东西比较多，不要下载错了，要找到`ddrelease64.exe。

这个工具没有安装包，下载下来直接就是可用的工具，我们把它放到一个方便自己管理的路径下，然后把这个路径配置到环境变量中（方法可以参考前面配置nasm的方法）。

更简单的方法是直接把这个程序复制到C:\Windows下，因为这个路径本来就在环境变量中。

建议把ddrelease64.exe重命名为dd.exe，这样命令会统一，使用更方便。

之后打开控制台，输入dd -h，如果能正常输出，说明dd工具已经配置就绪。

使用makefile

当文件拆开后，每次生成a.img需要好几条命令，并且后续会逐渐增多，所以搞一个项目工程生成的配置文件是一个比较好的方法。这里我们使用make工具。

make工具是GNU工具集中的一部分，在macOS下可通过Home Brew安装，在Windows下可通过MinGW来安装。

在macOS上安装make

在安装并配置好Home Brew的前提下，输入下面命令：

brew install make

等待安装流程结束后输入make -v，如果能出现版本号，证明安装成功。

在Windows上安装make

刚才介绍过，make工具属于GNU工具集中的，在Windows上安装GNU工具集需要用到MinGW工具，以后我们安装gcc相关工具也会用到MinGW。

首先进入sourceforge官网下载MinGW。

之后运行安装包，并进行安装

同样，安装参数保持默认即可。

安装完毕后点击「continue」。

之后会弹出MinGW的管理界面，选择「All Package」，然后找到mingw32-make的bin文件（注意要找bin文件，这才是程序，其他的是文档），点击后选「Mark to installation」

确认它被选中的情况下，点击「Installation」，选择「Apply Changes」，随后点击「Apply」即可开始安装make。

之后就是配置环境变量，默认情况下MinGW安装的程序会放在C:\MinGW\bin中。

我们把这个路径配置到环境变量中（详细方法可以看前面章节）：

然后我们打开控制台，输入mingw32-make -v，如果能出现版本号说明配置成功。

配置项目的makefile

make工具的运行依赖于makefile文件，我们在工程路径下创建一个名为makefile的文件，注意，这个文件没有任何后缀。然后编写以下内容：

.PHONY: all
all: sys

.PHONY: run
run: bochsrc sys
    bochs -qf bochsrc

a.img:
    rm -f a.img
    bximage -q -func=create -hd=16M $@

sys: a.img mbr.bin kernel.bin
    dd if=mbr.bin of=a.img conv=notrunc
    dd if=kernel.bin of=a.img bs=512 seek=1 conv=notrunc

mbr.bin: mbr.nas
    nasm mbr.nas -o mbr.bin

kernel.bin: kernel.nas
    nasm kernel.nas -o kernel.bin

.PHONY: clean
clean:
    -rm -f *.bin

要注意，上面的行前缩进都必须是制表符（'\t'，也就是按TAB键），而不可以是空格，否则无法正常运行。

保存之后，直接在项目路径下输入make run（如果是MinGW安装的则应当输入mingw32-make run，后文都同理，不再特别标注），即可全自动生成a.img，并且启动bochs运行：

接下来我们来解释一下makefile中的内容代表什么含义。

大致上来说，makefile的写法是：

目标: 依赖1 依赖2 ...
[Tab] 生成指令

比如说前面的：

mbr.bin: mbr.nas
    nasm mbr.nas -o mbr.bin

就表示，要生成mbr.bin文件，则需要mbr.nas文件，生成的指令是nasm mbr.nas -o mbr.bin。与此同时，它自带依赖，比如说生成sys需要mbr.bin，那么它就会先去生成mbr.bin。

对于这个.PHONY:run则表示后面的run并不是实际文件，而是一个标签。

make规则会默认按照第一个规则，也就是说，如果我们直接输入make，就相当于输入了make all，匹配makefile中的all标签。一般情况下还会在最后设置一个clean标签用做清理。

详细的makefile写法就不在本篇内容中介绍了，如果读者感兴趣可以自行查阅。为了降低门槛，笔者在本篇文章中也不会使用复杂的makefile语法，所以读者无需担心。

从8086到80286

到目前为止，我们已经从裸机启动开始，加载了mbr，又通过mbr加载了kernel。真的要说起来，再往后就应该是用kernel来调度用户程序了，但目前我们还没办法走到这一步，因为有一个很严重的问题，就是目前整个理论和流程，都是8086上的。

要想继续进行，咱们得先进入一个正常的模式，至少要先进入IA32模式，我们才能聊加载C/C++程序的事。但想从8086模式进入IA32模式并不是件容易的事，我们得串一遍架构发展的流程。这件事还蛮有意思的，因为我觉得跟生物进化如出一辙。比如说人类在母体内的发育过程，就很像一个极速版的人类从原始海洋生物不断进化的过程。类比到程序启动这里也是一样的，Intel从8086开始，到推出286、386、再到后面64位CPU的历史发展过程，也会浓缩在计算机启动的过程中。

在计算机启动时，CPU就是以8086模式工作的（当然，如果Intel推出x86S模式以后，情况可能会发生变化，但至少本文编写时，以常规AMD64架构方式设计的CPU还是会以8086模式开始启动的），然后要通过一些配置进入286模式，再进入IA-32模式，再进入AMD-64模式。

所以，我们还是需要了解一下中间这些历史发展情况，然后来指导我们如何配置和进入更高层的模式。

A20使能端

之前我们提到过8086机器有20位地址总线，但是却是用了2个16位寄存器来表示内存地址的。但是，用2个16位来拼凑一个20位地址，其实是有盈余的。

我们计算一下就可以知道，这种表示方式的范围应该是0x0000:0x0000~0xffff:0xffff，也就是0x00000~0x10ffef。我们发现最大值已经超过了20位的范围0xfffff。那么如果我真的把寄存器配成0x10000~0x10ffef之间的部分会怎么样？还记得前面解释内存地址拼接时的那张图吗？

既然是全加器，它的输出端其实应该要有进位符的输出的。事实上在硬件中的确有这个进位输出端，只不过在8086的CPU中，结果被丢弃了而已。

因此，在8086中，超过了16位的部分会被丢弃，也就是说0x10000~0x10ffef的部分会变成0x0000~0x0ffef。

接下来我们做个实验来验证这个说法。将es:dx配置为0xff00:0xf000，结果应该是0x10e000，那么按照刚才的说法，这个地址其实应该会反转到0x0e000处。

把kernel.nas改为以下内容：

begin:
mov ax, 0xff00
mov es, ax

mov [es:0xf000], byte 0xaa ; 给这个位置写入0xaa

hlt

times 1024-($-begin) db 0

然后通过调试模式，查看写入内存这一句的前后，内存的情况。我们make run以后，输入pb 0x8000，在kernel处打断点，然后用c命令执行至kernel处。再执行2次n命令，到我们需要观察的位置：

这时你可以通过x命令来看看此时的内存情况，现在不看，等一下执行完再看也行。

再执行一次n命令，让写入内存的指令生效，之后我们来看一下0xe000的内存情况，通过x 0xe000命令：

不对呀！这里的内存为什么没有被改呢？先不急，我们再来看一下0x10e000的情况：

这里是生效的！那这件事就很奇怪了，它事实上并没有发生我们预料之中的反转情况，因为根据上面的实验，0x10e000并没有映射到0x0e000上。

所以这里必须要提醒大家，虽然前面我们一直在解释8086的各种情况，但bochs并不是8086模拟器！，而是AMD-64模拟器。换句话说，咱们现在的运行环境并不是真正的8086，只是一个AMD-64的CPU，运行在了8086模式下罢了。

刚才我们说，20位全加器的进位结果，在8086上是被丢弃的，这是因为8086只有20位地址线。但是，到了80286的时候，就已经升级为24位地址线了，那么当时Intel理所应当地认为，这个全加器的进位结果，就应该接到第20位地址线（或者叫A20）上。

也就是说，80286处理器运行在8086模式下时，会有21位地址是有效的，有效地址范围是0x00000~0x10ffef，超出0xfffff的部分并不会反转（因为进位标志是有效的）。这个特性同样在后续的IA-32架构和AMD-64架构上被延续了下来，所以，我们在模拟器上看不到内存地址的反转。

虽然说现在看起来，这种做法无可厚非，但是当年却爆炸了。据说，是因为一个比较重要的软件，程序员在编写的时候利用了这种反转特性进行了编码。那么在8086机器上是运行OK的，但是换到了80286机器上，程序就不能正常运行了。（这个故事也告诉我们，程序员编码的时候还是应当以软件方式来思考问题，不应当依赖这种非常特殊的硬件特性来实现功能，否则硬件兼容性就会很差。）

因此为了解决这个问题，主板厂商想了一个办法，就是用南桥芯片来控制CPU的A20使能。通过给特定端口的I/O发送消息，来间接控制A20地址线是否有效。如果要在80286上运行依赖于地址反转的8086程序的话，只需要先将A20地址线去使能，然后就可以正常运行。

这个功能被映射到了I/O的0x92端口上，这个端口控制器的第1位（注意是第1位而不是第0位，也就是从低向高的低二位）用于控制A20的使能，也被称为A20 Mask位，简称A20M。为1时，A20去使能，地址会反转；为0时，A20使能，地址不会反转。

所以，我们先将A20M开启，然后再去写内存，就也可以达成目的了，代码如下：

begin:

; 开启A20M，允许超1M的地址反转
in al, 0x92
and al, 11111101b
out 0x92, al

; 再尝试溢出地址中写入数据
mov ax, 0xff00
mov es, ax

mov [es:0xf000], byte 0xaa

hlt

times 1024-($-begin) db 0 ; 补满2个扇区

然后按照之前的方式重新实验，可以观察到这时，0xe000的内存是被实际操作的： 不过对于我们来说，正常情况下不用刻意控制A20M，因为它默认是关闭的（也就是说A20默认是使能的）。

所以，这个例子也是为了提醒大家，我们现在并不是真正的8086设备，而是以8086模式运行的AMD64设备。（当然，后面要介绍的80826模式、IA32模式也是同理）。

从8086到80286

我们知道8086有20位地址总线，而80286有24位地址总线。因此，如果按照8086的寻址方式，即便是我们打开了A20M，也只是最多能达到21位的寻址空间。那么如何利用好这24位地址总线呢？

比较容易想到的一种方案是这样的。既然在8086里，我们是通过2个16位寄存器拼出一个20位地址的，那么，稍微改变一下偏移的策略，也是可以用2个16位寄存器拼出一个24位地址的嘛。也就是说段地址偏移8位（不再是4位）再加上偏移地址就好了。

上面这种方法确实可以简单地解决问题，但在80286诞生的时候，8086已经有相当一部分市场了，如果这时Intel推出一款新的处理器是新的寻址方式的话，就无法兼容现有的软件。因此，要想让8086的软件能够正常在80286上运行，80286就需要一种向下兼容的运行模式，也就是8086模式，在这种模式下，要按照8086的寻址方式来工作。

不过照理说，这样也不冲突，8086模式下我们按偏移4位的方式，286模式下我们按偏移8位的方式，也可以解决问题，但Intel并没有选择这样做，原因其实是在于恶意软件的防范（通俗的说法就是防病毒）。

在8086上，由于段寄存器是可以随便填写的，所有的程序都拥有最高权限，都可以访问任意的内存空间。随着计算机功能的不断扩充，逐渐也就不满足于单进程的运行方式了，那么，就需要引入操作系统的概念，区分「内核进程」和「用户进程」，让每个程序只能操作自己的一亩三分地，不能越权。因此，Intel就在80286上引入了这种保护基址，通过将内存分段，并且给每个段分配一个地址范围和操作权限。OS负责统筹段的选择，在进入用户进程之前，配置好对应的段，然后再执行用户进程，这样，用户进程的执行过程中就无法跨段操作，从而保证程序安全。

既然分段，还要额外配置段的范围以及权限，那么显然这个内容就不是一个简单的段地址这么简单了，因此，在286模式下，「段寄存器」就不能简简单单只保存一个段基址了，因为这样的信息是不够的。

286模式的解决方法，是把「段配置」这样的配置信息存在内存中，包括需要分几个段，每个段的首地址、末地址是多少，段的权限是怎样的。然后，把需要使用的段的序号传入段寄存器。寻址时，会首先根据段寄存器中保存的段序号找到对应的段基址，然后用基址加上偏移地址得到物理地址。之后，会根据段配置的权限，对当前操作指令进行合法性判断，例如对于只读的段来说，如果遇到写入操作，那么就会认为操作非法，从而触发系统中断。

大致的过程就是上述的这样，我们把段寄存器中保存的段序号称为「段选择子」，而这种通过段的提前配置，然后用段选择子+偏移地址的这种寻址方式称为「保护模式」，与之对应的原本8086的寻址方式则被称为「实模式」。

所以，在进入保护模式之前，我们得先配置一份段的描述表，否则进入保护模式后寻址会出问题的。

全局描述表

全局描述表，又称GDT（Global Descriptor Table），就是用来配置我们的内存要如何分段的数据表。

由于目前我们还在实模式下，所以，咱们也只能在当前可用的内存中间中，找一个地方，来放GDT，这里，我们就暂且选择0x7e00这个位置，以后进入保护模式后可以再更换。

从0x7e00位置开始，每8个字节配置1个段，并且要求最开头的段（0号段）强制为空（为什么要强制为空呢？当程序发生不合法的短访问时，系统中断会使得段寄存器强制归零，那么此时相当于选择了0号段，因此，0号段必须是一个不合法的段才行。）

之后，每一个段的配置要符合下面的描述表：

分别解释一下，首先，段界限Limit很好理解，就是当前这个段的大小，不过这里跟我们通常意义上理解的「大小」有一点区别，它想表明的是「段的最后一个字节的偏移量」，也就是说，这个值仍然在段内，只不过是段的最后一个字节。所以，Limit跟我们理解的Size其实差了1个字节。举例来说，如果我们希望这个段的大小是1KB，那么Limit应该填1023或者0x3ff而不是1024。

段基址Base就不用说了，就是这个段的首地址对应的内存大小。由于80286是24位地址空间，所以段基址也应该是个24位的内存地址。

访问位A可以理解为OS用作段访问标记的，用来让OS统计段的访问频率，以及虚拟内存策略使用。所以这一位对我们目前来说没有什么用途，填0就好。

子类型Type用于表示当前这个段的作用，Type内的3位分别叫做X``E``W，X和W这两个用过Unix的小伙伴一定很熟悉，分别表示「可执行」「可写」。如果X为0，那么当前段只能存数据，而不能用作执行指令。如果W为0，那么当前段只读，不可更改。

而E则表示段扩展方向，如果E=0则表示向高地址扩展，E=1表示向低地址扩展，不过目前我们暂时还不用考虑段的扩展问题，所以都默认填0就好。

S位表示这个段是否是「系统段」，系统段也是依赖于OS的概念，目前我们用不到，所以默认填0，表示他是普通的段。

DPL是权限等级，占2位，所以就是说一共可以划分4个等级，0位最高权限等级，3是最低等级。我们目前还是需要一个高权限来控制内核的，所以这里也应当填0。

P是存在位，或者也可以理解成「使能」位，如果P为0，则当前段失效。为1时当前段有效。这个主要是做虚拟内存进出策略时用到的，我们当前应当保证P为1。

最后的AVL是保留位，在80286模式下没有用处，我们留白即可。

那么，按照上述描述，咱们就可以着手配置一个段表了，代码如下：

; 下面配置GDT
mov ax, 0x07e0
mov es, ax

; 空白段
mov [es:0x00], dword 0
mov [es:0x04], dword 0

; 1号段
; 基址0x8000，大小8KB
mov [es:0x08], word 0x1fff ; Limit=0x1fff
mov [es:0x0a], word 0x8000 ; Base=0x008000，这是低16位
mov [es:0x0c], byte 0      ; 这是Base的高8位
mov [es:0x0d], byte 1_00_1_100_0b ; P=1, DPL=0, S=1, Type=100b, A=0
mov [es:0x0e], word 0       ; 预留位，先填0

大家着重看一下这里的1号段，由于我们当前的目的并不是像OS那样做特别合理的段规划，因此，咱们暂时就配一个超管段，然后进入保护模式即可。我们就选取0x8000作为基址，配一个8KB的可写、可执行的段。

那么配置好的GDT，还需要想办法让它生效才行。80286提供了一个48位寄存器，用于存储GDT的配置，这个寄存器叫做GDTR，它的低16位表示GDT的界限（也就是limit逻辑，总长度-1），16~35位表示GDT的首地址，36~47位预留。

我们来看代码：

; 下面是gdt信息的配置（暂且放在0x07f00的位置）
mov ax, 0x07f0
mov ex, ax
mov [es:0x00], word 15      ; 因为目前配了2个段，长度为16，所以limit为15
mov [es:0x02], dword 0x7e00 ; GDT配置表的首地址
; 把gdt配置进gdtr
lgdt [es:0x00]

最后用lgdt命令，把数据存入GDTR中，那么GDT就配置完毕了。

不过，当前我们仅仅是配置了GDT，但机器仍然还在8086模式下，所以它暂时还是没什么用的，我们需要切换机器的运行模式。

注意这里，我的措辞是「8086模式」「切换模式」，原因很简单，因为我们现在并不是真的在用8086的CPU，甚至也不是80286的CPU，咱们模拟器的是一个AMD64架构的CPU，因此8086模式也好，286模式也好，都只是它的一种工作模式罢了。不过也正因如此，我们才能做切换，要是真的是8086的CPU的话，你无论如何也没法切换成286的。

那么，如何切换至286模式呢？其实在CPU内部，有一个控制寄存器，叫做MSW，说是寄存器，其实就是控制开关啦，只要我们改变其中某些位的数值，就可以改变CPU的运行状态。MSW的最后一位就表示了寻址方式，计算机启动时它是默认至0的，这是寻址方式为8086方式（也就是实模式），当我们把它切为1的时候，就会切换至286模式（也就是保护模式）。

但另一个很难受的问题在于，80286的MSW这个16位控制寄存器仅出现在了80286这款CPU上，到了80386的时候就淘汰了，所以，目前的x86汇编器都很难支持这个操作这个寄存器的指令。原本笔者是想让大家体验一把「纯粹」的286，但出于这个原因，无奈，我们还是只能用更「高档」的语法来实现这个功能。

其实MSW寄存器在80386上，成为了CR0寄存器的一部分。在80386上，CR0是一个控制寄存器，32位的，而它的低16位正好对应了MSW的功能。所以，我们更改CR0的最后一位，同样也可以切换至保护模式。只不过这里就不得不提前让我们来操作32位寄存器了，希望读者体谅，并且了解这步操作并不是80286的，而是我们当前的环境是AMD64模拟器，不得已而为之的，代码如下：

mov eax, cr0
or eax, 0x01 ; PE位置1，启动保护模式
mov cr0, eax

说明一下，eax是32位通用寄存器，它的低16位就是ax，这同样也是80386才支持的寄存器，我们此刻也只是无奈来使用一下它，希望读者悉知。

那么，当CR0被改变的那一刹那开始，CPU就进入保护模式了，那这个时候最大的问题就是，当前我们的CS寄存器里还是原来的数据，也就是段基址。我们得给他变成段选择子才行，而CS寄存器又不能直接改写，那怎么办呢？答案很简单，用远跳指令来强制刷新段寄存器，代码如下：

jmp 00001_00_0b:0 ; 远跳指令可以刷新cs，使用1号段

目前读者理解到这里就好，下一节我们会用一个完整的实例来演示。

重新写一份MBR代码

前面我们花了不少的篇幅来介绍保护模式，以及通过汇编指令进入保护模式的方法。那么这一节，我们就来上一个完整的实例，首先在实模式下加载Kernel，然后配置GDT，之后进入保护模式，跳转至Kernel，再在Kernel里再打印一些文字用以区分。

前面的实例中我们已经把工程代码分为了mbr和kernel，在mbr中读盘，加载到内存中，然后再通过跳转指令运行kernel文件。虽然照理来说，在kernel中再配置GDT然后进入保护模式也没什么问题，但这样就会使得kernel中同时夹杂两种模式的指令代码（后续我们介绍完386模式以后，就还可能会同时混有16位和32位指令），不方便管理和维护。因此，我们在mbr中就做好这一些，最后以保护模式跳转至kernel部分，这样我们的kernel就会纯粹许多。

下面是我们重新写的一份MBR代码：

; 调用0x10号BIOS中断，清屏
mov al, 0x03
mov ah, 0x00
int 0x10 

; LBA28模式，逻辑扇区号28位，从0x0000000到0xFFFFFFF
; 设置读取扇区的数量
mov dx, 0x01f2
mov al, 2 ; 读取连续的几个扇区，每读取一个al就会减1
out dx, al
; 设置起始扇区号，28位需要拆开
mov dx, 0x01f3
mov al, 0x02 ; 从第2个扇区开始读（1起始，0留空），扇区号0~7位
out dx, al
mov dx, 0x01f4 ; 扇区号8~15位
mov al, 0
out dx, al
mov dx, 0x01f5 ; 扇区号16~23位
mov al, 0
out dx, al
mov dx, 0x01f6
mov al, 111_0_0000b ; 低4位是扇区号24~27位，第4位是主从盘（0主1从），高3位表示磁盘模式（111表示LBA）
; 配置命令
mov dx, 0x01f7
mov al, 0x20 ; 0x20命令表示读盘
out dx, al

wait_finish:
; 检测状态，是否读取完毕
mov dx, 0x01f7
in al, dx ; 通过该端口读取状态数据
and al, 1000_1000b ; 保留第7位和第3位
cmp al, 0000_1000b ; 要检测第7位为0（表示不在忙碌状态）和第3位是否是1（表示已经读取完毕）
jne wait_finish ; 如果不满足则循环等待

; 从端口加载数据到内存
mov cx, 512 ; 一共要读的字节除以2（表示次数，因为每次会读2字节所以要除以2）
mov dx, 0x01f0
mov ax, 0x0800
mov ds, ax
xor bx, bx ; [ds:bx] = 0x08000
read:
in ax, dx ; 16位端口，所以要用16位寄存器
mov [bx], ax
add bx, 2 ; 因为ax是16位，所以一次会写2字节
loop read

; 下面配置GDT
mov ax, 0x07e0
mov es, ax

; 空白段
mov [es:0x00], dword 0
mov [es:0x04], dword 0

; 1号段
; 基址0x8000，大小8KB
mov [es:0x08], word 0x1fff ; Limit=0x1fff
mov [es:0x0a], word 0x8000 ; Base=0x008000，这是低16位
mov [es:0x0c], byte 0      ; 这是Base的高8位
mov [es:0x0d], byte 1_00_1_100_0b ; P=1, DPL=0, S=1, Type=100b, A=0
mov [es:0x0e], word 0      ; 保留位都置0

; 下面是gdt信息的配置（暂且放在0x07f00的位置）
mov ax, 0x07f0
mov es, ax
mov [es:0x00], word 15      ; 因为目前配了2个段，长度为16，所以limit为15
mov [es:0x02], dword 0x7e00 ; GDT配置表的首地址
; 把gdt配置进gdtr
lgdt [es:0x00]

mov eax, cr0
or eax, 0x01 ; PE位置1，启动保护模式
mov cr0, eax

jmp 00001_00_0b:0 ; 远跳指令可以刷新cs，使用1号段，正好跳转至kernel的加载位置（0x8000）

times 510-($-$$) db 0 ; MBR剩余部分用0填充
dw 0xaa55

可以看到最后有一个远跳指令jmp 00001_00_0b:0，由于这个时候我们已经通过控制cr0寄存器来进入保护模式了，所以前面段的部分就已经不是段基址而是段选择子了。通过远跳指令我们就可以刷新cs寄存器，让他表示选择子1号段，而根据GDT的配置，1号段的段基址就是0x8000，也就正好是我们Kernel加载的位置。

所以接下来，我们只需要在Kernel中，输出一下信息，观察程序能否正常运行即可。但有个严重的问题是，要想输出信息我们需要写显存，可是显存在0xb8000~0xb8f9f，而1号段的界限在0x1fff，所以，我们当前的情况是没法操作显存的。那怎么办？我相信有读者可能会想到，那要不我们把1号段配长一点，包括到显存，是不是就可以操作了？

答案是：不可以！因为除了界限问题，保护模式下段是具有属性的，也就是GDT中的Type的XEW这3位，我们配置的时候配置的是100，W为0的时候是不可写的，所以我们不可以向这个段里写数据。

那，把Type配成101不就可以解决了么？理论上来说是的，但并不推荐大家这样去做，因为我们不希望指令段在执行时轻易被更改，这样程序的风险极大。当然了，如果大家仅仅是自己做实验方便的话，倒也无妨。

不过更稳妥的做法，是再配一个段，专门去管理显存。这样我们就要回到MBR里加一个GDT，把显存区域划分成一个段，然后再在显存中写数据即可。

; 2号段
; 基址0xb8000，上限0xb8f9f，覆盖所有显存
mov [es:0x10], word 0x0f9f ; Limit=0x0f9f
mov [es:0x12], word 0x8000 ; Base=0x0b8000，这是低16位
mov [es:0x14], byte 0x0b   ; 这是Base的高8位
mov [es:0x15], byte 1_00_1_001_0b ; P=1, DPL=0, S=1, Type=001b, A=0
mov [es:0x16], word 0

别忘了对应的GDT的配置也要变，要让2号段生效才行：

; 下面是gdt信息的配置（暂且放在0x07f00的位置）
mov ax, 0x07f0
mov es, ax
mov [es:0x00], word 23      ; 因为目前配了3个段，长度为24，所以limit为23
mov [es:0x02], dword 0x7e00 ; GDT配置表的首地址

下面给出修正后的完整MBR代码：

; 调用0x10号BIOS中断，清屏
mov al, 0x03
mov ah, 0x00
int 0x10 

; LBA28模式，逻辑扇区号28位，从0x0000000到0xFFFFFFF
; 设置读取扇区的数量
mov dx, 0x01f2
mov al, 2 ; 读取连续的几个扇区，每读取一个al就会减1
out dx, al
; 设置起始扇区号，28位需要拆开
mov dx, 0x01f3
mov al, 0x02 ; 从第2个扇区开始读（1起始，0留空），扇区号0~7位
out dx, al
mov dx, 0x01f4 ; 扇区号8~15位
mov al, 0
out dx, al
mov dx, 0x01f5 ; 扇区号16~23位
mov al, 0
out dx, al
mov dx, 0x01f6
mov al, 111_0_0000b ; 低4位是扇区号24~27位，第4位是主从盘（0主1从），高3位表示磁盘模式（111表示LBA）
; 配置命令
mov dx, 0x01f7
mov al, 0x20 ; 0x20命令表示读盘
out dx, al

wait_finish:
; 检测状态，是否读取完毕
mov dx, 0x01f7
in al, dx ; 通过该端口读取状态数据
and al, 1000_1000b ; 保留第7位和第3位
cmp al, 0000_1000b ; 要检测第7位为0（表示不在忙碌状态）和第3位是否是1（表示已经读取完毕）
jne wait_finish ; 如果不满足则循环等待

; 从端口加载数据到内存
mov cx, 512 ; 一共要读的字节除以2（表示次数，因为每次会读2字节所以要除以2）
mov dx, 0x01f0
mov ax, 0x0800
mov ds, ax
xor bx, bx ; [ds:bx] = 0x08000
read:
in ax, dx ; 16位端口，所以要用16位寄存器
mov [bx], ax
add bx, 2 ; 因为ax是16位，所以一次会写2字节
loop read

; 下面配置GDT
mov ax, 0x07e0
mov es, ax

; 空白段
mov [es:0x00], dword 0
mov [es:0x04], dword 0

; 1号段
; 基址0x8000，大小8KB
mov [es:0x08], word 0x1fff ; Limit=0x1fff
mov [es:0x0a], word 0x8000 ; Base=0x008000，这是低16位
mov [es:0x0c], byte 0      ; 这是Base的高8位
mov [es:0x0d], byte 1_00_1_100_0b ; P=1, DPL=0, S=1, Type=100b, A=0
mov [es:0x0e], word 0

; 2号段
; 基址0xb8000，上限0xb8f9f，覆盖所有显存
mov [es:0x10], word 0x0f9f ; Limit=0x0f9f
mov [es:0x12], word 0x8000 ; Base=0x0b8000，这是低16位
mov [es:0x14], byte 0x0b   ; 这是Base的高8位
mov [es:0x15], byte 1_00_1_001_0b ; P=1, DPL=0, S=1, Type=001b, A=0
mov [es:0x16], word 0

; 下面是gdt信息的配置（暂且放在0x07f00的位置）
mov ax, 0x07f0
mov es, ax
mov [es:0x00], word 23      ; 因为目前配了3个段，长度为24，所以limit为23
mov [es:0x02], dword 0x7e00 ; GDT配置表的首地址
; 把gdt配置进gdtr
lgdt [es:0x00]

mov eax, cr0
or eax, 0x01 ; PE位置1，启动保护模式
mov cr0, eax

jmp 00001_00_0b:0 ; 远跳指令可以刷新cs，使用1号段，正好跳转至kernel的加载位置（0x8000）

times 510-($-$$) db 0 ; MBR剩余部分用0填充
dw 0xaa55

然后我们在Kernel中打印随便打印点东西，查看效果即可。注意，要写显存的话，需要将段寄存器调整到2号选择子。

以下是Kernel例程：

begin:

mov ax, 00010_00_0b ; 选择2号段，以操作显存
mov ds, ax
; 打印Hello
mov [0x0000], byte 'H'
mov [0x0001], byte 0x0f
mov [0x0002], byte 'e'
mov [0x0003], byte 0x0f
mov [0x0004], byte 'l'
mov [0x0005], byte 0x0f
mov [0x0006], byte 'l'
mov [0x0007], byte 0x0f
mov [0x0008], byte 'o'
mov [0x0009], byte 0x0f

hlt

times 1024-($-begin) db 0 ; 补满2个扇区

以下是运行效果图：

上面的工程代码可以参考附件7。

探秘IA-32

稍安勿躁，我们没有偏题

到这一章的程度，我相信一定会有读者有这样的疑问：你不是要介绍怎么从裸机启动开始运行一个C++程序吗？到现在别说C++了，我们连C的毛都没见到嘞，天天都是各种硬件构造什么的，你是不是歪楼了啊？

笔者确实很担心大家会有这样的想法，所以觉得这里有必要解释一下。我们在前面的章节也提到过，计算机能够直接运行的只能是机器指令，汇编语言虽然很接近机器指令，但还是需要先经过汇编器的转换。而像C语言这种上层语言，就更不可能直接被计算机识别了，它要经历很多繁琐的转换步骤（比如预处理、编译、链接）。

前面介绍的8086实模式也好，80286的保护模式也好，用的都是Intel的16位指令集。虽然说当年贝尔实验室的大佬用C语言去开发Linux的时候还没有80286，并且确实也有适配80286的16位指令集的C语言编译期存在。但这些东西都没有被广泛使用，前面我们切换保护模式的时候就已经出现了类似的问题，因为现在的 CPU（即便是模拟器），都没有286的控制寄存器了，我们不得不用去操作CR0。

主要是因为，从80386开始确立的IA-32架构，在后续的很长一段时间内成为了PC机的主流架构，另一方面，目前C/C++的发行版编译期都是可以原生完美支持IA-32架构的编译的，但80286模式的确不能很好地支持，需要我们特殊去配置。

因此，笔者还是希望我们先稳定地了解到IA-32模式下，再考虑跟C语言去进行联动，所以这一章，还需要大家再坚持一下，当咱们的程序可以在IA-32模式下正常执行的时候，我们就可以开始跟C语言联动啦。

从286到386

80286最大的功劳就是引入了保护模式，这是一种完全不同于实模式的段分配方式。不知大家是否还记得，最初引入保护模式的两个主要目的是什么？一个是为了程序安全（所以引入了段权限），另一个则是因为寻址空间变大了，地址寄存器不够用。

而80386的最大功劳应该就是32位了，从386开始，不仅有了32位内存寻址空间，32位寄存器，同时还有了32位的指令集。

32位寻址空间也就意味着支持内存地址从0x00000000到0xffffffff一共4294967296B，合4GB的寻址空间。如果读者早年关注过个人PC的问题的话，可能会知道以前32位的电脑，最大只能支持4GB的内存，原因就是这个，因为寻址空间只有这么大。

寄存器方面，386将8个通用寄存器都扩展到了32位，分别是eax，ebx，ecx，edx，ebp，esp，edi，esi。注意这些寄存器的是在原本的16位寄存器上扩展得到的，例如说eax的低16位其实就是ax寄存器。当然了，指令寄存器ip也扩展到了eip，只不过这个寄存器不能随便使用罢了。同时还添加了gs和fs两个段寄存器。

而指令集也新添了32位指令集，注意这里是「添加」而不是「替换」，也就是说，386开始的CPU同样可以以实模式、286模式运行，这两种模式下执行的都是16位指令，只有在切换到386模式（或者叫IA-32模式）下，才会支持32位指令集。

IA-32模式也是保护模式，它跟286模式的区别在于指令集，所以286模式可以称为「16位保护模式」，IA-32模式可以称为「32位保护模式」。不过由于286比较短命，所以现在很少使用了，现代CPU也不会刻意进入286模式，而是会从实模式直接切换到IA-32模式（后面章节介绍切换方法的时候，这个问题就显而易见了），因此通常我们直接说「保护模式」，指的就是32位的保护模式，也就是IA-32模式。

IA-32汇编指令

这里需要给大家强调的是，汇编语言虽然很接近机器指令，但并不完全等价。同一条汇编指令，汇编为16位指令和32位指令可能是不同的，这一点大家一定要注意。

例如，mov ax, 5这句汇编，16位指令会汇编为B8 05 00，而32位指令会汇编为66 B8 05 00。所以我们在使用汇编语言的时候，除了要关注汇编语句本身，也要关注它的汇编环境才可以。

那么，如何在nasm中制定汇编指令集呢？方法如下：

[bits 32]
mov ax, 5

用[bits 32]语句声明后，从这一行往后的汇编指令，就会按照32位方式来汇编。如果想切回16位模式，那么就再声明[bits 16]即可。注意，如果我们没有显式声明的话，nasm默认是按照16位方式的，大家一定要注意。

不过现在我们写32位指令还无法运行，因为我们需要先将CPU切换到IA-32模式。

GDT的AVL保留位

在286的时候，我们配置GDT时，给了这样一张表：

注意这里的48~63位这16位是保留字段，而到了IA-32开始，这保留字段就真正发挥它的意义了。首先，既然是32位寻址空间，那么段基址它至少得是一个32位地址才行吧，而现在只有16~39这24位地址，还有8位怎么办？就只能塞到这保留的16位中了。还剩下8位则是增加了一些其他功能。下面给出IA-32模式下的GDT配置字段意义表：

正是由于386是在286的基础上扩展的，所以才会造成这里的段基址配置没有写在一起，而是劈开了，因为低24位就是原先286上的，而高8位则是386开始扩展的。与此同时，386也扩充了段的上限，从以前的16位扩充到了20位，那么高4位也是分开写的。

正常来说，20位的界限的话，那一个段最多只能是1MB的大小，但这对于IA-32架构的4GB内存来说显得有点局促了。为了解决这个问题，G配置位表示「粒度」，通俗来说就是Limit的单位。当G为0时，Limit的单位是Byte，那么这个段最少为1B，最多可以有1MB；而G为1时，Limit的单位是4KB，那么这个段最少有4KB，最多可以有4GB。因此，通过Limit和G两个配置项共同决定一个段的大小是多少。

最后的这个D/B就是问题的关键了，它用来表示，这个段里面是16位数据（或指令）还是32为数据（或指令）的。对于代码段，如果D/B为0，则执行时会使用ip寄存器加载16位指令，如果D/B为1，则会使用eip寄存器加载32位指令。对于栈段，表示选择使用sp还是esp寄存器。换句话说，这一项配置的就是当前段要用16位模式还是32位模式来操作。（当然，如果是数据段的话，这一项就无所谓了，毕竟数据段的操作寄存器是由程序指定的，不需要通过段配置来确定。）如果说我们要把Kernel代码用32位方式来汇编的话，那么用于保存Kernel指令的内存段就要配置为32位的（也就是D/B要写1）才行，否则跳转后就不能正常执行指令。

那么我们就把前面的代码做一个修改，给GDT重新配置上前面的字段，对于1号段来说，是我们的指令段，也就是用于加载Kernel的内容，所以我们需要把D/B位置1，而粒度、还有地址的高位部分就先保持不变即可。2号段照理说不用改变，但我们还是保持统一，把D/B位置1，代码如下：

; 1号段
; 基址0x8000，大小8KB
mov [es:0x08], word 0x1fff ; Limit=0x001fff，这是低8位
mov [es:0x0a], word 0x8000 ; Base=0x00008000，这是低16位
mov [es:0x0c], byte 0      ; 这是Base的16~23位
mov [es:0x0d], byte 1_00_1_100_0b ; P=1, DPL=0, S=1, Type=100b, A=0
mov [es:0x0e], byte 0_1_00_0000b  ; G=0, D/B=1, AVL=00, Limit的高4位是0000
mov [es:0x0f], byte 0      ; 这是Base的高8位

; 2号段
; 基址0xb8000，上限0xb8f9f，覆盖所有显存
mov [es:0x10], word 0x0f9f ; Limit=0x000f9f，这是低16位
mov [es:0x12], word 0x8000 ; Base=0x0b8000，这是低16位
mov [es:0x14], byte 0x0b   ; 这是Base的高8位
mov [es:0x15], byte 1_00_1_001_0b ; P=1, DPL=0, S=1, Type=001b, A=0
mov [es:0x16], byte 0_1_00_0000b  ; G=0, D/B=1, AVL=00, Limit的高4位是0000
mov [es:0x17], byte 0      ; 这是Base的高8位

32位Kernel

调整完GDT以后，当段选择子切换为对应段的时候，由于D/B位的原因，CPU就可以识别到，要用32位指令来解析代码了。但如果这时Kernel是没有调整过的，就会造成CPU会把16位指令「误认为」是32位指令进行解析。

; 原本的16位Kernel中的前两句
mov ax, 00010_00_0b
mov ds, ax

实际执行时会被认为：

因此，这就需要我们制定Kernel代码，要按照32位指令集来汇编，方法在前面提到过，用[bits 32]：

[bits 32] ; 这里声明按照32位指令汇编

begin:

mov ax, 00010_00_0b ; 选择2号段，以操作显存
mov ds, ax
; 打印Hello
mov [0x0000], byte 'H'
mov [0x0001], byte 0x0f
; ...

重新构建后，就可以正常运行了：

最后的运行效果如下：

由此，我们在IA-32模式下，成功打印了Hello字样。后续我们的Kernel代码都会采用32位指令来编写。

调用栈

到目前为止，我们的代码还都是线性的，也就是按照我们书写顺序，逐条来执行的。但事实上真正可用的代码是不可能做到一条线走到底的，一定会有一些封装的子模块，然后互相调用。

就像一个C语言代码，我们不可能做到所有的代码全部挤在main函数中吧？一定是说main作为入口，然后跟其他函数再进行调用和返回这样的过程。

那么在IA-32汇编中如何完成类似的操作呢？要想实现这个功能，我们大致上需要3个方面的前置知识：

1. 调用和回跳

2. 参数传递

3. 现场保留与现场还原

下面就逐一来介绍。

调用和回跳

前面我们介绍过几种跳转指令jmp，但它只能做到一次单纯的跳转，却没有办法记录我们是从哪里跳转来的，我们也就没办法做「回跳」。而要想实现类似于函数调用这样的功能，就必须要能够做到回跳。

比较容易想到的办法是，在jmp之前，我们先把当前的cs:eip的值保存在某一个位置，等后续执行完希望回跳的时候，再根据这里保存的cs:eip值跳转回来。

但这样做有两个问题。首先，cs和eip的值是没法直接读取到的，只能由CPU自己来控制。其次，多数情况下程序不会只做一层跳转和回跳，因为跳转之后还可能会再跳转，然后逐一回跳。所以固定空间记录回跳地址肯定是不可行的，必须要用到栈结构。当发生调用时，我们把当前地址压栈，而需要回跳时再弹栈并跳转，这样才能解决多层跳转问题。

IA-32汇编提供了单独的call和ret指令，用来解决上述需求。使用call指令时，会将当前的cs:eip压栈，写到ss:esp的位置，然后进行跳转。使用ret指令时，会先弹栈，然后再跳转到刚才从栈中弹出的地址，实现回跳功能。

既然用到了栈寄存器，那么肯定是需要我们要划分一片栈区才行。但目前我们划分的两个段都不太适合做栈区，毕竟1号段是指令，2号段是显存。所以看来，我们还是得补一个数据栈，用于存放指令执行过程中产生的临时数据才行。

因此，咱们就再回到MBR，配一个3号段作为数据段：

; 3号段
; 基址0x200000，大小4MB
mov [es:0x18], word 0x0400 ; Limit=0x3ff，这是低8位
mov [es:0x1a], word 0x0000 ; Base=0x00200000，这是低16位
mov [es:0x1c], byte 0x0020 ; 这是Base的16~23位
mov [es:0x1d], byte 1_00_1_001_0b ; P=1, DPL=0, S=1, Type=001b, A=0
mov [es:0x1e], byte 1_1_00_0000b  ; G=1, D/B=1, AVL=00, Limit的高4位是0000
mov [es:0x1f], byte 0x00   ; 这是Base的高8位

我们这里分配了一个数据段3号段，分了4MB的大小，所以我们把G调成了1，然后Limit配了0x3ff所以大小是1024×4KB=4MB。至于基址，反正现在也有4GB的内存空间了，我们就往高地址一点的位置放，这里选择了0x200000。

记得要调整GDT的大小：

; 下面是gdt信息的配置（暂且放在0x07f00的位置）
mov ax, 0x07f0
mov es, ax
mov [es:0x00], word 31      ; 因为目前配了4个段，长度为32，所以limit为31
mov [es:0x02], dword 0x7e00 ; GDT配置表的首地址

同时注意，要调整一下虚拟机的内存大小：

a.img:
  rm -f a.img
  bximage -q -func=create -hd=4096M $@

之后，我们就可以在Kernel里去使用了，下面给一个简单的示例供大家参考：

[bits 32]

begin:

mov ax, 00011_00_0b ; 选择3号段，数据段
mov ss, ax

mov ax, 00010_00_0b ; 选择2号段，显存段
mov ds, ax

; 压栈
push 0x0f420f41
; 弹栈
pop edx
mov [0x0000], edx ; 写入显存

hlt

times 1024-($-begin) db 0 ; 补满2个扇区

如果顺利的话，显存里应该会有0x41和0x42两个字符（也就是AB）：

我们也可以通过命令查看此时的寄存器情况：

接下来我们就做一个调用和回调的验证。我们在begin段中先打印一些字符，然后跳转到f_test段中打印一些字符，然后返回回去之后再打印一些字符，验证是否能正常发生跳转。例程如下：

[bits 32]

begin:

mov ax, 00011_00_0b ; 选择3号段，数据段
mov ss, ax

mov ax, 00010_00_0b ; 选择2号段，显存段
mov ds, ax

mov [0x0000], byte '_'
mov [0x0001], byte 0x0f
mov [0x0002], byte '1'
mov [0x0003], byte 0x0f
mov [0x0004], byte '_'
mov [0x0005], byte 0x0f

call f_test ; 调用
; 调用后会回跳回来
mov [0x0010], byte '_'
mov [0x0011], byte 0x0f
mov [0x0012], byte '2'
mov [0x0013], byte 0x0f
mov [0x0014], byte '_'
mov [0x0015], byte 0x0f

hlt

f_test:
mov [0x0020], byte '_'
mov [0x0021], byte 0x0f
mov [0x0022], byte 'f'
mov [0x0023], byte 0x0f
mov [0x0024], byte '_'
mov [0x0025], byte 0x0f
ret ; 回跳

times 1024-($-begin) db 0 ; 补满2个扇区