1. 从实模式到保护模式：一次关键的“搬家”

如果你是从《操作系统真象还原》这本书的第三章一路跟过来的，那么恭喜你，你已经成功地在实模式下“裸奔”了一回。我们亲手用汇编和BIOS中断，把MBR加载到内存，把Loader也加载进来，甚至还玩了一把显卡的文本模式，在屏幕上打印出了字符。那种感觉，就像在一个空旷的、没有任何规则的操场上自由奔跑，你可以直接读写任何内存地址，调用任何BIOS功能，简单直接，但也危机四伏。

现在，第四章“保护模式入门”摆在面前，这意味着我们要告别那个“无法无天”的操场，搬进一个现代化、有完善安保和物业管理的小区——保护模式。这个“搬家”过程，是编写一个真正现代操作系统（哪怕是玩具级的）所必须跨越的第一道，也是最关键的一道门槛。为什么必须搬？因为实模式太“原始”了。它诞生于8086那个16位、1MB内存就是天文数字的时代。在实模式下，程序可以访问整个1MB的物理地址空间，没有任何权限检查，一个程序的错误操作（比如写错了地址）可以直接导致系统崩溃，更别提运行多个程序了。这完全不符合我们对现代操作系统“稳定”、“安全”、“多任务”的基本要求。

保护模式，是Intel从80286开始引入，并在80386（也就是我们常说的IA-32架构的起点）上成熟起来的一套全新的CPU工作模式。它之所以叫“保护”，核心就在于它提供了一套硬件级别的内存访问和权限检查机制。在保护模式下，程序不再直接操作物理地址，而是通过一个叫做“段”的抽象来访问内存。CPU会严格检查每一次内存访问：这个程序有没有权限读写这个段？它试图执行的代码段是否允许执行？这就好比在小区里，你不能随便进别人家（段保护），保安（CPU）会检查你的门禁卡（段选择子）和权限。

这个“搬家”过程，或者说模式切换，本身并不复杂，但准备工作极其繁琐。你需要为这个新的“小区”建立一套完整的管理规则和基础设施，其中最重要的就是全局描述符表。你可以把它想象成小区的“业主花名册”加“房屋产权证”合集。GDT里存放着一个个“段描述符”，每个描述符精确地定义了一个内存段：它从哪里开始（基地址），有多大（段界限），是什么类型的（代码段、数据段），以及谁有权限访问（描述符特权级DPL）。CPU在保护模式下，所有对内存的访问都必须先查阅这个GDT，找到对应的“产权证”，验证权限，然后才能进行。

所以，第四章的核心任务非常明确：在Loader程序中，完成从实模式到保护模式的切换。这需要我们按顺序做好几件“苦力活”：准备好GDT，打开A20地址线（突破实模式1MB内存寻址限制的关键一步），设置控制寄存器CR0的PE位（保护模式使能位），最后执行一个长跳转，彻底进入保护模式的新世界。这个过程一旦成功，我们的操作系统开发就真正迈入了现代的门槛，后续的内存管理、任务切换、用户态/内核态隔离等高级特性，才有了赖以实现的硬件基础。接下来，我们就一步步拆解这个“搬家”流程里的每一个技术细节和容易踩坑的地方。

2. 核心基础设施：全局描述符表详解

在动手写代码之前，我们必须把GDT这个概念吃透。它是保护模式的基石，理解不清，后面的代码就是空中楼阁。

2.1 段描述符：内存段的“身份证”

在实模式下，一个段由“段基址:段内偏移”构成，段基址左移4位加上偏移就是物理地址。这种方式简单粗暴，但段基址可以任意设置，毫无约束。在保护模式下，段的概念被抽象和强化了。一个“段”现在由一个8字节（64位）的段描述符来完整描述。这8个字节里塞满了信息，其结构是由Intel手册明确定义的，我们必须严格遵守。

一个段描述符主要包含以下几类信息：

1. 段基址：32位，定义了这个段在4GB线性地址空间中的起始位置。
2. 段界限：20位，定义了这个段的大小范围。这里有个关键点：段界限的单位（粒度）由G位决定。当G=0时，单位是1字节，段最大为1MB；当G=1时，单位是4KB（一页），段最大可达4GB。这对于管理大内存至关重要。
3. 段类型：4位，用于区分代码段、数据段、系统段（如任务状态段TSS、局部描述符表LDT）等。例如，代码段是可执行的，数据段是可读写的。
4. 描述符特权级：2位，取值0~3。0是最高特权级（通常给内核），3是最低特权级（通常给用户程序）。DPL决定了访问这个段所需的最低CPU当前特权级。
5. 段存在位：1位。P=1表示该描述符有效，对应的段存在于内存中；P=0则无效，访问它会导致异常。这为虚拟内存（段被换出到磁盘）提供了硬件支持。
6. 其他属性：如是否可读/可写、是否已访问、默认操作尺寸（16位/32位）等。

把这64位信息按照特定顺序排列在内存中，就构成了一个段描述符。CPU在保护模式下，通过一个叫做段选择子的16位索引来查找GDT。选择子的高13位是索引号，指向GDT中的第几个描述符；第2位是TI位（Table Indicator），TI=0表示查GDT，TI=1表示查LDT；最低2位是RPL（请求特权级），与CPL、DPL共同决定访问是否合法。

2.2 构建我们的第一个GDT

对于入门，我们不需要一个复杂的GDT。一个最简单的、能让我们进入保护模式并执行一些代码的GDT，通常至少包含三个描述符：

1. 第0个描述符：按照Intel规定，GDT的第一个描述符必须是空描述符（全0）。这是一个安全设计，防止段选择子未初始化时误访问。
2. 代码段描述符：用于存放和执行我们的32位保护模式代码。它的类型是“可执行的、依从的代码段”，DPL=0（内核级），G=1（粒度4KB），D/B=1（32位段）。
3. 数据段描述符：用于存放数据。它的类型是“可读写的、向上扩展的数据段”，DPL=0，G=1，D/B=1。

在汇编中，我们需要手动计算并填充这8个字节。这个过程很枯燥，但又是基本功。以创建一个基址为0，界限为0xFFFFF（当G=1时，表示4GB），DPL=0的32位代码段为例，我们需要根据手册拆分基址、界限和属性，然后拼成两个双字（4字节）写入内存。

注意：在编写描述符时，字节顺序（Big-Endian vs Little-Endian）和位域的顺序非常容易出错。一个常见的技巧是，先使用一个在线的“段描述符计算器”或者写一个简单的C程序来生成描述符的十六进制值，然后在汇编中直接使用这些常量。这能避免大量低级错误，尤其是在学习阶段。

2.3 GDT的加载：lgdt指令

GDT本身只是一片普通的内存数据。要让CPU知道它，我们必须使用lgdt指令来加载全局描述符表寄存器。GDTR是一个48位的寄存器（在32位模式下），其低16位存储GDT的界限（大小-1），高32位存储GDT的线性基地址。

lgdt的操作数是一个内存地址，该地址处存放着一个6字节的数据结构，前2字节是界限，后4字节是基址。执行lgdt后，CPU就知道了GDT在哪里、有多大。但请注意，执行lgdt本身并不会让CPU进入保护模式，它只是完成了“花名册”的登记工作。

3. 切换前的关键准备：A20地址线与CR0寄存器

有了GDT，我们只是准备好了新家的“规章制度”。要真正搬家，还得打通道路，并按下切换的开关。

3.1 打开A20地址线：突破1MB的枷锁

这是一个历史遗留问题。在最早的IBM PC/AT上，为了兼容更老的软件，第21根地址线（A20）默认是被禁用的，这导致即使CPU有32位地址线，在实模式下也只能访问奇数MB边界上的内存，即0x100000以上的地址会回绕到0x0。在保护模式下，我们需要完整使用32位地址空间，因此必须打开A20。

打开A20的方法有多种，最常见的是通过键盘控制器（8042芯片）的端口0x64和0x60来操作。步骤大致是：

1. 读取0x64端口，等待输入缓冲区为空。
2. 向0x64端口发送命令0xD1，表示要写输出端口。
3. 再次等待缓冲区为空。
4. 向0x60端口发送数据，将A20位（第1位）置1。

这个过程需要严格的等待和状态检查，代码写起来有点啰嗦，但逻辑是清晰的。现代机器通常都支持更快速的“Fast A20”方式（通过端口0x92），但为了兼容性，书中和很多Bootloader（如GRUB）依然使用键盘控制器方式。

实操心得：在QEMU或Bochs这类模拟器中，A20默认可能是打开的。但我们的代码绝不能依赖这一点。必须显式地包含打开A20的代码，这是一个好习惯，能确保你的引导程序在真实硬件或不同模拟器上都能正确工作。忘记打开A20是一个经典错误，症状是进入保护模式后，在访问超过1MB的内存时出现莫名其妙的问题。

3.2 设置CR0寄存器：按下保护模式的开关

控制寄存器CR0的第0位是保护模式使能位。当PE=1时，CPU进入保护模式；PE=0时，CPU在实模式。

切换的代码非常简单：

mov eax, cr0 or eax, 0x00000001 ; 将PE位置1 mov cr0, eax

执行完mov cr0, eax这条指令的瞬间，CPU就进入了保护模式。但是，这还没完！CPU的指令预取队列和下一条指令的译码可能还是按照实模式进行的。因此，紧随其后必须有一条远跳转指令。

4. 临门一脚：远跳转与保护模式下的初始化

4.1 远跳转：清空流水线，更新CS

远跳转指令jmp会同时改变CS和EIP。在实模式下，CS是段基址；在保护模式下，CS（以及DS，ES等）变成了段选择子。这个选择子是一个索引，指向GDT中我们定义好的代码段描述符。

jmp dword SELECTOR_CODE:prot_mode_entry ; SELECTOR_CODE是代码段选择子，prot_mode_entry是32位代码标号

这条jmp指令做了两件至关重要的事：

1. 清空流水线：强制CPU刷新指令预取队列，确保后续指令按照保护模式规则译码。
2. 加载新的段描述符：将SELECTOR_CODE这个选择子装入CS寄存器，CPU会自动用这个选择子去GDT中查找对应的代码段描述符，并将其信息（基址、界限、属性）加载到CS对应的不可见部分（描述符高速缓存器）。从此以后，CS:IP的寻址将基于这个新的描述符进行。

4.2 更新数据段寄存器

进入保护模式后，实模式下设置的DS，ES，SS等段寄存器都失效了。我们必须显式地用新的数据段选择子来加载它们。

mov ax, SELECTOR_DATA ; SELECTOR_DATA是数据段选择子 mov ds, ax mov es, ax mov fs, ax mov gs, ax mov ss, ax

SS也需要加载，除非你不打算使用栈。同时，需要为栈分配空间并设置ESP。

4.3 一个完整的切换流程代码框架

将以上所有步骤整合到Loader中，代码框架如下（使用NASM语法）：

[bits 16] LOADER_BASE_ADDR equ 0x900 ; Loader被加载到的物理地址 LOADER_STACK_TOP equ LOADER_BASE_ADDR ; 栈向下生长 jmp loader_start ; 定义GDT GDT_BASE: dd 0x00000000 ; 第一个描述符必须为空 dd 0x00000000 CODE_DESC: dd 0x0000FFFF ; 段界限低16位，段基址低16位 (这里先临时填充，后面会修正) dd 0x00CF9A00 ; 段基址高8位，段属性，段界限高4位及属性 (G=1, D/B=1, P=1, DPL=00, TYPE=1010) DATA_DESC: dd 0x0000FFFF dd 0x00CF9200 ; TYPE=0010 (可读可写数据段) GDT_SIZE equ $ - GDT_BASE GDT_LIMIT equ GDT_SIZE - 1 ; 选择子 SELECTOR_CODE equ CODE_DESC - GDT_BASE SELECTOR_DATA equ DATA_DESC - GDT_BASE ; GDTR临时存储位置 gdt_ptr: dw GDT_LIMIT dd GDT_BASE loader_start: mov ax, cs mov ds, ax mov es, ax mov ss, ax mov sp, LOADER_STACK_TOP ; 1. 打印准备信息（实模式） mov si, msg_loading call print_string ; 2. 打开A20地址线 call enable_a20 ; 3. 加载GDT lgdt [gdt_ptr] ; 4. 设置CR0的PE位 mov eax, cr0 or eax, 0x1 mov cr0, eax ; 5. 远跳转，进入保护模式，并更新CS jmp dword SELECTOR_CODE:prot_mode_begin [bits 32] prot_mode_begin: ; 6. 更新数据段寄存器 mov ax, SELECTOR_DATA mov ds, ax mov es, ax mov fs, ax mov gs, ax mov ss, ax mov esp, LOADER_STACK_TOP ; 重新设置32位栈指针 ; 7. 进入保护模式后的第一件事：清屏并打印成功信息 mov byte [gs:0x00], 'P' ; 假设显存起始为0xb8000，使用gs段 mov byte [gs:0x01], 0x0A ; 黑底绿字 mov byte [gs:0x02], 'M' mov byte [gs:0x03], 0x0A ; 8. 后续可以在这里进行更多保护模式下的初始化... jmp $ ; 实模式下的子程序 enable_a20: ; ... 具体实现省略 ... ret print_string: ; ... 具体实现省略 ... ret msg_loading db "Loading and switching to PM...", 0

这段代码清晰地展示了从实模式跳转到保护模式的完整链条。每一个步骤都不可或缺，顺序也基本固定。

5. 调试与排错：保护模式切换的“暗礁”

理论很美好，但第一次尝试时，大概率会失败。屏幕可能卡住、乱码、或者直接重启。这时候，系统的调试手段非常有限，因为我们的程序是直接跑在裸机上的。以下是几个最常见的坑点和排查思路。

5.1 问题一：屏幕无任何输出，系统挂起或重启

这是最令人沮丧的情况。可能的原因和排查方向：

• GDT描述符构造错误：这是头号嫌疑犯。仔细检查每个描述符的8个字节。确保基地址、界限、属性位（特别是P位、G位、D/B位、TYPE域）完全正确。强烈建议将你计算出的描述符值，与一个可靠的参考值（如书籍示例、在线工具生成的结果）进行逐字节比对。
• lgdt加载的地址或界限错误：lgdt指令的操作数指向一个6字节的内存区域。检查这个区域的内容是否正确。界限应该是GDT_SIZE - 1，基地址必须是GDT的线性地址。在实模式下，如果你把GDT定义在Loader的代码中，那么这个地址就是GDT_BASE的偏移地址加上段基址（通常是0x9000）。计算错误会导致CPU查不到正确的描述符。
• A20地址线未成功打开：虽然很多模拟器默认打开，但代码有问题也可能导致失败。确保你的enable_a20子程序包含了完整的等待状态步骤。一个简单的测试方法是，在进入保护模式前，尝试读写一个高于1MB的地址（比如0x10_0000），看是否会发生回绕。如果回绕，说明A20没开。
• 远跳转指令错误：jmp dword是必须的，它告诉汇编器这是一个32位远跳转。选择子SELECTOR_CODE必须指向GDT中一个有效的、类型为代码段的描述符。跳转目标prot_mode_begin的地址必须在代码段的界限之内。

5.2 问题二：进入保护模式后，打印字符错乱或位置不对

这说明切换基本成功，CPU已经在执行32位代码了，但内存访问（特别是显存访问）有问题。

• 数据段选择子未正确加载：在32位代码开始处，你是否正确加载了DS，ES，GS等寄存器？如果你用GS来访问显存（0xb8000），那么GS必须加载一个有效的、可写的数据段选择子，并且该描述符的基址最好为0，界限为4GB，这样[gs:0xb8000]才能正确映射到物理地址0xb8000。
• 显存地址计算错误：在文本模式下，每个字符占2字节（ASCII码+属性）。计算屏幕位置是行 * 80 * 2 + 列 * 2。确保你的计算是正确的。
• 段描述符属性错误：数据段描述符的TYPE字段必须是可读可写的（对于显存，通常用0x92或0x93，表示可读写、向上扩展）。如果属性是只读，那么写操作会引发CPU异常。

5.3 问题三：使用Bochs进行调试

对于操作系统开发，Bochs模拟器是比QEMU更强大的调试工具。QEMU速度快，但调试信息少。Bochs自带一个调试器，可以单步执行、查看寄存器/内存/描述符表、设置断点。

当你的Loader卡住时，在Bochs中：

1. 启动Bochs并加载配置文件。
2. 在Bochs命令行中，使用sreg命令查看段寄存器及其对应的描述符信息。在保护模式切换前后分别执行，可以清楚地看到CS、DS等寄存器从实模式的值变成了选择子，并且旁边会显示其描述符的详细信息（基址、界限、属性）。这是最直接的验证手段。
3. 使用info gdt命令查看你定义的GDT内容，与你代码中定义的是否一致。
4. 使用xp /Nx ADDR命令查看物理内存，确认你的代码和数据是否被正确加载到了预期位置。
5. 单步执行（s或n）跟踪lgdt，mov cr0，jmp这几条关键指令。

通过Bochs的调试，你可以像用GDB调试普通程序一样，洞察CPU在每一个时刻的状态，绝大部分问题都能被定位。

6. 保护模式初体验：我们能做什么？

成功进入保护模式后，我们并没有立刻获得什么超能力，但世界的基础规则已经改变了。我们现在可以：

• 访问完整的4GB线性地址空间：不再受1MB限制。理论上，我们可以读写任何物理内存（前提是有对应的段描述符允许我们这么做）。
• 享受最基本的内存保护：如果程序试图访问一个段描述符规定范围之外的内存，或者试图向一个只读段写入，CPU会立刻产生一个异常。这为操作系统捕获程序错误提供了可能。
• 为后续功能铺平道路：这是实现分页机制（现代操作系统内存管理的核心）、特权级切换（用户态/内核态隔离）、多任务（任务状态段TSS）的前提。没有保护模式，这些高级特性都是无源之水。

在第四章的末尾，我们通常会在保护模式下做一件有“成就感”的小事，比如用32位汇编更高效地清屏，或者绘制一个简单的图形，来证明我们确实在新的模式下运行了。这不仅仅是演示，更是对段机制理解的一次实践。

例如，我们可以写一个用STOSD指令快速填充显存的循环，这比实模式下用INT 0x10一个字符一个字符地打印要快得多，也更能体现32位模式的优势。通过这样的实践，你会真切地感受到，我们虽然还在写汇编，但所处的环境已经是一个更强大、更有序的“新世界”了。而这个世界，正是我们构建自己操作系统的起点。