$4`
+
+很快啊！刷的一下就全部都修改好了！！！
+
+
+
+然后再把原先的图片复制到现在的 `img` 目录下，批量改一手路径，Done！
+
+谁能想到这个卡了我两年的问题，竟然能 15 分钟就搞定了！！！
+
+过于激动，遂特写此文记录一下，真是拍大腿啊！！！
diff --git a/source/_posts/os-journal-vol-1.md b/source/_posts/os-journal-vol-1.md
new file mode 100644
index 0000000..1749976
--- /dev/null
+++ b/source/_posts/os-journal-vol-1.md
@@ -0,0 +1,342 @@
+---
+title: 操统实验日志 第一章 序章
+date: 2022-07-15 08:36:46
+description: "简述: 在一切开始之前，请允许我先简要地介绍一下关于这个实验的一切。这一系列日志将是我对大二下学期操作系统实验课程中实验的一个整体回顾与记录。当然，在我写下这些的时候，我还完全不知道这份日志可以做到怎样的完成度，但我仍希望在我写下这些文字的暑假里能够以一系列详实、可复现的日志作为我对过去这一个学期里的这样一门有趣的课程的一个交代。我希望，通过这一系列日志，可以记录我完成一个简单操作系统的全部过程、记录在完成操作系统实验中可能遇到的难题和它们的解决方案，并作为一份简易操作系统的简易教程，帮助我自己或是别人复现这个实验。那么，准备好了吗？我们开始吧！"
+tags:
+ - 操作系统
+ - 大学
+categories:
+ - 技术
+---
+
+简述
+在一切开始之前，请允许我先简要地介绍一下关于这个实验的一切
+
它是关于什么的
+这一系列日志将是我对大二下学期操作系统实验 课程中实验的一个整体回顾与记录。
+当然，在我写下这些的时候，我还完全不知道这份日志可以做到怎样的完成度，但我仍希望在我写下这些文字的暑假里能够以一系列详实、可复现的日志作为我对过去这一个学期里的这样一门有趣的课程的一个交代。
+它有什么用
+我希望，通过这一系列日志，可以
+
+记录我完成一个简单操作系统的全部过程
+记录在完成操作系统实验中可能遇到的难题和它们的解决方案
+作为一份简易操作系统的简易教程，帮助我自己或是别人复现这个实验
+
+
+环境搭建
+在介绍具体的安装方法前，先在此列出所有需要的环境，方便快速对照安装
+必须的
+
+
+Linux环境 ：由于代码编译和虚拟机运行需要依赖Linux环境，因此需要准备一个Linux设备，在我的实现中使用了VMWare WorkStation与Ubuntu 20.04 LTS的组合QEMU ：安装在Linux环境下的虚拟机，用来运行编写的操作系统C/C++编译环境 ：代码编译需要，下列不完全
+
+CMake ：编写makefile需要GCC/LLVM ：编译器，在我最初的实现中使用了GCC，但是由于操作系统涉及到很多*bare-metal C++*也就是脱离C/C++标准库的代码，GCC在编译的时候会遇到一些棘手的问题，这些问题当然在LLVM中也会遇到，但相对GCC更好解决一些，故在我的实现中最后改为了使用LLVM作为编译器
+NASM ：汇编代码编译器
+建议的
+为了提升在实验过程中的编写、调试等体验，以下环境是可选 的，并且在我的实现中安装 的
+
在Windows下
+
+VSCode ：现代IDE，可选安装如下插件
+
+ASM Code Lens或其他asm插件 ：提供asm语法高亮C/C++ ：提供C/C++语法高亮CMake, CMake Language Support, CMake Tools ：提供CMake支持Hex Editor ：调试时查看生成的二进制文件GitLens ：优秀的Git可视化管理工具，提供了比VSCode原生更丰富的功能，包括分支等Remote-SSH等Remote家族 ：提供远程连接Linux环境支持，使得可以在Windows环境下直接编写Linux环境中的代码并且进行编译等基本操作
+Windows 11 ：提供了更漂亮的PWS/CMD工具Windows终端 ：Microsoft Store中提供的开源的漂亮的命令行工具，用于连接Linux shellIDA ：在调试bug的时候用于打开.o文件看看里面发生了什么奇怪的错误
+在Linux下
+
+git ：不多解释了，基本上啥都要用到这个ZSH ：终端美化
+
+pwndbg ：好用的GDB工具
+Ubuntu安装指南
+Ubuntu版本以进行实验时的20.04LTS版本为例，其他版本的安装方式基本相同
+
前往Ubuntu官网 处下载对应版本的镜像文件
+
+
+
下载得到一个文件名如ubuntu-20.04.4-desktop-amd64.iso的镜像文件
+
有了镜像文件以后，就可以进入下一步，在虚拟机中使用该镜像安装系统了
+
+
由于我在实验中使用的是VMWare Workstation，此处以VMWare Workstation Pro 16 为例进行介绍，其他虚拟机可以使用搜索引擎 查询对应Linux配置方式
+
+
在VMWare Workstation中安装Ubuntu的步骤如下：
+
+创建新的虚拟机
+配置选择自定义（高级）
+硬件兼容性选择Workstation 16.2.x
+选择稍后安装操作系统
+安装的系统选择Linux及Ubuntu 64位
+设置名称位置
+根据CPU设置处理器内核数
+内存大小设置为4~8GiB
+网络类型设置为NAT
+I/O控制器类型选择为LSI Logic
+虚拟磁盘类型选择SCSI
+磁盘选择创建新虚拟磁盘
+自由设置其他内容
+
+
硬件配置如下
+
+
为了从上一步下载的镜像文件中安装系统，需要编辑虚拟机设置，在CD/DVD的连接栏选择使用ISO映像文件并设置为上一步中下载的镜像文件，同时勾选启动时连接
+
如果设备中没有找到CD/DVD，需要通过下方添加添加一个CD/DVD驱动器
+
+
在启动虚拟机之前，由于在某些情况下虚拟机的显示分辨率会太低导致显示不出安装界面的下一步按钮，因此在启动之前可以在虚拟机设置中调整显示器分辨率。
+
这里将显示器设备中的监视器 一栏设置为指定监视器设置 并设置最大分辨率为当前显示器的分辨率
+
如果这一步没有产生效果，并且在安装时确实遇到了无法点击按钮的情况，可以在第一步选择Try Ubuntu进入桌面
+
之后右键在Display Settings中设置分辨率和缩放
+
如果没有合适的缩放，可以开启Fractional Scaling进行小数位缩放，可以多出125%、150%和175%的缩放比设置
+
+
设置好后启动虚拟机，进入.iso文件中的系统，启动后会自动进入Ubuntu安装程序
+
如果这一步无法启动，检查CD/DVD是否设置为启动时连接
+
+
安装步骤如下：
+
+安装程序中选择Install Ubuntu进入安装
+检查键盘布局是否正确，具体测试方式为在输入栏中测试键盘各个键输入是否符合预期
+选择Minimal installation进行最小安装，同时可以取消勾选Download updates while installing Ubuntu，避免因为遇到无法访问的情况卡住安装，更新可以在后续换源后进行，这里可以不着急
+简便起见，在Installation type步骤可以直接选择Erase disk and install Ubuntu，如果有自己的分区喜好，可以选择Something else，具体分区方式网上 有完备介绍，可以跟随教程设置，完成后选择Install Now
+时区选择Shanghai
+设置用户名密码
+点选Continue执行安装即可
+
+
在安装完成之后，系统会提示是否重启系统，由于需要关闭CD/DVD驱动器以免再次进入安装系统，在这一步不进行重启系统，关闭该通知进入系统桌面，右上角菜单选择关机，关机过程中会有一个提示移出安装媒介并按回车键，直接按回车关机即可
+
关机后进入编辑虚拟机设置 页，移出CD/DVD设备或是取消勾选该设备的启动时连接
+
完成后启动虚拟机进入安装好的系统，开机后使用安装时设置的用户密码登录，初次启动会有一些提示框，基本一直下一步即可进入桌面
+
进入系统以后同样会遇到分辨率问题，可以参照上文调整分辨率和缩放
+
+
此处以清华源 为例进行配置，同样也可以选择企业提供的镜像源，如阿里源 ，在一定程度上企业源会比大学镜像源更加可靠，可以酌情选择
+
+
换源实质上就是更改系统所使用的软件源的配置文件，因此要做的事就只有两件：
+
+去使用的源的网站获取当前版本的配置文件
+修改系统中原本的配置文件
+
+
清华源 中给出的Ubuntu 20.04 LTS 版本的配置文件如下，复制该配置文件内容
+
1 2 3 4 5 6 7 8 9 10 11 12 13 # 默认注释了源码镜像以提高 apt update 速度，如有需要可自行取消注释 deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-updates main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-updates main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-backports main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-backports main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-security main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-security main restricted universe multiverse # 预发布软件源，不建议启用 # deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-proposed main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-proposed main restricted universe multiverse
+
对于不同版本的Ubuntu，配置文件会有所不同，体现在链接后面的focal字样，该字段是Ubuntu的版本号，例如Ubuntu 18.04的版本号就是仿生鱼bionic而Ubuntu 22.04LTS版本号为jammy
+
如果选择了错误的配置文件，会使得后续apt update环节出现奇怪的错误，因此一定要选择版本对应的配置文件
+
+
在终端中输入
+
1 sudo vim /etc/apt/sources.list
+
如果还没有安装vim，可以
+
+改成使用vi而不是vim，在换源后再安装vim
+执行sudo apt-get update && sudo apt-get install vim安装vim继续
+
+
+
首先注释掉原先的内容，然后在文件尾追加上文中复制的配置文件，之后保存退出
+
在vim中使用I进入编辑模式，使用ESC退出编辑模式
+
在非编辑模式下输入:wq保存并退出，输入:q退出，输入:q!放弃更改退出
+
+
在vim中可以使用如下方式批量添加注释
+
+Ctrl+V进入列选择模式J / K / ↓ / ↑ 移动光标选中行Shift+I（这一步会让光标移到选中列的第一行第一个字符之前，但实际上光标在所有选中行的第一个字符之前）Shift+3（输入注释符#）ESC退出
+
+
保存了新的配置文件以后，执行如下命令执行更新
+
+
执行了更新之后就完成了换源的全部步骤，可以进入下一步安装其他软件环境了！
+
+
终端执行以下命令
+
1 2 sudo apt install binutils sudo apt install gcc
+
或者使用一行命令
+
1 sudo apt install binutils && sudo apt install gcc
+
检查是否安装成功
+
+
如果输出gcc的版本号则表明安装成功
+
+
首先检查已经安装的nasm版本
+
+
如果已经是2.15^版本则可以跳过本节，如果不是的话则需要安装2.15^版本的nasm
+
首先根据网上教程 的指引，下载压缩包
+
1 2 $ wget https://www.nasm.us/pub/nasm/releasebuilds/2.15.05/nasm-2.15.05.tar.xz Download time (Average speed) - `nasm-2.15.05.tar.xz` saved [995732/995732]
+
然后进行解压和配置文件生成
+
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 $ tar -xvf nasm-2.15.05.tar.xz nasm-2.15.05/ nasm-2.15.05/AUTHORS ... nasm-2.15.05/doc/nasmlogw.png $ cd nasm-2.15.05/ $ ./configure checking for prefix by checking for nasm... no ... configure: creating ./config.status config.status: creating Makefile config.status: creating doc/Makefile config.status: creating config/config.h
+
上面的bash代码不要直接复制，其包含了输出的显示
+
只有 $ 后的内容才需要输入，其他的内容为预期的输出显示
+
+
最后进行make安装
+
+
+
如果打算使用LLVM作为编译器，则可以参照官网安装指南 进行安装，下面给出脚本安装方式
+
1 sudo bash -c "$(wget -O - https://apt.llvm.org/llvm.sh) "
+
安装后的clang可能不叫作clang，因此直接执行clang -v可能会报错未安装
+
输入clang后按TAB两次可以看到安装了的clang版本，例如clang-14和clang++-14，这样输入clang-14 -v就能够显示版本了
+
之后在编写makefile的时候也要注意不要将编译器写为单独的clang，而是带后缀的安装了的版本
+
+
+
终端执行以下命令
+
1 2 3 4 5 6 7 8 9 10 sudo apt install git sudo apt install qemu sudo apt install cmake sudo apt install libncurses5-dev sudo apt install bison sudo apt install flex sudo apt install libssl-dev sudo apt install libc6-dev-i386 sudo apt install gcc-multilib sudo apt install g++-multilib
+
或是输入一行指令
+
1 sudo apt install git && sudo apt install qemu && sudo apt install cmake && sudo apt install libncurses5-dev && sudo apt install bison && sudo apt install flex && sudo apt install libssl-dev && sudo apt install libc6-dev-i386 && sudo apt install gcc-multilib && sudo apt install g++-multilib
通过设置Ubuntu环境下的SSH，可以让Windows能够通过SSH连接到Ubuntu环境的shell，从而可以在Windows环境下完成大部分操作
+
除此之外，通过VSCode中的Remote插件，可以在Windows环境下编写Ubuntu中的文件
+
如果你希望在Ubuntu中完成所有代码的编写，则这一步不是必须的
+
+
通过如下命令安装ssh
+
1 sudo apt-get install ssh
+
之后配置密钥登录所必须的文件目录和文件并设置权限
+
1 2 3 4 mkdir ~/.ssh && cd ~/.sshtouch authorized_keyschmod 600 ~/.ssh/authorized_keyschmod 700 ~/.ssh
+
通过修改sshd配置文件关闭密码登录并打开密钥登录
+
打开sshd_config文件
+
1 sudo vim /etc/ssh/sshd_config
+
之后在# Authentication:下修改如下键值，同时如果有注释则关闭注释
+
1 2 PubkeyAuthentication yes PasswordAuthentication no
+
保存退出后重启sshd服务
+
+
之后，需要在VMWare Workstation里转发22端口到虚拟机
+
为了完成这个任务，需要先获取虚拟机的ip地址
+
1 2 3 4 $ ip a ... inet 192.168.XXX.XXX/24 brd 192.168.XXX.255 scope global dynamic noprefixroute ens33 ...
+
可以看到输出中给出的ipv4地址，这里假设为192.168.85.130，记住该地址
+
进入VMWare Workstation中的 编辑-虚拟网络编辑器-更改设置-VMnet8 NAT模式-NAT设置 ，添加端口转发规则
+
+
+
+主机端口
+类型
+虚拟机IP地址
+虚拟机端口
+描述
+
+
+
+
+22
+TCP
+192.168.85.130
+22
+SSH
+
+
+
+
保存并应用设置就完成了端口转发的添加
+
最后，为了能够让Windows能够顺利连接上虚拟机，需要在Windows环境下生成密钥并且拷贝公钥到上文中创建的authorized_keys文件中
+
+
首先，需要在Windows环境下安装OpenSSH，参照Microsoft官方文档 给出的指南，可以使用Powershell安装OpenSSH
+
以管理员身份运行Powershell并且检查OpenSSH的安装情况
+
1 Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'
+
如果两者均没有安装，则会返回如下输出
+
1 2 3 4 5 Name : OpenSSH.Client~~~~0.0.1.0 State : NotPresent Name : OpenSSH.Server~~~~0.0.1.0 State : NotPresent
+
之后，根据需要安装对应未安装的组件
+
1 2 3 4 5 Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0 .1.0 Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0 .1.0
+
这两者都应该返回如下输出
+
1 2 3 Path : Online : True RestartNeeded : False
+
之后，使用终端生成密钥
+
1 2 3 ssh-keygen -t rsa ssh-keygen -t ed25519
+
根据提示设置对应的文件位置（默认为%USERPROFILE%\.ssh\id_rsa）以及密码
+
然后使用cat命令显示公钥内容，假定公钥文件为C:\Users\Linloir\.ssh\id_ed25519.pub
+
1 cat C:\Users\Linloir\.ssh\id_ed25519.pub
+
会返回一个类似如下的输出
+
1 ssh-ed25519 AAAAC3N******************TzC6 linloir@******
+
拷贝该输出，并回到Linux操作
+
如果希望在Windows和Linux虚拟机间复制内容，可以在VMWare中安装VMWare Tools或Open VM Tools
+
+
如果VMWare Tools安装选项为灰色，可以参照网上的博客 进行如下操作
+
+关闭虚拟机
+打开虚拟机设置
+如果在前序步骤删除了CD/DVD设备，则添加回来
+取消勾选CD/DVD设备的 启动时连接 ，同时勾选 使用物理驱动器-自动检测
+重启虚拟机
+
+
+
在测试过程中，安装VMWare Workstation自带的VMWare Tools会提示建议安装Open VM Tools
+
可以结束安装并参照官方文档 或是Github页面 中的指南使用sudo apt-get install open-vm-tools-desktop安装
+
+
在Linux终端中使用vim修改authorized_keys文件
+
1 vim ~/.ssh/authorized_keys
+
进入编辑模式粘贴上文中复制的密钥内容后保存退出
+
最后可以在Windows环境下使用下述命令测试连接到虚拟机
+
在<username>中填写Linux用户名，<ip>填写前文中获得的虚拟机ip地址
+
+
+
如果连接成功，则证明完成了SSH的全部配置内容，同样，也完成了Ubuntu环境的全部配置！
+
接下来，可以直接进入下一节或是跟随教程完成Windows下使用工具的配置和安装
+
Windows环境配置指南
+如果希望在Linux环境下完成所有代码编写与调试，可以跳过此节
+
为了提升代码编写体验，在本节中将会介绍如何在Windows环境下配置和使用VSCode以及其插件，从而能够在Windows环境下使用VSCode编写Linux中的代码
+同样，还会介绍通过Windows终端连接Linux终端的方式，并在Windows环境下配置Linux环境中的ZSH终端以及powerlevel10k主题
+前往VSCode官网 下载并安装VSCode
+
安装完成后进入VSCode页面，在左侧栏中有一积木样图标，点击进入VSCode的插件安装页
+
搜索并安装以下插件，具体安装的插件可以根据自己的喜好选择，其中Remote家族为连接虚拟机所需要的插件
+
+C/C++ (Microsoft)
+Chinese (Simplified)(简体中文) Language Pack For Visual Studio Code (Microsoft)
+CMake Tools (Microsoft)
+Hex Editor (Microsoft)
+Remote - SSH (Microsoft)
+Remote - SSH:Editing Configuration Files (Microsoft)
+The Netwide Assembler (NASM) (Right)
+
+
在完成了Remote家族插件的安装后，侧边栏会有一远程连接的图标，点击可以进入远程资源管理器
+
选择SSH Target以添加虚拟机，之后在SSH TARGETS菜单处点击添加键，在弹出窗口中输入
+
+
在弹出的Select SSH configuration file to update页面中选择默认选项，也即直接按回车
+
之后在左侧SSH TARGETS菜单栏能够看到新添加的地址，鼠标移至其上方，点击其右侧文件夹图标在新窗口中打开
+
在Select the platform for the remote host窗口中选择Linux
+
之后输入在上文 配置SSH 中生成密钥步骤中设置的密码即完成连接
+
快试试在侧边栏中的文件页面中打开Ubuntu中的项目文件夹吧！
+
在我的实验中，在Windows中使用了Windows Terminal，在Linux中使用了ZSH+powerlevel10k的组合，你也可以根据你的喜好设置自己的终端和主题
+
+
首先，在Windows Terminal中使用ssh连接到虚拟机终端
+
之后，根据ZSH Wiki页面 的教程安装ZSH
+
1 2 3 4 5 6 7 8 9 10 11 12 $ sudo apt install zsh $ zsh --version zsh 5.8 $ chsh -s $(which zsh) $ exit
+
然后重新使用ssh登录，初次进入会进行设置，可以根据自己的喜好进行设置或者直接选择Populate your ~/.zshrc with the configuration recommended by the system administrator and exit进行默认设置
+
+
之后依据Oh My Zsh官网 来安装Oh-My-Zsh框架
+
1 sh -c "$(wget https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh -O -) "
+
完成设置就代表着Zsh安装完成，可以进行后续主题安装
+
+
在安装powerlevel10k主题前，需要安装其依赖的字体
+
+
双击打开下载的字体文件进行安装，之后进入Windows Terminal → 设置 → 配置文件 → 默认值 → 外观 → 字体，选择MesloLGS NF字体
+
然后使用git安装该主题
+
1 git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME /.oh-my-zsh/custom} /themes/powerlevel10k
+
可以使用gitee加速下载
+
1 git clone --depth=1 https://gitee.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME /.oh-my-zsh/custom} /themes/powerlevel10k
+
在~/.zshrc中设置ZSH_THEME="powerlevel10k/powerlevel10k并重启Zsh
+
+
之后根据设置向导设置主题即可得到一个漂亮的终端啦
目前为止，环境已经基本配置完成了
+
关于本章
+本章的序 将会首先介绍操作系统是如何运行起来的，并在此基础上介绍实现一个完备的操作系统实验需要实现哪些方面，以及这些部分的先后顺序和依赖关系
+由于这份文档我并不打算作为一份完备的教程文档来编写，因此语言方面的介绍会相对简略或是跳过，对应的详细介绍可以参考学校的同步教程
+在本章的后半部分 ，将会介绍MBR和中断的相关知识，记录如何编写MBR、测试使用BIOS启动MBR引导程序并通过中断输出字符串进行测试
+在下一章节，将会介绍如何从MBR中加载Bootloader并进行更复杂的启动准备操作
+序
+计算机是如何启动的
+这里介绍的启动方式是x86架构下的BIOS启动过程，UEFI启动或是在arm架构下启动则是另一种启动方式 搜索引擎 进行了解
+
经典的BIOS启动过程分为了如下五个步骤：
+
+
+加电开机 ：0xFFFF0需要注意的是，这些指令并不需要我们来编写，它们位于系统的BIOS地址范围内 。在 0xFFFF0BIOS启动 过程
+
+
+BIOS启动 ：(Power-On-Self-Test) ，检查系统的关键设备比如内存、显卡等是否正常工作。如果检测到这些关键设备存在致命问题，则会通过蜂鸣音来报告错误，蜂鸣音的长短即次数对应错误类型。在完成自检之后，BIOS就会进入下一步加载MBR并启动
+
+
+加载MBR ：(Master-Boot-Record) ，它存储在存储设备的首扇区512字节。MBR包含了如下的三个部分：
+
+启动相关的代码 ：磁盘分区记录 ：结束标记 ：(Magic number) ，通过 0xAA55
+因此在BIOS启动之后，它便会根据设置好的引导顺序，按排位顺序检查引导序列中对应地存储设备是否可以启动 （也就是检查MBR的最后两个字节是否是0x55AA） ，如果满足要求，则复制这512字节到内存中的 0x7C00
+
+
+
+加载bootloader ：0x7C00
+
+
+加载kernel ：
+当进入内核以后，操作系统就基本完成了启动的过程，内核会完成后续操作系统的初始化操作，这些将留到编写内核的时候再详述
+
+
+启动过程不是绝对的，从MBR之后的启动方式可以按照自己的设计进行
+
前序知识
+在这一章节中将会介绍在后续实验中将会大量使用的基础知识，包括了nasm的语法以及常用概念的解释等
+这些内容大部分在用到的时候也会在文章中再次出现
+
nasm语法
+IA-32 处理器
+
+
IA-32处理器有8个通用寄存器eax, ebx, ecx, edx, ebp, esp, esi, edi
+
除此之外，还有6个段寄存器cs, ss, ds, es, fs, gs
+
以及标志寄存器eflags和指令寄存器eip
+
更多的寄存器 cr0，存储页目录表基地址的cr3、存储产生缺页错误的地址的寄存器cr2等
+
+
在nasm中，除了可以直接使用上述的名字访问寄存器的全部内容，还提供了访问部分寄存器低位数据的访问方式：
+
+
+
+[31:0]
+[15:0]
+[15:8]
+[7:0]
+
+
+
+
+eaxaxahal
+
+ebxbxbhbl
+
+ecxcxchcl
+
+edxdxdhdl
+
+esisi–
+–
+
+
+edidi–
+–
+
+
+espsp–
+–
+
+
+ebpbp–
+–
+
+
+
+
同时，nasm还有一套约定俗成的规矩，用来指定寄存器的作用
+
其中，有一些规定是被 默认使用 的：
+
+
+
+寄存器
+作用
+
+
+
+
+eax在乘法和除法指令中被自动使用C或C++函数的返回值放置在eax中
+
+
+ecx在循环 (loop) 指令中被默认为计数器ecx中，loop指令只有当ecx为0时停止
+
+
+esp在对栈进行push和pop操作时，会自动从esp中取基地址push eax实际上相当于sub esp, 4，mov eax, [esp]
+
+
+esi, edi用于内存数据高速传送，本次实验中用不到
+
+
+ebp通常用于在栈上取数据时使用，一般不用于算数或是数据传输 C++与asm混编后会经常遇到关于ebp的内容
+
+
+cs16位 代码段寄存器
+
+ds16位 数据段寄存器
+
+ss16位 栈段寄存器
+
+
+
还有一些类似于习惯的规定，似乎不遵守它们也不会让程序出现错误：
+
+
+
+寄存器
+作用
+
+
+
+
+eax一般用于算数运算add eax, 4，因而也叫做累加寄存器
+
+
+ebx基地址寄存器，用于在取址时提供基地址mov eax, dword [ebx + 2]为取出ebx + 2位置上32位的数据放入eax
+
+
+edx数据寄存器
+
+
+esi源变址寄存器，用于在取值时提供偏移的地址mov eax, dword [ebx + esi + 2]或是mov eax, dword [esi + 2]
+
+
+edi目的变址寄存器，用于在取值时提供偏移的地址mov dword [edi + 2], eax
+
+
+es, fs, gs16位 附加段寄存器，用来存放其他的段
+
+
+
寻址 寻址 相关的内容，可以前往寻址页面查看
+
+
段寄存器 保护模式 相关的内容，可以前往基本概念 查看
+
标识符是我们取的名字，用来表示变量、常量、过程、函数或代码标号
+
标识符满足如下要求和特性：
+
+至少1个字符，最多247个字符
+大小写不敏感
+第一个字符必须是字母、_或是@，后续字符可以包含数字
+不能与保留字相同
+
+
下面是一些有效的标识符
+
1 2 3 4 5 6 var1 Count _main MAX open_file @myfile
+
下面是一些使用标识符的示例
+
1 2 3 4 5 6 function_1: ret count dw 100
标号是充当指令或数据位置标记的标识符，可以直接将其理解为一个地址值，指向的是其之后指令或是数据的起始地址
+
例如
+
+
中count指向的就是其之后4字节长度的数据100的起始地址
+
如果有更长的数据，则可以这样写
+
+
在.asm文件中，可以视为地址是从第一行代码向下增长的
+
+
这样写相当于声明了一个值为0x880000000000的数据
+
其低4字节为dw 0所声明的值，高2字节为dd 0x8800声明的值
+
而pgdt指向其低四字节的起始地址，也即该数据最低字节的地址
+
IA-32为小端序 (little-endian) 其标识符指向的是它的最低字节数据地址
+
+
标号也可以用于声明相当于C语言中数组的数据项
+
数据项之间以,分隔，标号指向第一个数据项最低字节的地址
+
1 2 array dw 1024 , 2048 dw 4096 , 8192
+
上述代码按照1024，2048，4096，8192的顺序存放数据，同时array指向1024
+
标号也可以用来在过程中添加标记以方便跳转
+
1 2 3 4 Stage_1: mov eax , ebx jmp Stage_1
+
这里，Stage_1并不会编译成汇编代码，而是会编译为mov eax, ebx这一步的地址值，jmp Stage_1相当于跳转到mov eax, ebx这句执行
+
标号后面的换行和空格并不会影响标号的值 Stage_1: mov eax, ebx中Stage_1跟上面的代码拥有一样的标号值
+
如何理解寻址 寄存器寻址 可以理解为代码通过寄存器获得数据
+
+
nasm有六种寻址方式，分别为
+
+
+寄存器寻址 ：操作数存放在寄存器中，从寄存器中取得数据
+
+
+立即数寻址 ：直接将立即数作为操作数
+
+
+直接寻址 ：从立即数或是标号指向的地址处取得数据
+从立即数指向的地址取得数据
+1 2 3 4 5 6 mov eax , dword [0x5C00 ]
也可以从标号指向的地址取得数据
+1 2 tag dw 0x20 mov eax , dword [tag]
+
+基址寻址 ：将基址寄存器所储存的数值视为地址并从该地址处取得数据
+基址寻址类似于数组的寻址，基址寄存器只能是寄存器bx或bp
+1 2 3 tag dw 0x20 mov ebx , tag mov eax , dword [ebx ]
基址寻址也可以使用基址寄存器和立即数来构成真实的偏移地址
+1 2 3 4 5 6 tag dw 0x20 mov ecx , tagsub ecx , 4 mov ebx , ecx mov eax , dword [ebx + 4 ]
+
+变址寻址 ：使用变址寄存器和立即数来构成真实的偏移地址，从该地址处取得数据
+变址寻址与基址寻址相似，变址寄存器只能是si或di
+1 2 mov eax , dword [esi + 4 * 4 ] mov dword [edi ], 0x5
+
+基址变址寻址 ：通过基址寄存器、变址寄存器、立即数来构成真实的偏移地址，从该地址处取得数据
+1 mov eax , dword [ebx + esi + 4 * 5 ]
+
+
不够用的地址？ 实模式 下，IA-32处理器使用 20位 的地址线2 20 = 1 M B 2^{20} = 1MB 2 20 = 1 MB 0x0000到0xFFFF16位 ，意味着使用基址、变址寻址的时候没办法访问到所有的内存地址
+
+
为了解决这个问题，工程师提出了 段 的概念，使用了段地址之后，实际的地址可以表示为
+
A d d r = ( S e g m e n t A d d r < < 4 ) + S h i f t A d d r Addr = (SegmentAddr << 4) + ShiftAddr
+ A dd r = ( S e g m e n t A dd r << 4 ) + S hi f t A dd r
+
也就是物理地址由左移4位的段地址加上偏移地址组成，这个偏移地址就由标号或是寄存器提供
+
此段非彼段 实模式 下的问题，此时的段是用来解决寄存器不足以访问所有的内存地址的问题保护模式 中，还将看到另一个段定义，它与本节所述的段并不是同一个概念
+
+
段地址的使用一般出现在使用[]来寻址的操作中，因为在这种情况下[]内表示的是一个地址，而这个地址很可能由一个16位的寄存器或是标号提供
+
添加了段地址的寻址语法为
+
+
在默认的情况下，系统会根据使用的标号和寄存器自动指定段地址，指定的段地址与使用的基址寄存器有直接关系
+
由于这里讨论的是实模式，所以只讨论16位寄存器
+
+
对于bx、si、di，默认的段寄存器为ds
+
对于bp，默认的段寄存器为ss
+
对于基址变址寻址方式，默认的段寄存器以基址寄存器的使用为准
+
1 2 3 4 5 6 7 8 9 10 11 mov ax , word [tag]mov ax , word [ds :tag]mov ax , word [bx ]mov ax , word [ds :bx ]mov ax , word [bp + si + 4 * 4 ]mov ax , word [ss :bp + si + 4 * 4 ]
下文中可能用到的标识符解释如下
+
+
+
+标识符
+意义
+
+
+
+
+reg
+寄存器
+
+
+imm
+立即数
+
+
+immX
+X位立即数
+
+
+tag
+标号
+
+
+mem
+使用寻址方式取得的内存数据，例如[ebx]
+
+
+
+
mov add/sub imul/idiv shl/shr inc/dec 逻辑操作 跳转指令 push/pop in/out 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 mov [dest], [src]mov <reg>, <reg/imm>mov <reg>, <size> [<reg/imm/tag>]mov <size> [<reg/imm/tag>], <reg/imm>mov eax , ebx mov eax , 0x20 mov eax , dword [ebx ]mov eax , dword [0x8800 ]mov eax , dword [tag]mov dword [eax ], ebx mov dword [eax ], 0x20 mov dword [0x8800 ], ebx mov dword [0x8800 ], 0x20 mov dword [tag], ebx mov dword [tag], 0x20
1 2 3 4 5 6 7 8 9 10 11 12 13 add /sub [dest & op1], [op2]add /sub <reg>, <reg/imm/mem>add /sub <mem>, <reg/imm>add eax , ebx sub eax , 0x20 add eax , dword [tag]sub dword [tag], ebx add dword [tag], 0x8800
imul完成整数乘法操作
+
1 2 3 4 5 6 7 8 9 10 11 12 13 imul [dest & op1], [op2]imul [dest], [op1], [op2]imul <reg>, <reg/mem>imul <reg>, <reg/mem>, <imm>imul eax , ebx imul eax , dword [var]imul esi , edi , 25 imul esi , dword [shift], 4
+
idiv完成整数除法操作
+
idiv只有一个操作数，此操作数为除数，而被除数则为edx:eax中的内容 (一个64位的整数)
+
操作的结果有两个部分
+
+商 ：存放在eax寄存器中余数 ：存放在edx寄存器中
+
1 2 3 4 5 6 7 8 9 idiv [divisor]idiv <reg/mem>idiv ebx idiv dword [var]
shl，shr表示逻辑左移和逻辑右移，空出的位补0
+
1 2 3 4 5 6 7 8 9 10 11 12 shl /shr [target], [shift]shl /shr <reg/mem>, <con>shl /shr <reg/mem>, cl shl eax , 5 shr dword [ebx ], 4 shl eax , cl shr dowrd [ebx ], cl
inc，dec指令分别表示自增1或自减1
+
1 2 3 4 5 6 7 8 9 inc /dec [target]inc /dec <reg/mem>inc eax dec byte [tag]
and, or, xor分别表示将两个操作数逻辑与、逻辑或和逻辑异或后放入到第一个操作数中
+
1 2 3 4 5 6 and /or /xor [dest & op1], [op2]and /or /xor <reg/mem>, <reg/imm>and /or /xor <reg>, <mem>
+
not表示对操作数每一位取反，neg表示对操作数取负
+
1 2 3 4 5 6 7 not [target]neg [target]not <reg/mem>neg <reg/mem>
jmp指令是无条件跳转指令，跳转到代码标号的指令处执行
+
1 2 3 4 5 6 7 8 jmp [addr]jmp <tag>jmp func_1
+
除了无条件跳转指令外，还有条件跳转指令
+
1 2 3 4 5 6 7 je <tag> jne <tag> jz <tag> jg <tag> jge <tag> jl <tag> jle <tag>
+
在使用条件跳转指令之前，要先进行判断，判断使用的是cmp指令
+
1 2 3 4 5 6 7 8 9 cmp [op1], [op2]cmp <reg/mem>, <reg/imm>cmp <reg>, <mem>cmp eax , 10
+
一个条件跳转的示例如下，其展示了一个不适用loop指令循环10次的简单实现
+
1 2 3 4 5 6 7 8 xor eax , eax mov eax , 10 loop_start: dec eax cmp eax , 0 je exit jmp loop_start exit:
push和pop为栈操作，负责将寄存器值压栈、弹栈
+
in、out为端口读写操作，它们的操作数非常严格
+
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 in [dest], [src] out [dest], [src] in al /ax /eax , <imm8/dx > out <imm8/dx >, al /ax /eax in al , 0x21 mov dx , 0x379 in al , dx out 0x21 , al mov dx , 0x378 out dx , al
+
其中，al/ax/eax根据端口位宽设置，如果对8位端口指定了16位输入/输出，则会连带该端口的下一个端口一并进行输入/输出
基本概念
+
+
实模式是所有的x86处理器都有的一个16位运行模式
+
这个模式是为早期的操作系统设计的，它的出现远远早于保护模式
+
即使现在的操作系统已经运行在保护模式下了，但是处于兼容性考虑，所有的现代操作系统都需要先从实模式开始运行，然后再切换到保护模式
+
在实模式下，CPU只有20根地址线可用，也即可用内存为
+
2 20 B y t e = 1 M i B 2^{20}Byte = 1MiB
+ 2 20 B y t e = 1 M i B
+
为了让16位寄存器能够对全部内存地址空间进行取址，额外引入了段寄存器cs、ss、ds和es、fs、gs，地址的表示由段地址和寄存器表示的偏移地址组合而成
+
R e a l A d d r e s s = ( S e g m e n t A d d r e s s < < 4 ) + S h i f t A d d r e s s RealAddress = (SegmentAddress << 4) + ShiftAddress
+ R e a l A dd ress = ( S e g m e n t A dd ress << 4 ) + S hi f t A dd ress
+
段地址保存在段寄存器中，其中es、fs和gs为附加段寄存器，可以由用户自行指定
+
保护模式是目前英特尔处理器主流的运行模式，在保护模式中，处理器以32位模式运行，所有的寄存器也都为32位
+
为了进入保护模式，操作系统需要在实模式下进行一系列操作：
+
+设置全局描述符表
+关闭中断
+开启第21根地址线
+打开保护模式开关
+执行一次远跳转送入代码段选择子
+
+
具体的切换方式让我们留到实验中再行讲解
+
保护模式之所以叫做保护模式，因为其引入了 “段” 的概念，每一个程序都有它自己的段，一旦程序错误地访问其他段的地址空间，那么CPU就会产生异常
+
段 (segment)
+
+
+
也就是说，可以认为保护模式保护的是地址空间，防止程序代码错误地访问了非它自己的段地址空间，造成越界访问
+
为了让CPU知道段的范围，工程师引入了全局描述符表 的概念
+
全局描述符表可以理解为一段连续的内存 ，类似于数组，其中存储了全局描述符 ，每个描述符都对应了一个段的设置
+
为了取出对应的全局描述符，就如同用下标从数组中获取数据那样，CPU使用选择子从全局描述符表中获取描述符
+
选择子除了包含了取出描述符所需要的下标信息，还包含了一些权限信息等，这些选择子会被存储在段寄存器中
+
更多的保护内容
+
+
操作系统的最终目的是完成用户的任务，但很显然，用户不会时时刻刻都有需要操作系统完成的任务，同时，当用户没有向操作系统提交任务的时候，它应当去干点别的而不是傻傻地待在原地等着用户提交任务——这也就是中断的意义
+
可以把操作系统想象成一个忙碌的打工人，当你向他提交了任务以后，他便会开始完成你提交的任务。但如果在他进行到一半的时候，你突然又想让他干点别的，该怎么办呢？对了！就是拍拍他的肩膀，说：“伙计，先停停手上的活，把这件事情做了，然后再回来做现在的活儿。”
+
中断对于操作系统的作用也正是这样，通过中断，可以让CPU暂停当前正在运行的代码，转而对产生中断的信息进行处理，当处理完后再返回运行原先的代码
+
通过中断，可以让操作系统在等待用户/内核打断的同时进行其他的任务，而不需要在原地循环等待用户的下一步指令
+
又由于操作系统实质就是无数个 中断-处理-返回 的过程，所以可以说这就是操作系统进行任务的最根本方式，所有的操作都要经由中断来实施，所以可以说 “操作系统是由中断驱动的”
实验路线
+在这一步中，需要搭建实验所必需的Linux环境以及虚拟机qemu和C、C++、asm编译器等
+
+
由于实验的第一部分 ( 编写MBR ) 就需要使用到汇编语法，因此首先需要了解的就是nasm汇编语法
+
其次，为了能够对实验有整体的把握，建议先完整阅读 《 操作系统概念（第九版）》 对操作系统有一个整体视角再着手开始实验，这样更有利于落实自己的想法并体验到实验的乐趣所在
+
当然，如果是正在跟随课程实验进行，尚不能提前通读整本书的话，也不要担心，因为随着实验的进行也是完全能够循序渐进地认识操作系统的各个概念的
+
如果阅读了前文的 前序知识 的话，那么就已经足够可以让我们编写MBR了，让我们继续吧
+
+
本节需要完成：
+
+使用 中断 加载bootloader
+跳转到bootloader运行
+
+
本节需要完成：
+
+切换到 保护模式
+从磁盘加载kernelloader
+跳转到kernelloader运行
+
+
从这一节开始，将会从asm编程切换到C++和内联汇编组合编程
+
+
为了能够使得操作系统能够方便地组织和使用硬件资源，需要对硬件的接口进行 抽象 ，编写合适的 驱动
+
同时，为了加强代码的可读性，需要将常用的结构包装为 类
+
驱动的编写和结构的封装并不需要在这一步就全部完成，而是随着后续代码的编写而逐渐完善
+
+
为了后续实验顺利进行，在这一步需要完成如下驱动：
+
+端口驱动
+UART驱动磁盘驱动
+显示驱动
+
+
同时需要完成如下结构体：
+
+pagetable：页表page：页frame：帧elf head：ELF头
+
本节需要完成：
+
+开启 分页机制
+装载 文件系统
+编写elf parser
+从文件系统中读取kernel.o
+使用elf parser解析kernel.o中的 ELF头 并加载内核入内存正确地址处
+跳转到内核运行
+
+
+
实现malloc和free
+
从此节开始后，将可以使用malloc和free函数 这也意味着同样也可以使用vector等等各种数据结构了，代码的编写自此进入现代化
+
+
实现 虚拟页 的管理和分配，实现 虚拟页到物理页的映射
+
实现GDT、IDT和TSS的抽象，并初始化描述符表
+
实现 中断处理函数
+
本节中会涉及部分用户进程的知识 天杀的 不一样
+
+
实现 内核进程 以及 进程管理器
+
完成本节后，就有了进程调度机制，可以支持并发了
+
+
由于用户进程不能直接运行内核相关的代码，因此需要实现系统调用来在对用户进程透明的情况下执行内核相关代码
+
从MBR开始编写自己的操作系统
+
+创建项目
+首先给项目创建一个仓库，不妨叫做MyOS
+之后，为项目创建一个编译用文件夹build，一个存放镜像文件的文件夹run，一个存放所有代码的文件夹src
+由于目前我们需要完成的是操作系统启动的部分，因此本节的代码mbr.asm放置在src/boot文件夹下，同时，为了能够方便地编译项目，在build文件夹下创建项目的makefile文件
+创建完成之后的项目目录看起来就像这样
+1 2 3 4 5 6 7 . ├── build │ └── makefile ├── run └── src └── boot └── mbr.asm
Hello World
+Hello World实验作为各大语言的必经之路，在操统实验中自然也是必不可少的
+在尝试输出代码之前，先研究一下怎样让操作系统显示出我们想要的东西…
+通过显存显示内容
+qemu显示屏实际上是按25x80个字符来排列的矩阵，如下所示
+
+为了便于控制显示的内容，IA-32处理器将这个矩阵映射到了内存地址的0xB8000~0xBFFFF处，这段地址被称为显存地址
+在文本模式下，控制器的最小可控制单位为字符。每一个显示字符自上而下，从左到右依次使用显存中的两个字节表示，低字节表示显示的字符，高字节表示字符的颜色属性。H在显存中如下存放：
+
+
+
+显存地址
+值
+含义
+
+
+
+
+…
+-
+-
+
+
+B800:0001
+0x0F
+背景色黑色，前景色白色
+
+
+B800:0000
+0x48
+字符H
+
+
+
+每个字符的颜色又由两部分组成，高4位为字符的背景色，低4位为字符的前景色，每个颜色由R、G、B和K/I位组成
+K/I位含义如下
+
+
+
+K/I
+背景色
+前景色
+
+
+
+
+0
+不闪烁
+深色
+
+
+1
+闪烁
+亮（浅）色
+
+
+
+字符颜色的对照表如下
+
+
+
+R
+G
+B
+颜色
+
+
+
+
+0
+0
+0
+黑色
+
+
+0
+0
+1
+蓝色
+
+
+0
+1
+0
+绿色
+
+
+0
+1
+1
+青色
+
+
+1
+0
+0
+红色
+
+
+1
+0
+1
+品红
+
+
+1
+1
+0
+棕色
+
+
+1
+1
+1
+白色
+
+
+
+也就是说，0x0F对应的是 背景色为黑色不闪烁，前景色为亮白色的颜色
+于是，记 ( x , y ) (x, y) ( x , y ) x x x y y y ( x , y ) (x, y) ( x , y )
+
+计算出该坐标相对于显存起始地址的偏移量
+获得字符的颜色值
+将字符ASCII码和颜色值放置在显存中
+
+其中，由于一行有80列，每个字符占用两个字节的空间，因此偏移地址计算的公式如下
+I n d e x = 2 × ( x × 80 + y ) Index = 2 \times (x \times 80 + y)
+ I n d e x = 2 × ( x × 80 + y )
+之所以要用偏移地址，是因为很容易发现，0xB8000这一个起始地址已经超出了16位所能表示的范围，因此需要引入段地址，这里再回顾一次引用段地址后实际地址的计算公式：
+A c t u a l A d d r e s s = ( S e g m e n t A d d r e s s < < 4 ) + S h i f t A d d r e s s ActualAddress = (SegmentAddress << 4) + ShiftAddress
+ A c t u a l A dd ress = ( S e g m e n t A dd ress << 4 ) + S hi f t A dd ress
+很显然，将段地址设置为0xB800可以让偏移地址从0x0开始取值，因此不妨将段地址0xB800放置在附加段寄存器gs中，然后使用[gs:index]格式进行取址，例如
+1 2 mov byte [gs :0 ], 'H' mov byte [gs :1 ], 0x0F
就是将黑底白字的H显示在坐标 ( 0 , 0 ) (0, 0) ( 0 , 0 )
+通过中断显示内容
+除了使用显存赋值这一操作来显示字符，在实模式下还提供了另一种显示字符的方式——中断
+中断的调用涉及了四个部分：
+
+设置中断参数 ：参数一般为存储在bx、cx和dx寄存器或是它们的高低位中的值设置中断功能 ：一种中断调用可以实现很多不同的功能，具体要调用的功能一般通过ax或是ah指定调用中断 ：使用int指令和对应的中断向量号调用中断获取返回值 ：中断函数如果有返回值的话一般是放在寄存器中，所以要从寄存器中获取返回值
+BIOS提供了很多中断函数，中断向量号和它们的功能可以查看 OSDev Wiki中关于BIOS的页面
+在本次实验中我们暂时只关注int 10h这个函数，它提供了光标相关的操作，对应的参数和返回值可以参考 Wikipedia 中关于光标中断的页面
+
+
+
+功能
+功能号
+参数
+返回值
+
+
+
+
+设置光标位置
+AH=02HBH：页码DH：行，DL：列-
+
+
+获取光标位置
+AH=03HBX：页码AX=0CH：行扫描开始，CL：行扫描结束DH：行，DL：列实验中一般只需要用到DH和DL
+
+在光标位置写入字符
+AH=09HAL：字符，BL：颜色BH：页码，CX：输出字符个数-
+
+
+
+所以在 ( x , y ) (x, y) ( x , y )
+
+设置光标位置为 x x x y y y
+设置字符颜色等参数
+在光标位置写入字符
+
+例如，在 ( 0 x 1 C , 0 x 03 ) (0x1C, 0x03) ( 0 x 1 C , 0 x 03 ) H操作为
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 move_cursor: mov dh , 0x1C mov dl , 0x03 mov ah , 0x02 int 0x10 output_character: mov al , 'H' mov bl , 0x0F mov cx , 0x01 mov ah , 0x09 int 0x10
编写MBR
+回顾：MBR的加载 （也即存放MBR的扇区） 是否可以启动将这512字节加载到0x7C00处开始执行 实模式 下
+
为了让编译器能够正确理解 “我们是在编写MBR” 这件事，需要使用一些汇编的伪指令告知编译器：
+
+代码会被加载到0x7C00处执行
+代码在16位模式下运行
+
+翻译成asm语言如下
+之后，需要对寄存器进行初始化，避免为初始化的段地址影响后续的取址操作段寄存器只能通过ax寄存器赋值 ，所以可以先将ax置0，然后再通过ax将段寄存器置0
+陷阱：不要初始化cs ds, ss, es, fs, gs都可以正常进行置0操作cs进行置0，则会导致代码出现意料之外的行为cs寄存器初始化
+
1 2 3 4 5 6 7 xor ax , ax mov ds , ax mov ss , ax mov es , ax mov fs , ax mov gs , ax
此时栈指针寄存器sp还没有被初始化，由于栈是从高地址向低地址增长的，所以需要给栈分配一段可以向下增长的空间0x7C00处让其向下增长
+之后使用显存显示内容的方式来完成Hello World!字串的输出
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 mov ax , 0xB800 mov gs , ax mov si , 0 print: mov dl , byte [_msg + si ] cmp dl , 0 je print_exit inc si mov ax , word [_row] imul ax , 80 add ax , word [_col] imul ax , 2 mov bx , ax mov byte [gs :bx ], dl mov byte [gs :bx + 1 ], 0x0F add word [_col], 1 mov ax , word [_col] cmp ax , 80 jne add_row_exit add word [_row], 1 mov word [_col], 0 add_row_exit: jmp print print_exit: jmp $_row dw 0 _col dw 0 _msg db 'Hello World!' , db 0
陷阱：不要将数据放置在代码中间或者前部 0x7C00处开始执行代码，其并不区分内存中存储的二进制码究竟是数据还是指令，因此如果将数据放置在代码前面，可能会让CPU误认为数据是代码从而被执行，产生无法预料的错误，这类错误往往很难通过调试发现
+
不要让代码掉进 “虚无” jmp $，其中$的意思是当前语句的地址，这句指令无限跳转到其自身执行
+
最后，由于还没有开始做文件系统和磁盘分区，不妨将MBR后续字节填充零，使用伪指令times来重复填充，$ - $$很容易解读出其意译为当前地址减去文件起始地址的差
+1 2 3 4 5 times 446 - ($ - $$) db 0 times 510 - ($ - $$) db 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 [org 0x7C00 ] [bits 16 ] xor ax , ax mov ds , ax mov ss , ax mov es , ax mov fs , ax mov gs , ax mov sp , 0x7C00 mov ax , 0xB800 mov gs , ax mov si , 0 print: mov dl , byte [_msg + si ] cmp dl , 0 je print_exit inc si mov ax , word [_row] imul ax , 80 add ax , word [_col] imul ax , 2 mov bx , ax mov byte [gs :bx ], dl mov byte [gs :bx + 1 ], 0x0F add word [_col], 1 mov ax , word [_col] cmp ax , 80 jne add_row_exit add word [_row], 1 mov word [_col], 0 add_row_exit: jmp print print_exit: jmp $_row dw 0 _col dw 0 _msg db 'Hello World!' , db 0 times 446 - ($ - $$) db 0 times 510 - ($ - $$) db 0 dw 0xAA55
编写makefile
+
+为了让项目能够顺利地运行起来，需要编写Makefile文件。在默认已经了解Makefile语法的前提下，简要介绍从MBR启动所需要的各个文件以及它们的依赖关系
+
+
+
+文件
+作用
+依赖关系
+
+
+
+
+hd.img硬盘文件
+mbr.bin
+
+mbr.binMBR编译后的二进制文件
+mbr.asm
+
+mbr.asmMBR源文件
+-
+
+
+
+根据这些依赖关系，可以写出Makefile文件
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 ASM_COMPILER := nasm SRC_PATH := ../src RUN_PATH := ../run .PHONY :build: mbr.bin qemu-img create $(RUN_PATH) /hd.img 10m dd if=mbr.bin of=$(RUN_PATH) /hd.img bs=512 count=1 seek=0 conv=notrunc %.bin: $(SRC_PATH) /boot/%.asm $(ASM_COMPILER) -o $@ -f bin $^ .PHONY :clean: rm -f *.o* *.bin rm -f $(RUN_PATH) /*.img .PHONY :run: qemu-system-i386 -hda $(RUN_PATH) /hd.img -vga virtio -serial null -parallel stdio -no-reboot
运行和结果
+进入项目目录下的build/目录
+可以首先清除原先生成的文件，重新构建并且运行
+
+完成本章 下一章 吧！
+
关于本章
+在本章的第一部分 中，将会介绍读取硬盘的CHS方式、LBA方式以及如何通过in、out指令读写硬盘，之后会将上一章 输出Hello World!的代码移植到BootLoader中，并且从MBR中加载并跳转到编写的BootLoader执行
+在第二部分 中，会回顾保护模式的概念并介绍进入保护模式的四个步骤，并在开启保护模式之后输出第二个Hello World
+第一次跃进：从MBR跳转到BootLoader
+MBR只有512字节的大小，甚至如果除去分区表，只有四百多字节的大小，这个大小稍微复杂一些的程序就难以运行了，更不要说是把全部的操作系统都放在里面了
+因此，目前的首要任务就是 突破512字节的限制 ，从而能够让我们着手编写更复杂的程序，其实，聪明的工程师很早就提出了一个可行的解决方案：在MBR里面把另一段更大的程序加载到内存里面，之后跳转到加载的地址去执行 ，这个 “更大的程序” 就是我们本节要编写的BootLoader，它在编译之后会被烧录到硬盘镜像中指定的扇区里，MBR要做的事情就是从这些扇区里面把我们编写的BootLoader加载出来放在内存里，然后跳转到加载的内存地址处执行BootLoader的代码
+为什么不直接从MBR跳转到内核运行？ 上一章的实验路线 中可以看到，在加载内核之前有许多需要准备的工作，包括开启虚拟分页机制以及文件系统的装载
+
简述CHS模式
+CHS全称为 Cylinder-head-sector ，是早期用来定位硬盘上扇区的一种方式
+在CHS中，扇区通过不同的 柱面 (Cylinder) 、磁头 (Head) 和 扇区 (Sector) 指定，除此之外，在CHS中还有一个额外的概念 磁道 (Track) ，下面简要介绍这四个概念的含义
+
+
+柱面 ：（或者说做相交的操作） ，则每一个磁盘都会被相交得到一个空心圆，这些空心圆的组合就叫做柱面，实际上，它们看起来也确实像一个圆柱的外表面，而这个圆柱与做相交时的空心圆柱大小是一样的
+换一种说法，每一个碟片都是由很多个同心圆组成的，这些同心圆被叫做 磁道 ，从外到内由0开始编号，每个碟片上的磁道数都是相同而且对齐的，也就是说，如果我们俯视一个磁盘，那么最上面的碟片的磁道是怎么分布的，它下面的碟片也都是这么分布的，如果我们对所有碟片选定同一个磁道，那么它从上到下看起来就会构成一个圆柱的外表面，也就是 柱面 ，这个磁道编号就是柱面号
+
+
+磁头 ：（也就是磁道） 上，并且可以在不同的磁道间移动
+
+
+扇区
+扇区与数据密度 老式的磁盘使用的就是这种方式 ，确实会导致内外磁道数据密度不同的问题新的解决方式按照等密度的方式划分扇区，也就是越靠外的磁道扇区数越多
+
在实验中将使用经典的理解，也就是老式磁盘的划分方式，同时后面也会看到在LBA模式中这种差异将不会对取址产生影响
+
+
+磁道 ：磁道 。同时，磁道也可以理解为是由柱面和磁头对应的盘面相交得到的圆
+也就是说，一个柱面和一个磁头可以唯一指定一个磁道，在CHS取址模式中不需要提供磁道号也正是这个原因
+
+
+如果还不能够完全理解，可以查看Wikipedia关于CHS模式的页面 中精妙的配图如下
+
+简述LBA模式
+LBA模式全称为 Logical Block Addressing ，顾名思义，就是通过逻辑扇区号去寻址物理扇区号，具体的寻址方式则是对用户透明的
+在LBA模式下，不存在像CHS那样复杂的概念，硬盘的扇区被看作是线性的并从0扇区开始编号 ，当使用LBA扇区号进行取址的时候，存储设备会自动转换成对应的柱面、磁头和扇区进行读取，用户不需要关心这部分的实现
+陷阱：CHS和LBA模式的扇区编号不同
+
通过CHS编号来计算LBA编号可以使用如下公式，其中HPC为柱面中的磁头数 Heads per Cylinder ，SPT为每个磁道中的扇区数 Sectors per Track
+L B A = ( C × H P C + H ) × S P T + ( S − 1 ) LBA = (C \times HPC + H) \times SPT + (S - 1)
+ L B A = ( C × H PC + H ) × SPT + ( S − 1 )
+同样，LBA模式也可以通过下述公式转换为CHS编号
+{ C = L B A ÷ ( H P C × S P T ) H = ( L B A ÷ S P T ) m o d H P C S = ( L B A m o d S P T ) + 1 \left\{
+ \begin{aligned}
+ \; &C = LBA \div (HPC \times SPT)\\
+ &H = (LBA \div SPT)\;mod\;HPC\\
+ &S = (LBA\;mod\;SPT) + 1
+ \end{aligned}
+\right.
+ ⎩ ⎨ ⎧ C = L B A ÷ ( H PC × SPT ) H = ( L B A ÷ SPT ) m o d H PC S = ( L B A m o d SPT ) + 1
+在LBA模式下通过端口读写磁盘
+接口和模式
+
了解了硬盘的寻址模式之后，就可以开始着手从磁盘里读取数据了，在实验中我就采用了更为 无脑 简单的LBA28模式
+LBA28
+
既然要从磁盘读取数据，那就自然要告诉磁盘 读数据、去哪读和读多少 ，端口就在这个过程中充当了信使的角色，我们通过向端口发送数据，告诉磁盘读取地址和读取数量，等候磁盘完成后再从端口接收数据
+在磁盘读的操作中，要用到的端口及其描述如下
+
+
+
+端口号
+端口数据传输方向
+作用 (LBA28)
+描述
+位长 (LBA28)
+
+
+
+
+0x1F0
+读/写
+数据寄存器
+硬盘读出/要写入的数据
+16-bit
+
+
+0x1F1
+读
+错误码寄存器
+存储执行的ATA指令所产生的错误码
+8-bit
+
+
+0x1F1
+写
+功能寄存器
+用来指定特定指令的接口功能
+8-bit
+
+
+0x1F2
+读/写
+扇区数寄存器
+存放需要读写的扇区数量
+8-bit
+
+
+0x1F3
+读/写
+起始扇区寄存器
+存放起始扇区0-7位
+8-bit
+
+
+0x1F4
+读/写
+起始扇区寄存器
+存放起始扇区8-15位
+8-bit
+
+
+0x1F5
+读/写
+起始扇区寄存器
+存放起始扇区16-23位
+8-bit
+
+
+0x1F6
+读/写
+磁盘、起始扇区寄存器
+选择磁盘和访问模式
+8-bit
+
+
+0x1F7
+读
+状态寄存器
+读取当前磁盘状态
+8-bit
+
+
+0x1F7
+写
+指令寄存器
+传送ATA指令
+8-bit
+
+
+
+其中，部分端口的位作用比较复杂，部分位在实验中也不需要留意，使用*号注明
+
+
+
+端口号
+位
+缩写
+作用
+
+
+
+
+0x1F6
+0-3
+-
+在LBA模式中，指定其起始扇区号的24-27位
+
+
+0x1F6
+4
+DRV
+指定磁盘0：主硬盘1：从硬盘
+
+
+0x1F6
+5
+1
+始终置位
+
+
+0x1F6
+6
+LBA
+指定访问模式0：CHS模式1：LBA模式
+
+
+0x1F6
+7
+1
+始终置位
+
+
+
+
+
+
+端口号
+位
+缩写
+作用
+
+
+
+
+0x1F7 (Read)
+0
+ERR
+指示是否有错误发生，通过发送新指令可以清除该位
+
+
+0x1F7 (Read)
+1*
+IDX
+索引，始终置为0
+
+
+0x1F7 (Read)
+2*
+CORR
+修正数据，始终置位0
+
+
+0x1F7 (Read)
+3
+DRQ
+0：硬盘还不能交换数据1：硬盘存在可以读取的数据或是可以写入数据
+
+0x1F7 (Read)
+4*
+SRV
+重叠模式服务请求
+
+
+0x1F7 (Read)
+5*
+DF
+驱动器故障错误
+
+
+0x1F7 (Read)
+6*
+RDY
+0：驱动器发生了减速或是错误1：驱动器运转正常
+
+0x1F7 (Read)
+7
+BSY
+忙位0：空闲1：忙
+
+
+
+了解了各个端口的作用后，如何从硬盘读取数据似乎就是显而易见的了：
+
+设置起始扇区号
+设置读取的扇区数量
+设置磁盘和访问模式
+检测状态位，等待硬盘就绪
+从端口读取数据
+
+为了方便代码重用 （虽然MBR的代码也不会重用了） ，在实验中将读取硬盘的功能包装成一个汇编函数进行调用
+NASM中的函数调用
+
调用函数前，通过将参数压栈的方式传递参数call tag调用函数，在执行call指令时会将下一条指令地址压入栈顶pushad为主调函数保存寄存器的值ret返回，在执行ret指令时会取出栈顶值并跳转到该值处执行add sp, <imm>操作将栈指针上移，从栈上删除传递的参数
+
令函数名为read_sectors，并假定主调函数向其传递四个参数值startSector[15:0]、startSector[27:16]、sectorCount和targetAddress，可以据此先写出函数体
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 read_sectors: push sp mov bp , sp pushad popad pop sp ret
之后从栈上依次取出起始扇区号并发送到端口0x1F3~0x1F6
+陷阱：注意正确设置0x1F6端口高4位
+
陷阱：栈上的字长为2字节 bp在栈上取数据时步进为2而不是4 word [bp + 2 * 2]
+
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 mov bx , word [bp + 2 * 2 ] mov al , bl mov dx , 0x1F3 out dx , al mov al , bh mov dx , 0x1F4 out dx , al mov bx , word [bp + 3 * 2 ] and bx , 0x0FFF or bx , 0xE000 mov al , bl mov dx , 0x1F5 out dx , al mov al , bh mov dx , 0x1F6 out dx , al
然后通过0x1F2端口设置读取的扇区数量
+1 2 3 mov al , byte [bp + 4 * 2 ] mov dx , 0x1F2 out dx , al
向0x1F7端口发送0x20指令请求硬盘读
+1 2 3 mov dx , 0x1F7 mov al , 0x20 out dx , al
在发送读请求后，通过循环检测0x1F7端口的0、3、7位等待硬盘就绪，就绪的标志为这三位依次为0、1、0
+陷阱：记得等待硬盘就绪 一定 要等待硬盘就绪，不然会读出错误的数据
+
1 2 3 4 5 6 .wait_disk: mov dx , 0x1F7 in al , dx and al , 0x89 cmp al , 0x08 jnz .wait_disk
最后，从0x1F0端口读取数据
+0x1F0端口为16位端口，因此一次可以读取两个字节，总的读取次数为
+L o o p C o u n t = S e c t o r C o u n t × 512 ÷ 2 = S e c t o r C o u n t × 256 \begin{aligned}
+LoopCount &= SectorCount \times 512 \div 2 \\
+ &= SectorCount \times 256
+\end{aligned}
+ L oo pC o u n t = S ec t or C o u n t × 512 ÷ 2 = S ec t or C o u n t × 256
+1 2 3 4 5 6 7 8 9 10 11 12 xor ax , ax mov al , byte [bp + 4 * 2 ] imul ax , 256 mov bx , word [bp + 5 * 2 ] mov si , 0 mov cx , ax .write_word: mov dx , 0x1F0 in ax , dx mov word [bx + si ], ax add si , 2 loop .write_word
所以完整的读取函数为
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 read_sectors: push sp mov bp , sp pushad mov bx , word [bp + 2 * 2 ] mov al , bl mov dx , 0x1F3 out dx , al mov al , bh mov dx , 0x1F4 out dx , al mov bx , word [bp + 3 * 2 ] and bx , 0x0FFF or bx , 0xE000 mov al , bl mov dx , 0x1F5 out dx , al mov al , bh mov dx , 0x1F6 out dx , al mov al , byte [bp + 4 * 2 ] mov dx , 0x1F2 out dx , al mov dx , 0x1F7 mov al , 0x20 out dx , al .wait_disk: mov dx , 0x1F7 in al , dx and al , 0x89 cmp al , 0x08 jnz .wait_disk xor ax , ax mov al , byte [bp + 4 * 2 ] imul ax , 256 mov bx , word [bp + 5 * 2 ] mov si , 0 mov cx , ax .write_word: mov dx , 0x1F0 in ax , dx mov word [bx + si ], ax add si , 2 loop .write_word popad pop sp ret
加载BootLoader并跳转
+为了验证上一节中读取硬盘函数的正确性，现在需要在项目中创建BootLoader，由于目前我们还不打算在BootLoader中完成很复杂的任务，所以就先将上一节中打印’Hello World!' 的代码移植到BootLoader中，然后尝试从MBR加载并跳转到BootLoader执行，看看能否正常运行
+首先我们需要扩充我们的项目结构：
+
+BootLoader自身需要一个汇编文件bootloader.asm，由于它同样属于启动过程，所以可以将它放置在/src/boot/目录下
+由于BootLoader加载需要指定 起始扇区号 、扇区数量 和 加载地址 ，为了方便修改，增加代码可读性，可以像C语言那样将这些数值定义为常数值放在头文件中，然后在代码中引用这个头文件。于是我们为启动过程添加一个共同的头文件boot.inc，用于指定启动过程中用到的所有常数值，这个文件同样放置在/src/boot/目录下
+
+扩充后的项目结构大致像这样
+1 2 3 4 5 6 7 8 9 10 11 . ├── build │ └── makefile ├── readme.md ├── run │ └── hd.img └── src └── boot ├── boot.inc ├── bootloader.asm └── mbr.asm
在开始移植之前，需要先确认BootLoader的起始地址以及它的大小，这涉及到内存地址的安排
+在操作系统内核设计的过程中，内存规划是一件令人苦恼的事情，但同时也是一件自由的事情，只要不发生溢出和重叠之类的问题，将内容放置在哪里是一个相对主观的事情
+这里我将BootLoader直接放置在MBR后面，占用4个扇区的大小，内存的安排如下
+
+
+
+用途
+起始地址
+终止地址
+扇区数
+
+
+
+
+MBR
+0x7C00
+0x7E00
+1
+
+
+BootLoader
+0x7E00
+0x8600
+4
+
+
+
+完成了内存规划之后，就可以将常数写入头文件中了
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 BOOTLOADER_SECTOR_START_15_0 equ 1 BOOTLOADER_SECTOR_START_27_16 equ 0 BOOTLOADER_SECTOR_COUNT equ 4 BOOTLOADER_LOAD_ADDRESS equ 0x7E00 GDT_START_ADDRESS equ 0x9000 ZERO_SELECTOR equ 0x00 KERNEL_CODE_SELECTOR equ 0x08 KERNEL_DATA_SELECTOR equ 0x10 KERNEL_STACK_SELECTOR equ 0x18 GDT_SIZE equ 4
打印Hello World!代码的移植步骤就比较简单了，直接复制粘贴入bootloader.asm即可，不过需要注意的是要修改一下头部伪代码中的[org 0x7C00]为BootLoader的起始地址[org 0x7E00]
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 %include "boot.inc" [org 0x7E00 ] [bits 16 ] mov ax , 0xB800 mov gs , ax mov si , 0 print: mov dl , byte [_msg + si ] cmp dl , 0 je print_exit inc si mov ax , word [_row] imul ax , 80 add ax , word [_col] imul ax , 2 mov bx , ax mov byte [gs :bx ], dl mov byte [gs :bx + 1 ], 0x0F add word [_col], 1 mov ax , word [_col] cmp ax , 80 jne add_row_exit add word [_row], 1 mov word [_col], 0 add_row_exit: jmp print print_exit: jmp $_row dw 0 _col dw 0 _msg db 'Hello World!' , db 0 times 2048 - ($ - $$) db 1
之后，对mbr.asm中的代码进行修改
+向其中添加read_sectors函数并且调用read_sectors函数
+1 2 3 4 5 6 7 push BOOTLOADER_LOAD_ADDRESSpush BOOTLOADER_SECTOR_COUNTpush BOOTLOADER_SECTOR_START_27_16push BOOTLOADER_SECTOR_START_15_0call read_sectorsadd sp , 8
跳转到BootLoader的起始地址
+1 2 jmp BOOTLOADER_LOAD_ADDRESS
最后，修改makefile文件，由于添加了两个文件，依赖关系也产生了变化，新的依赖关系如下
+
+
+
+文件
+作用
+依赖关系
+
+
+
+
+hd.img硬盘文件
+mbr.binbootloader.bin
+
+mbr.binMBR编译后的二进制文件
+mbr.asmboot.inc
+
+bootloader.binBootLoader编译后的二进制文件
+bootloader.asmboot.inc
+
+mbr.asmMBR源文件
+-
+
+
+bootloader.asmBootLoader源文件
+-
+
+
+boot.inc头文件
+-
+
+
+
+根据新的依赖关系，可以编写新的makefile文件如下，其中除了添加了新的依赖文件编译规则外，还添加了对头文件路径的指定
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 ASM_COMPILER := nasm SRC_PATH := ../src RUN_PATH := ../run INCLUDE_PATH := $(addprefix -I, $(dir $(shell find '$(SRC_PATH) ' -name '*.inc') )) .PHONY :build: mbr.bin bootloader.bin qemu-img create $(RUN_PATH) /hd.img 10m dd if=mbr.bin of=$(RUN_PATH) /hd.img bs=512 count=1 seek=0 conv=notrunc dd if=bootloader.bin of=$(RUN_PATH) /hd.img bs=512 count=4 seek=1 conv=notrunc %.bin: $(SRC_PATH) /boot/%.asm $(ASM_COMPILER) -o $@ -f bin $(INCLUDE_PATH) $^ .PHONY :clean: rm -f *.o* *.bin rm -f $(RUN_PATH) /*.img .PHONY :run: qemu-system-i386 -hda $(RUN_PATH) /hd.img -vga virtio -serial null -parallel stdio -no-reboot
运行的方式与上一章相同，进入build/目录下执行make clean build run即可以对代码进行编译和运行
+运行的结果应该与上一章一样，在屏幕的第一行打印出Hello World!字样
+
+在BootLoader中开启保护模式
+知识准备
+保护模式
+
保护模式是目前英特尔处理器主流的运行模式，在保护模式中，处理器以32位模式运行，所有的寄存器也都为32位，因此程序可以访问到2 32 = 4 G i B 2^{32} = 4GiB 2 32 = 4 G i B
+
保护模式提出了 段 的概念，在CPU产生地址以后，会判断这个地址是否超出了段所规定的地址，从而避免程序之间的越界访问
+
除此之外，保护模式还包括了特权级保护等，在后面的实验中会逐个涉及
+
上面提到，在保护模式中提出了段的概念，在保护模式中运行的各种代码都需要声明自己所使用的段，并且由CPU监视地址的访问是否越界。那么，代码是如何告诉CPU自己所使用的段信息，CPU又是如何知道段的界限的呢？
+实际上，为了能够让CPU得知段的具体信息，需要在内存中分配一段地址空间，在其中放置关于各个段的说明信息，这部分空间就被叫做全局描述符表GDT (Global Descriptor Table)
+全局描述符表的起始地址与它的大小组合成一段48位长度的数据提供给CPU作为查询全局描述符表基地址的依据，放置在CPU中的GDTR寄存器中 ，GDTR的结构如下
+
+
+
+位区间
+描述
+
+
+
+
+[48:16]
+基地址 (Offset) [31:0]
+
+
+[15:0]
+大小 (Size) [15:0]
+
+
+
+其中，大小由最多能够放入的描述符个数Count指定
+S i z e = C o u n t × 8 − 1 Size = Count \times 8 - 1
+ S i ze = C o u n t × 8 − 1
+全局描述符表看起来就像一个数组，其存放的都是64位长度的元素，每一个元素都用来描述一个段的信息，被称作段描述符 (Segment Descriptor) ，全局描述符表中的第一个元素始终为空描述符，从第二个元素开始可以由程序定义
+对于段描述符而言，它由七个部分组成，结构如下
+
+
+
+位区间
+描述
+
+
+
+
+[63:56]
+起始地址 (Base) [31:24]
+
+
+[55:52]
+标志位 (Flags) [3:0]
+
+
+[51:48]
+段界限 (Limit) [19:16]
+
+
+[47:40]
+访问控制位 (Access Byte) [7:0]
+
+
+[39:32]
+起始地址 (Base) [23:16]
+
+
+[31:16]
+起始地址 (Base) [15:0]
+
+
+[15:0]
+段界限 (Limit) [15:0]
+
+
+
+其中，访问控制位又分为七个不同的部分，其结构和作用如下
+
+
+
+位
+缩写
+描述
+
+
+
+
+0
+A
+访问位 (Accessed bit) 0：段未被访问1：段在上次清除这个访问位后被访问过
+
+1
+RW
+读写权限位 (Readable/Writable bit) 代码段： 0不可读，1可读，始终不可写数据段： 0不可写，1可写，始终可读
+
+2
+DC
+增长方向/一致性标志位 (Direction/Conforming bit) 代码段： 0只能由DPL中指定的特权级执行，1代表DPL中指定可执行的最高特权级数据段： 0段向高地址增长，1段向低地址增长
+
+3
+E
+可执行位 (Executable bit) 0：不可执行，为数据段1：可执行，为代码段
+
+4
+S
+描述符类型位 (Descriptor type bit) 0：系统段，例如TSS1：代码段或是数据段
+
+5-6
+DPL
+描述符特权级 (Descriptor privilege level field) 0：最高特权级（内核）3：最低特权级（用户）
+
+7
+P
+存在位 (Present bit) 0：该描述符不可用 (invalid) 1：描述符可用
+
+
+段描述符的标志位则使用三个不同的标志设置了段的粒度、位模式
+
+
+
+位
+缩写
+描述
+
+
+
+
+0
+Reserved
+保留位，始终置0
+
+
+1
+L
+长模式标志位 (Long-mode code flag) 0：位模式由DB位指定1：段描述的位64位代码段
+
+2
+DB
+位模式位 (Size flag) 0：描述符对应16位保护模式段1：描述符对应32位保护模式段L位应为0
+
+3
+G
+粒度标志位 (Granularity flag) 0：描述符中的段界限按照字节单位计算1：描述符中的段界限按照4KiB单位计算
+
+
+在了解了段描述符各个位的作用后，CPU又是如何通过这些地址和标志位去判断地址的合法性的呢？要明确这个问题，就需要首先知道CPU是如何生成地址的
+进入保护模式之后，每当CPU生成一个地址，它实际上生成的是相对于段的偏移地址Offset，CPU同时还会通过上文中提到的段选择子从全局描述符表中取出段的基地址Base，之后CPU中的地址变换部件会判断偏移地址的合法性，并组合偏移地址和基地址得到真实的物理地址Address，这个最后的物理地址才会用于访问内存数据
+也就是说，Address、Base和Offset之间存在如下关系
+A d d r e s s = B a s e + O f f s e t Address = Base + Offset
+ A dd ress = B a se + O ff se t
+而CPU对地址合法性的检验，实际上就是在做Offset和段描述符中界限Limit之间关系的判断，当然，由于粒度Granularity的引入，在计算实际的界限时还需要掺入粒度单位
+对于向上增长的段，它的偏移地址需要满足
+0 ≤ O f f s e t ≤ L i m i t × G r a n u l a r i t y 0 \le Offset \le Limit \times Granularity
+ 0 ≤ O ff se t ≤ L imi t × G r an u l a r i t y
+这个很好理解，因为 0 0 0 L i m i t × G r a n u l a r i t y Limit \times Granularity L imi t × G r an u l a r i t y
+陷阱：粒度不是直接进行乘4KiB的操作 L i m i t × G r a n u l a r i t y Limit \times Granularity L imi t × G r an u l a r i t y Limit << 12 | 0xFFF0xFFFFF的界限实际对应着0xFFFFFFFF，0x00000对应着0x00000FFF
+
对于向下增长的段，则稍微有些不一样，一个比较容易理解的阐述是，对于使用相同基址和界限的向上增长段，其合法地址在向下增长的段中不合法，其不合法的地址在向下增长的段中合法 ，如果使用公式来更严谨的解释这一说法，则偏移地址需要满足
+L i m i t × G r a n u l a r i t y + 1 ≤ O f f s e t ≤ 0 x F F F F F F F F ( 0 x F F F F f o r 16 b i t ) Limit \times Granularity + 1 \le Offset \le 0\mathtt{x}FFFFFFFF\;(0\mathtt{x}FFFF\;for\;16\;bit)
+ L imi t × G r an u l a r i t y + 1 ≤ O ff se t ≤ 0 x FFFFFFFF ( 0 x FFFF f or 16 bi t )
+举一个例子，假设需要在16位模式下设置一个1KiB栈段，其最高地址为0xFFFF，则其最低地址为0xFC00，大家可能很快就能想到，将基地址设置为0x0000并设置界限为0xFC00既可以描述这个栈段
+但且慢，注意到偏移地址的最低合法地址为 L i m i t × G r a n u l a r i t y + 1 Limit \times Granularity + 1 L imi t × G r an u l a r i t y + 1 0xFC00，则最低合法地址为 0 x 0000 + 0 x F C 00 + 1 = 0 x F C 01 0\mathtt{x}0000 + 0\mathtt{x}FC00 + 1 = 0\mathtt{x}FC01 0 x 0000 + 0 x FC 00 + 1 = 0 x FC 01
+因此，界限应该设置为0xFBFF才能让栈段的可用地址为1KiB
+全局描述符表不仅可以存储段描述符 (Task State Segment) ，这将会在实现用户进程的章节介绍
+
既然是数组，那就意味着可以通过下标（索引）来取出某个位置上的元素，CPU也正是这么做的，当一个程序向CPU声明自己所使用的段时，它实际上是向CPU提供了一个索引，这个16位索引中存储了其所使用的段在全局描述符表中的下标以及特权级信息（将会在用户进程的实现中介绍），被称作段选择子 (Segment Selector)
+段选择子由其对应的段在全局描述符表中的索引、描述符表类型以及特权级构成，其结构如下
+
+
+
+位区间
+描述
+
+
+
+
+[15:3]
+索引 (Index) [12:0]
+
+[2:2]
+描述符表类型 (TI) 0：使用全局描述符表 (GDT) 1：使用局部描述符表 (LDT)
+
+[1:0]
+特权级 (RPL) [1:0]
+
+
+我们目前只需要设置索引位
+由于在实验中不会使用到局部描述符表，因此在此处不会介绍它，这一位直接设置为0
+同时特权级位会在后面涉及到用户进程时再次介绍，目前我们只需要关心RPL = 0的段
+总的来说，操作系统内的代码首先在内存中的全局描述符表内声明需要用到的段 ，之后将对应段的选择子提供给CPU ，CPU在产生地址后，根据选择子中的信息在全局描述符表中查询段的具体信息 来判断访问是否越界
+进入保护模式
+在了解了保护模式以及全局描述符表的相关知识后，就可以编写代码在BootLoader中开启保护模式了
+进入保护模式 设置全局描述符表 、关闭中断 ， 开启第21根地址线 、打开保护模式开关 和 执行一次远跳转送入代码段选择子
+
首先进行第一步：设置全局描述符表
+通过上一小节可以知道，全局描述符表实际上就是存放在内存中的一段类似于数组的空间，但是目前我们还没有指定这一段空间的位置，所以要先进行内存规划
+实际上位置的指定相对自由，在实验中将GDT放置在0x9000-0x10000的位置处
+
+
+
+用途
+起始地址
+终止地址
+扇区数
+
+
+
+
+MBR
+0x7C00
+0x7E00
+1
+
+
+BootLoader
+0x7E00
+0x8600
+4
+
+
+GDT
+0x9000
+0x10000
+-
+
+
+
+将新的常数写入头文件中方便调用
+1 2 GDT_START_ADDRESS equ 0x9000
之后，在BootLoader中向GDT中添加元素，在实验中我们使用平坦模式，所以只需要添加代码段、数据段以及栈段的描述符，以及最初的空描述符
+平坦模式
+
可以根据段特性来设置描述符的值
+
+
+
+段
+起始地址
+段界限
+A
+RW
+DC
+E
+S
+DPL
+P
+L
+DB
+G
+描述符值
+
+
+
+
+空
+0x0
+0x0
+0
+0
+0
+0
+0
+0
+0
+0
+0
+0
+0x00000000_00000000
+
+
+代码
+0x0
+0xFFFFFFFF
+0
+1
+0
+1
+1
+0
+1
+0
+1
+1
+0x00CF9A00_0000FFFF
+
+
+数据
+0x0
+0xFFFFFFFF
+0
+1
+0
+0
+1
+0
+1
+0
+1
+1
+0x00CF9200_0000FFFF
+
+
+栈
+0x0
+0x0
+0
+1
+1
+0
+1
+0
+1
+0
+1
+1
+0x00CF9600_0000FFFF
+
+
+
+确定了描述符值以后，使用mov命令放置在给GDT分配的内存空间中
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 mov dword [GDT_START_ADDRESS + 0 * 4 ], 0x00000000 mov dword [GDT_START_ADDRESS + 1 * 4 ], 0x00000000 mov dword [GDT_START_ADDRESS + 2 * 4 ], 0x0000FFFF mov dword [GDT_START_ADDRESS + 3 * 4 ], 0x00CF9A00 mov dword [GDT_START_ADDRESS + 4 * 4 ], 0x0000FFFF mov dword [GDT_START_ADDRESS + 5 * 4 ], 0x00CF9200 mov dword [GDT_START_ADDRESS + 6 * 4 ], 0x0000FFFF mov dword [GDT_START_ADDRESS + 7 * 4 ], 0x00CF9600
陷阱：注意小端模式 低地址存放低32位，高地址存放高32位 mov指令的事情，我们就不需要关心了，我们只需要知道在使用mov指令的时候，宏观上要把低32位放在低地址上 就对了
+
根据写入的顺序就可以设置描述符对应的选择子了，由于我们只使用GDT而且只考虑特权级为0的情况，因此选择子的低3位均为0
+将选择子以及描述符个数写入头文件中方便重用
+1 2 3 4 5 ZERO_SELECTOR equ 0x00 KERNEL_CODE_SELECTOR equ 0x08 KERNEL_DATA_SELECTOR equ 0x10 KERNEL_STACK_SELECTOR equ 0x18 GDT_SIZE equ 4
设置好了GDT里的内容后，就要考虑如何将其装载入GDTR了
+由于GDTR为糟糕的48位长度，很显然没有一个寄存器能够放下这样长度的数据，因此工程师们又想出了一个天秀的方式：先把要放入GDTR的值放置在内存的一段地址中，然后使用lgdt命令读取这个地址，由该指令将地址之后的48位数据拷贝到GDTR中
+所以首先指定一段用于存放GDTR数据的内存
+1 2 3 gdt_descriptor dw 0 , dd GDT_START_ADDRESS
陷阱：注意小端模式 GDTR中的Size段位于低地址，应该先声明，然后再声明其Base段
+
在BootLoader中由 S i z e = C o u n t × 8 − 1 Size = Count \times 8 - 1 S i ze = C o u n t × 8 − 1
+1 2 mov word [gdt_descriptor], GDT_SIZE * 8 - 1
一切准备妥当后，就是用lgdt指令将这糟糕的48位长度数据送入寄存器
+然后进行关中断操作
+之所以要关中断，是因为在保护模式下中断的实现与实模式下不一样，在我们尚未实现中断的时候，贸然进入保护模式会产生错误。因此我们先在BootLoader中关闭中断，当我们在后续章节中建立起完善的中断机制之后再打开中断
+在关闭中断后，就可以进行第三步：开启第21根地址线
+在实模式下，CPU始终将21根地址线置为低电平，这样不论指令寄存器如何自增，始终会因为溢出而在0xFFFFF处回到0x00000
+在编写BootLoader中的代码前，可以先看一段有趣的代码来感受CPU是如何通过第21根地址线将地址限制在20位的
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 [bits 16 ] check_a20: pushf push ds push es push di push si cli xor ax , ax mov es , ax not ax mov ds , ax mov di , 0x0500 mov si , 0x0510 mov al , byte [es :di ] push ax mov al , byte [ds :si ] push ax mov byte [es :di ], 0x00 mov byte [ds :si ], 0xFF cmp byte [es :di ], 0xFF pop ax mov byte [ds :si ], al pop ax mov byte [es :di ], al mov ax , 0 je check_a20__exit mov ax , 1 check_a20__exit: pop si pop di pop es pop ds popf ret
至于打开这根地址线，由于该地址线由南桥A20端口控制，端口号为0x92，控制位位于第二位，因此代码编写如下
+1 2 3 4 in al , 0x92 or al , 0b0000_0010 out 0x92 , al
接下来就来到了保护模式真正的开关，CR0寄存器中的PE位
+1 2 3 4 mov eax , cr0 or eax , 1 mov cr0 , eax
最后执行一次远跳转，送入代码段选择子，正式开启保护模式 ，其中protected_mode_begin部分将在下一小节 中完成
+1 jmp dword KERNEL_CODE_SELECTOR:protected_mode_begin
远跳转 执行远跳转会将段选择子送入代码段寄存器CS，同时将段内偏移送入EIP ，使得CPU在新的代码段的基地址上以新的段内偏移开始执行指令不能够手动设置 ，因此只能够通过远跳转进行设置，所以此处执行的远跳转主要目的是为了送入代码段选择子
+
第二个Hello World
+进入保护模式以后，自然要输出些什么才能确认前面的代码都正确无误地执行了。因此，在这一小节中就来实现保护模式中的第二个Hello World!
+由于进入保护模式以后，代码全面进入了32位模式，所以也要添加对应的伪代码
+1 2 3 4 5 6 7 [bits 32 ] protected_mode_begin:
这时，我们还没有设置好各个段选择子，因此应当尽快将数据段和栈段的选择子送入寄存器，由于暂时用不到附加的段寄存器，所以不妨将它们设置为空描述符
+1 2 3 4 5 6 7 8 9 mov ax , KERNEL_DATA_SELECTORmov ds , ax mov ax , KERNEL_STACK_SELECTORmov ss , ax mov ax , ZERO_SELECTORmov es , ax mov fs , ax mov gs , ax
接着就可以移植原先实模式下的代码，鉴于实模式与保护模式地区别，在移植时需要进行如下修改
+
+寄存器由16位更换到32位
+已然可以访问32位地址，不再需要[gs:bx]这样的访问模式
+
+陷阱：不是在32位模式下所有的寄存器都要使用32位
+
移植后的代码如下
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 xor eax , eax mov ebx , 0xB8000 mov esi , 0 print: mov dl , byte [_msg + esi ] cmp dl , 0 je print_exit inc esi mov eax , dword [_row] imul eax , 80 add eax , dword [_col] imul eax , 2 mov edi , eax mov byte [ebx + edi ], dl mov byte [ebx + edi + 1 ], 0x0F add dword [_col], 1 mov eax , dword [_col] cmp eax , 80 jne add_row_exit add dword [_row], 1 mov dword [_col], 0 add_row_exit: jmp print print_exit: jmp $_row dd 0 _col dd 0 _msg db 'Hello World!' , db 0
完整的bootloader.asm如下
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 %include "boot.inc" [org 0x7E00 ] [bits 16 ] cli mov dword [GDT_START_ADDRESS + 0 * 4 ], 0x00000000 mov dword [GDT_START_ADDRESS + 1 * 4 ], 0x00000000 mov dword [GDT_START_ADDRESS + 2 * 4 ], 0x0000FFFF mov dword [GDT_START_ADDRESS + 3 * 4 ], 0x00CF9A00 mov dword [GDT_START_ADDRESS + 4 * 4 ], 0x0000FFFF mov dword [GDT_START_ADDRESS + 5 * 4 ], 0x00CF9200 mov dword [GDT_START_ADDRESS + 6 * 4 ], 0x0000FFFF mov dword [GDT_START_ADDRESS + 7 * 4 ], 0x00CF9600 mov word [gdt_descriptor], GDT_SIZE * 8 - 1 lgdt [gdt_descriptor]in al , 0x92 or al , 0b0000_0010 out 0x92 , al mov eax , cr0 or eax , 1 mov cr0 , eax jmp dword KERNEL_CODE_SELECTOR:protected_mode_beginjmp $gdt_descriptor dw 0 , dd GDT_START_ADDRESS [bits 32 ] protected_mode_begin: mov ax , KERNEL_DATA_SELECTORmov ds , ax mov ax , KERNEL_STACK_SELECTORmov ss , ax mov ax , ZERO_SELECTORmov es , ax mov fs , ax mov gs , ax xor eax , eax mov ebx , 0xB8000 mov esi , 0 print: mov dl , byte [_msg + esi ] cmp dl , 0 je print_exit inc esi mov eax , dword [_row] imul eax , 80 add eax , dword [_col] imul eax , 2 mov edi , eax mov byte [ebx + edi ], dl mov byte [ebx + edi + 1 ], 0x0F add dword [_col], 1 mov eax , dword [_col] cmp eax , 80 jne add_row_exit add dword [_row], 1 mov dword [_col], 0 add_row_exit: jmp print print_exit: jmp $_row dd 0 _col dd 0 _msg db 'Hello World!' , db 0
完成 make clean build run来测试代码的运行情况吧！
+
关于本章
+在本章节的第一部分 中，将会简要介绍在下一章 中将要编写的KernelLoader，以及在开始着手进行它的编写之前所需要完成的，包括各种驱动、文件系统接口等在内的诸多准备工作。
+在第一部分之后，我决定按照KernelLoader中的函数调用顺序，逐节完成KernelLoader中所需要的所有准备工作，因此在第二部分 中，将会首先记录如何在项目中使用C语言和汇编混合编程，包括C语言是如何进行函数调用的，以及内联汇编中NASM向AT&T迁移语法所需要注意的问题。有了这部分基础知识，就可以进行第三部分 编写一些常用的驱动，并从我个人的角度讲讲为什么要这么做，它对后续的代码编写能够起到哪些帮助。
+在之后的第四部分 中，会进行有关文件系统的知识的详述，并且带领大家阅读微软关于FAT文件系统的文档 ，根据文档完成FAT文件系统接口的设计和实现。
+而第五部分 则会关注如何在多个分区的磁盘上通过MBR读取不同分区的信息，从而为正确读取文件系统中的文件提供条件
+在第六部分 中，会介绍我个人认为的操作系统中最重要的概念之一的分页机制，并根据我对它的理解，完成对分页机制中主要数据结构的抽象。
+如果你恰好像我一样，在第二部分中阅读的是人生中第一篇官方的文档的话，应当能够克服曾经对于文档的恐惧，甚至会在阅读后面的小节时仍意犹未尽，激动不已，那么第七部分 将会趁热打铁，跟随关于ELF文件的文档 完成对ELF文件格式中用到的主要数据结构的抽象。
+本章内容提示： 绕过了这一部分直接进入Kernel先着手编写Kernel中的内容 从BootLoader加载到Kernel 这一步骤，甚至KernelLoader都并不是必须的，但省略这一部分并不是没有代价的 ：由于省去了进入Kernel前的分页机制准备工作，学校教程不得不在第八次实验 中返回BootLoader，添加开启分页的代码Kernel不再需要以.bin的形式编译，也不再需要单独的entry.asm文件作为入口，并且可以加载到任意指定的地址处
+
最后一个跳板：KernelLoader
+在上一章 中，已经成功地从MBR跳转进入了BootLoader并且在BootLoader中开启了保护模式。
+在成功开启了保护模式之后，其实就已经可以进入内核运行了。事实上，学校的教程也确乎是这么实现的：就如同MBR跳转BootLoader那样，将内核编译为.bin文件并从BootLoader加载后跳转到内核加载地址上运行。
+而我的实现则相较于学校教程而言复杂了许多，在我的实现中，BootLoader与Kernel间额外添加了一层跳板，也就是在下一章中要完成的KernelLoader，它负责从硬盘活动分区的/system/文件夹中读取kernel.elf文件，并且解析kernel.elf文件中的信息，将内核加载到正确的地址，之后开启分页机制，最后跳转到Kernel运行。
+看上去，学校教程的实现方式更加简单，但这样的捷径并非没有代价，至于学校教程有哪些弊端，以及为什么我采用了一条这样的路线，在后续小节和章节的实现中，都会渐渐明朗。
+为了完成这样一个复杂的跳板程序，需要为其做许多的前期准备工作：
+
+驱动准备 ：文件读取离不开对硬盘的读写操作，硬盘的读写则离不开对接口的读写。自然，使用类似于MBR和BootLoader中使用汇编是一种解决方式，但是为了增强代码可读性，不妨使用C++对这部分操作进行包装，提供接口供程序使用文件系统的抽象 ：为了能够让程序能够识别硬盘中的文件系统，并且从文件系统中找到需要的路径和文件，就需要对文件系统的组织结构进行抽象，提供更为直观的函数接口供程序调用MBR的抽象 ：对于一个多分区的磁盘，MBR会存储关于分区的位置信息和属性，如果需要加载磁盘分区文件系统中的文件，那么从MBR获得关于分区的信息就是必不可少的第一步。因此需要了解数据在MBR中是怎样存储的，以及怎样从MBR中提取关于分区的信息页表结构抽象 ：在后面实现虚拟地址和分页机制时，需要用到一些特殊的数据结构，将这些数据结构抽象成类并提供接口可以大大提高代码的可读性Elf文件结构抽象 ：.elf文件中包含了一个加载并执行一个程序的诸多关键信息，例如程序需要加载到的地址、程序的入口点等等。为了解析文件内的信息，需要像文件系统一样，对.elf文件的结构进行抽象，最后提供接口供程序使用
+这也就意味着我们的项目目录也会产生一些变化：
+
+由于需要实现一系列驱动，所以需要在src目录下添加driver文件夹
+需要实现端口和硬盘的驱动，所以需要在driver文件夹下添加hdd和port文件夹
+由于需要实现许多抽象后的结构，所以需要一个struct文件夹
+需要对文件系统、ELF文件、MBR和页表进行抽象，所以需要为它们的文件准备fs、elf、mbr和paging文件夹
+同时，操作系统的代码还会依赖一些可重用的功能函数，例如常用的字符串处理函数、memcpy、memset等等，这些都可以被称作操作系统需要用到的“库”，可以放在src目录下的lib文件夹中。同样，抽象后的结构也可以看作库的一部分，所以将struct文件夹也放置在lib文件夹下。
+在之后的代码中还会用到一些通用的常数值和一些常用的类别如unsigned int、unsigned char和unsigned long long和它们的别名uint32、uint8和uint64等等，可以将它们编写到头文件constants.h和types.h中。由于它们同样可以视为操作系统库的一部分，所以可以放在lib中叫做common的文件夹下
+此外，可以提前为内核准备文件夹kernel，放置在src目录下
+
+在准备妥当后，新的项目结构如下
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 . ├── build ├── run └── src ├── boot │ ├── bootloader.asm │ ├── boot.inc │ ├── klentry.asm │ └── mbr.asm ├── driver │ ├── harddisk │ └── port ├── kernel └── lib ├── common │ ├── constants.h │ └── types.h ├── mem │ ├── memory.cpp │ └── memory.h ├── str │ ├── str.cpp │ └── str.h └── struct ├── elf ├── fs ├── mbr └── paging
现在，就让我们开始接下来激动人心的旅程吧！
+熟悉的朋友：C++闪亮登场
+大家不会觉得KernelLoader要使用汇编完成吧，不会吧不会吧
+离开了实模式进入32位保护模式后，C++就已经可以大展身手了，也就是说，从接下来开始就将脱离汇编苦海，投入C++的怀抱之中了。
+不过，在正式开始C++的工作前，需要完成一些交接的工作，在这一小节中，将会介绍一个C++程序是如何从源文件编程可执行文件的，以及如何进行C++与汇编的混合编程
+从代码到可执行文件
+
+在编译器将代码编译成可执行文件的过程中，其实际上进行了四个步骤：预处理、编译、汇编和链接
+预处理 又称为预编译，在这一环节中，编译器主要处理宏定义，如#include, #define, #ifndef等，并删除注释行，还会添加行号和文件名标识，在编译时编译器会使用上述信息产生调试、警告和编译错误时需要用到的行号信息。.i文件不包含任何宏定义，因为所有的宏已经被展开，并且包含的文件也已经被插入到.i文件中
+我们可以通过新建一个简单的C程序main.cpp来测试这一步骤：
+1 2 3 4 5 6 #include <stdio.h> int main () printf ("Hello world!\n" ); return 0 }
之后在编译命令中使用-E参数只进行预编译步骤
+1 gcc -o main.i -E main.cpp
查看Linux关于指令的手册： man命令man gcc可以查看关于gcc所有参数的描述和用法，其中关于-E参数就有如下描述：-E Stop after the preprocessing stage; do not run the compiler proper. The output is in the form of preprocessed source code, which is sent to the standard output.
+
可以看到生成了一个main.i文件，其内容如下：
+1 2 3 4 5 6 7 8 9 10 11 12 # 1 "main.cpp" # 1 "<built-in>" # 1 "<command-line>" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "<command-line>" 2 # 1 "main.cpp" ... # 10 "main.cpp" int main() { printf("Hello world!\n"); return 0; }
编译 是将预处理后的代码翻译成汇编语法的步骤，具体包括了词法分析 、语法分析 、语义分析及相关的优化 、中间代码生成 以及目标代码生成 五个环节
+在gcc中使用-S参数可以进行编译步骤，-masm=intel指定输出的语法格式为第二章 中介绍的Intel汇编语法
+1 gcc -o main.s -S main.cpp -masm=intel
生成的main.s文件如下：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 .file "main.cpp" .text .section .rodata.LC0: .string "Hello world!" .text .globl main .type main, @functionmain: .LFB0: .cfi_startproc endbr64 pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6 , -16 movq %rsp, %rbp .cfi_def_cfa_register 6 leaq .LC0(%rip), %rdi call puts@PLT movl $0 , %eax popq %rbp .cfi_def_cfa 7 , 8 ret .cfi_endproc .LFE0: .size main, .-main .ident "GCC: (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0" .section .note. GNU-stack,"" ,@progbits .section .note. gnu. property,"a" .align 8 .long 1f - 0f .long 4f - 1f .long 5 0 : .string "GNU" 1 : .align 8 .long 0xc0000002 .long 3f - 2f2 : .long 0x3 3 : .align 8 4 :
在汇编 步骤中，编译生成的汇编代码将会被翻译成机器语言，并且组织成为可重定位文件的格式。在Linux下，可重定位文件是ELF格式，关于ELF格式的文档 中详细地介绍了ELF格式中的各个部分，以及它们如何对重定位起作用。
+ELF文件有多种类别： 链接 环节的生成的可执行文件中，在本文的第六部分 中，就要根据文档来介绍如何解析一个可执行的ELF格式文件
+
汇编步骤仅仅只是将单个的文件转换成了机器语言，如果项目中有许多文件，它们中又存在着调用关系的话，此时是没有办法执行的。可以这么理解：在编译器进行汇编的时候，它会遇到一些只有声明而没有定义的符号，例如一些外部函数和变量，这部分函数和变量的地址此时还并不知道，因此编译就会将它们标记起来，放置在ELF文件一些特殊的区域存储
+在链接 步骤中，链接器接受多个输入的可重定位文件，根据输入的参数设置，可以规定程序的入口点地址、程序代码段放置的地址等，然后按照设置的地址将文件中的各个部分组合拼接在一起。
+由于在链接的步骤中，程序起始的地址通过参数规定，同时所有的文件此时都“齐聚一堂”，每个文件各个代码段就可以像安排座位那样依次入座了，整个程序各个符号的绝对地址也就确定了。这样，原先那些没有定义的符号此刻也能够找到了，并且也具有了绝对的地址值，各个文件中的相对地址此刻也都有了对应的绝对地址值，链接器根据这些新确定的绝对地址替换掉类似jmp、call中原先使用的值，将整个程序完整地串联在一起。
+类似jmp这样的跳转指令，就是在链接的步骤中，才真正确定跳转的绝对地址的。
+
C++与汇编混编
+即便有了C++这一利器，在实验中的许多地方仍然不可避免会需要用到汇编语言，例如需要操作某个特殊寄存器或是需要读写端口的时候。在这种情况下，有两种可行的解决方案，分别是 内联汇编 和 调用汇编函数
+学校所提供的教程在第四次实验的C/C++和汇编混合编程 这一部分介绍了调用汇编函数这一解决方案
+在这个解决方案中，主要需要三个步骤：
+
+将需要通过汇编实现的功能通过汇编函数的形式写在.asm文件中，并声明global
+在需要调用函数的C程序头文件中提供extern "C" boo baz()这样的外部函数声明，并在程序中调用这个函数来执行对应的功能
+在链接步骤中将汇编和C程序一同链接
+
+此外，为了能够让汇编函数的编写和调用能够顺利进行，还需要了解编译器是如何处理带参函数的调用的，我们不妨写一个带有参数的函数来试一试
+1 2 3 4 5 6 7 8 9 void func (int a, char b) return ; } int main () func (1 , 'A' ); return 0 ; }
之后使用编译器编译成汇编代码，其中main函数对应调用func部分的代码如下
+1 2 3 4 push 65 push 1 call _Z4funcicadd esp , 8
可以看出，两个push操作分别向栈内压入了'A'和1两个参数，之后使用call指令调用函数，在函数返回后再使用add esp, 8将参数移出栈，
+
+进入函数内也不能干坐着，按照C语言的规定，被调函数需要使用ebp从栈上取值，同时还需要为主调函数保留ebp寄存器的值，因此可以看到在汇编被调函数内部有这样的代码
+1 2 3 4 5 6 7 push ebp //Preserve ebp mov ebp , esp //Move esp to ebp //Function body pop ebp //Restore ebp ret //Return
当然，尽管C语言似乎并没有要求被调函数主动保存其他寄存器的值，但我个人而言还是习惯在进入函数之后进行一次pushad操作主动保存，这也就让固定的函数骨架变为了
+1 2 3 4 5 6 7 8 9 push ebp mov ebp , esp pushad //Function body popad pop ebp ret
上述方法为了调用一个汇编函数还要额外添加一个.asm文件，实在是不够优雅，所以我在后续的实现中改为了使用内联汇编 来完成汇编代码的部分
+实际上，内联汇编的使用极其简单（对于实验中所需要用到的部分而言），由于主要需要和内联汇编打交道的地方几乎无外乎都是要么从寄存器读出一个值，要么往寄存器写入一个值，所以并不需要学习多么复杂的语法，够用即可
+在GCC中使用内联汇编，只需要使用asm关键字，如果不希望编译器改动汇编代码顺序，可以额外添加volatile关键字，于是，一个最简单的内联汇编语句可以长这样：
+如果代码有很多行的话，就长这样：
+1 2 3 4 5 asm volatile ( "nop\n\t" "nop\n\t" "nop" )
是否已经跃跃欲试了？且慢，内联汇编默认使用的是AT&T的语法，因此我们需要进行一次Intel语法向AT&T语法的迁移，在了解了Intel与AT&T语法的主要区别之后，我们不论是写.asm文件还是写内联汇编都将得心应手
+
+Intel和AT&T的语法区别，无外乎以下几点：
+
+操作数位置相反 ：op [dest], [src]op [src], [dest]操作数写法 ：eax；立即数直接写立即数值，如0x1000%标明，如%eax；立即数前用$标明，如$0x1000寻址格式 ：[ebx + esi * 2 - 0x10]-0x10(%ebx, %esi, 2)base、索引index、元素大小size以及偏移量disp四个量进行寻址，格式为disp(base, index, size)操作数大小 ：[]寻址的过程中，需要指定大小，如mov eax, word [ebx]b为byte，w为word，l为dword，q为qword（64-bit），操作数的大小附加在指令名称后，如movl、addl
+最后，为了能够让内联汇编功能更强大，GCC还提供了一系列扩展的指令操作：
+1 2 3 4 5 6 asm volatile ( "nop" : : : )
可以看到，在正常指令的尾部，GCC允许程序员添加三个参数列表，类似于printf函数那样，通过在汇编代码中插入特定的操作数，并在后面的参数列表中按照规定的格式提供变量，可以使用变量来 “替换” 代码中对应的操作数，从而起到将变量值写入寄存器或是将寄存器值写入变量的操作。
+其中，参数列表中每一个参数都由一个可选的名称[name]，一个限制符如"=r"、"i"等以及对应的变量(var)组成。
+限制符在实验中只需要用到"r"以及"i"，其中
+
+"r"代表可以使用任意的寄存器"i"代表立即整型操作数
+除此之外，还有更多的限制符，如
+
+"a"代表可以使用%eax、%ax、%al"b"代表可以使用%ebx、bax、%bl"c"代表可以使用%ecx、%cx、%cl"d"代表可以使用%edx、%dx、%dl"s"代表可以使用%esi、%si"D"代表可以使用%edi、%di"m"代表内存操作数"o"代表内存操作数，仅用于偏移量"V"代表内存操作数，仅用于非偏移量"n"代表立即整型操作数，允许已知的数值"g"代表允许任何寄存器，但寄存器不是常规的寄存器
+在汇编指令中，可以用%0、%1…%n这样从零开始的数字来表示参数列表中的第一个、第二个、…第n个变量，例如
+1 2 3 4 5 6 7 8 int out_eax, in_eax = 10 ;asm volatile ( "movl %%eax, %0\n\t" "movl %1, %%eax" : "=r" (out_eax) : "r" (in_eax) )
也可以使用%[name]的方式通过名称来直接对应参数列表中指定名字的变量，例如：
+1 2 3 4 5 6 7 8 int out_eax, in_eax = 10 ;asm volatile ( "movl %%eax, %[out]\n\t" "movl %[in], %%eax" : [out]"=r" (out_eax) : [in]"r" (in_eax) )
陷阱：额外的% %0这样的操作数会使用一个%符号，为了区分，所有的语句中 的寄存器都需要额外加一个%，例如movl %0, %%eax
+
陷阱：变量大小与指令操作数大小对应 movl指令，那么对应的参数列表中的变量也应当是32位长度，例如int
+
至此，内联汇编的优势已然显现出来，其不但减少了杂乱文件的数目，而且还可以方便的与C程序中的变量进行操作，在后续的实验中选择哪种方案相比心里也有了答案。
+但不论选择哪一个方案完成C和汇编的混合编程，至此我们都已经顺利完成了进入C++语言环境的全部知识准备，足够我们进入后面的小节继续实验的进程了。
+驱动：抽象硬件交互
+在操作系统实现的各个环节中，都离不开和硬件打交道的部分，在我们已经完成的MBR中，就有我们为了加载BootLoader而写的读取磁盘扇区的函数。
+这些需要和硬件进行通信的操作，往往都需要用到一些特殊的端口，通过我们实现MBR的经历可以知道，使用汇编的in和out指令就可以对端口进行读写操作，而这样简单的操作如果是使用C++这样的语言进行编程的话却是无法实现的。
+这时，大家可能就会说了，不是刚刚学完了C++和汇编混编吗，这不直接上来就是一个asm ("inb dx, al")，很快啊！
+不可否认，这不失为一个解决方式，但放在C++中，它就是显得不那么优雅：如果能把一个端口视为一个对象，比如port，直接port.read()，这才叫优雅嘛！
+可喜的是，这在C++中是完全可以实现的：只需要实现一个类，其持有一个端口号作为成员变量，读写操作的实现则都使用内联汇编完成。
+这样就相当于在汇编操作外附加了一层C++的外衣，将原先裸的内联汇编代码包装成了C++代码，不仅提升了代码的可读性，而且由于存在C++的类作为中间层，可以添加很多保护性的代码，比如判断非法端口的访问、只读端口的写入等等，相比直接操作裸汇编代码提升了安全性和灵活性。
+端口驱动
+在实现端口驱动的时候，可以根据端口的读写权限分为三个类：
+
+Port类用来表示可读写的端口PortWriteOnly类用来表示只能写的端口PortReadOnly类用来表示只能读的端口
+对于Port类，由于汇编中的in和out指令都需要提供端口号，而既然我们现在打算将一个端口封装成一个Port的实例，那就不能每次调用读写函数的时候都提供一次端口号，而是要让实例在初始化的时候就记住它应当是哪个端口。由于这个端口号只有在初始化的时候被赋值，之后就不再需要更改或是暴露给程序，因此可以作为私有的const变量进行储存：
+1 2 private : const uint16 _port;
对于端口的读写函数，由于不同的端口位宽会存在不同，因此读写指令的返回值和参数的类型需要借助类模板的帮助：
+1 2 3 4 5 6 template <typename T>class Port { public : T read () const ; void write (T data) const }
又因为在内联汇编中，in和out指令都需要指定操作数的宽度，如inb或是inl，因此在读写函数的实现上，要使用sizeof(T)对模板类的类型参数位宽进行判断，再使用合适的内联汇编函数，例如：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 template <typename T>T Port<T>::read () const { if (sizeof (dat) == 1 ) { } else if (sizeof (dat) == 2 ) { } else { } }
对于一个8位端口，使用内联汇编的读取代码可以首先将端口号读取到dx，再使用inb指令读取端口数据到al，最后将数据从al写入到外部变量：
+1 2 3 4 5 6 7 8 asm volatile ( "movw %[p], %%dx \n\t" "inb %%dx, %%al \n\t" "movb %%al, %[o] \n\t" : [o] "=r" (_dat) : [p] "r" (_port) : )
内联汇编在编译的时候会检查外部变量的大小是不是和对应指令中指定的操作数宽度相匹配，例如movw指令不能提供一个uint16类型的变量，因此如果直接将T data作为参数传入，会发生报错。对于这个问题，可以在使用sizeof()判断后，显示地将data转换为对应的大小，或是先赋值到一个明确宽度的变量（例如：uint8 _data）中，再在C++中赋值给原先的变量：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 template <typename T>T Port<T>::read () const { T dat; if (sizeof (dat) == 1 ) { uint8 _dat = static_cast <uint8>(dat); asm volatile ( "movw %[p], %%dx \n\t" "inb %%dx, %%al \n\t" "movb %%al, %[o] \n\t" : [o] "=r" (_dat) : [p] "r" (_port) : ) dat = _dat; } return dat; }
由于只写或是只读的端口在读、写函数的实现上与可读写端口中的读写函数没有任何区别，因此在我最初的实现中将Port类作为基类而PortWriteOnly和PortReadOnly私有继承Port，之后封装父类中对应的函数为类的公有接口，例如：在Port中的public: void _write(T data)函数在私有继承后，在PortWriteOnly中添加public: void write(T data) { _write(data); }来调用基类中的写接口，而不对读接口进行封装，来实现读写权限的限制。
+但在后续的实验中我发现，即便父类中的函数由于继承已经实质是类的私有函数，但在Intellisense中仍然可以看到，感觉还是不够安全。因此我决定不继承的方式，转而对于PortWriteOnly存储一个Port类型的成员变量代替Port中的端口号，在写函数中调用Port::write函数，彻底杜绝在PortWriteOnly中出现read函数的提示。
+1 2 3 4 5 6 7 8 9 10 11 template <typename T>class PortWriteOnly { public : PortWriteOnly (uint16 port) : _port(port) {} private : const Port<T> _port; public : void write (T data) const _port.write (data); } };
完整的端口驱动ports.h如下：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 #include "types.h" #ifndef _PORT_H_ #define _PORT_H_ template <typename T>class Port { public : Port (uint16 port): _port(port) {} private : const uint16 _port; public : T read () const ; void write (T data) const }; template <typename T>class PortWriteOnly { public : PortWriteOnly (uint16 port) : _port(port) {} private : const Port<T> _port; public : void write (T data) const _port.write (data); } }; template <typename T>class PortReadOnly { public : PortReadOnly (uint16 port) : _port(port) {} private : const Port<T> _port; public : T read () const { return _port.read (); } }; template <typename T>T Port<T>::read () const { T dat; if (sizeof (dat) == 1 ) { uint8 _dat = static_cast <uint8>(dat); asm volatile ( "movw %[p], %%dx \n\t" "inb %%dx, %%al \n\t" "movb %%al, %[o] \n\t" : [o] "=r" (_dat) : [p] "r" (_port) : ) dat = _dat; } else if (sizeof (dat) == 2 ) { uint16 _dat = static_cast <uint16>(dat); asm volatile ( "movw %[p], %%dx \n\t" "inw %%dx, %%ax \n\t" "movw %%ax, %[o] \n\t" : [o] "=r" (_dat) : [p] "r" (_port) : ) dat = _dat; } else { uint32 _dat = static_cast <uint32>(dat); asm volatile ( "movw %[p], %%dx \n\t" "inl %%dx, %%eax \n\t" "movl %%eax, %[o] \n\t" : [o] "=r" (_dat) : [p] "r" (_port) : ) dat = _dat; } return dat; } template <typename T>void Port<T>::write (T data) const { if (sizeof (data) == 1 ) { asm volatile ( "movb %[i], %%al \n\t" "movw %[p], %%dx \n\t" "outb %%al, %%dx \n\t" : : [i] "r" (static_cast <uint8>(data)), [p] "r" (_port) ) } else if (sizeof (data) == 2 ) { asm volatile ( "movw %[i], %%ax \n\t" "movw %[p], %%dx \n\t" "outw %%ax, %%dx \n\t" : : [i] "r" (static_cast <uint16>(data)), [p] "r" (_port) ); } else { asm volatile ( "movl %[i], %%eax \n\t" "movw %[p], %%dx \n\t" "outl %%eax, %%dx \n\t" : : [i] "r" (static_cast <uint32>(data)), [p] "r" (_port) ); } } #endif
陷阱：模板类的函数应在头文件中定义 所有的模板类函数都需要在头文件中就实现函数的定义 。
+
硬盘驱动
+
+要将硬盘的读写操作抽象成驱动，在实验中使用了与第三章中相同的PIO模式对硬盘进行访问，在这个模式下与硬盘通信需要使用到8个不同的端口：
+
+
+
+端口号
+端口数据传输方向
+作用 (LBA28)
+描述
+位长 (LBA28)
+
+
+
+
+0x1F0
+读/写
+数据寄存器
+硬盘读出/要写入的数据
+16-bit
+
+
+0x1F1
+读
+错误码寄存器
+存储执行的ATA指令所产生的错误码
+8-bit
+
+
+0x1F1
+写
+功能寄存器
+用来指定特定指令的接口功能
+8-bit
+
+
+0x1F2
+读/写
+扇区数寄存器
+存放需要读写的扇区数量
+8-bit
+
+
+0x1F3
+读/写
+起始扇区寄存器
+存放起始扇区0-7位
+8-bit
+
+
+0x1F4
+读/写
+起始扇区寄存器
+存放起始扇区8-15位
+8-bit
+
+
+0x1F5
+读/写
+起始扇区寄存器
+存放起始扇区16-23位
+8-bit
+
+
+0x1F6
+读/写
+磁盘、起始扇区寄存器
+选择磁盘和访问模式
+8-bit
+
+
+0x1F7
+读
+状态寄存器
+读取当前磁盘状态
+8-bit
+
+
+0x1F7
+写
+指令寄存器
+传送ATA指令
+8-bit
+
+
+
+既然前面已经实现了端口的驱动，那么在这里就可以直接投入使用了，将列表中的端口按照对应的读写权限和用途实例化作硬盘类HDDManager的私有成员变量：
+1 2 3 4 5 6 7 8 9 10 11 private : const Port<uint16> _datPort = 0x1F0 ; const PortReadOnly<uint8> _errPort = 0x1F1 ; const PortWriteOnly<uint8> _funcPort = 0x1F1 ; const Port<uint8> _secCntPort = 0x1F2 ; const Port<uint8> _lbaLoPort = 0x1F3 ; const Port<uint8> _lbaMidPort = 0x1F4 ; const Port<uint8> _lbaHiPort = 0x1F5 ; const Port<uint8> _drivePort = 0x1F6 ; const PortReadOnly<uint8> _statusPort = 0x1F7 ; const PortWriteOnly<uint8> _cmdPort = 0x1F7 ;
注意到，对于0x1F7端口，当其作为读端口时用来表示硬盘的状态，其表示形式为按位枚举，端口读出值的每一位都有对应的含义：
+
+
+
+端口号
+位
+缩写
+作用
+
+
+
+
+0x1F7 (Read)
+0
+ERR
+指示是否有错误发生，通过发送新指令可以清除该位
+
+
+0x1F7 (Read)
+1*
+IDX
+索引，始终置为0
+
+
+0x1F7 (Read)
+2*
+CORR
+修正数据，始终置位0
+
+
+0x1F7 (Read)
+3
+DRQ
+0：硬盘还不能交换数据1：硬盘存在可以读取的数据或是可以写入数据
+
+0x1F7 (Read)
+4*
+SRV
+重叠模式服务请求
+
+
+0x1F7 (Read)
+5*
+DF
+驱动器故障错误
+
+
+0x1F7 (Read)
+6*
+RDY
+0：驱动器发生了减速或是错误1：驱动器运转正常
+
+0x1F7 (Read)
+7
+BSY
+忙位0：空闲1：忙
+
+
+
+什么是按位枚举： 利用二进制位来表示某个事物的属性 ，不同的二进制位描述不同的属性 。2 0 2^0 2 0 2 1 2^1 2 1 不同的二进制位应当描述不同的属性 ，例如如果要表示性别应当使用一个二进制位的0和1来区别，而不是 使用两个二进制位，一个置位表示男，另一个置位则表示女。
+
由上述的列表中可以看出0x1F7中的每个二进制位都确实描述了一个硬盘状态的不同属性，对于这样的二进制位枚举，可以通过enum来表示：
+1 2 3 4 5 6 7 8 9 10 enum HDDStatus { ERR_OCCURRED = 1 , IDX = 1 << 1 , CORR = 1 << 2 , DATA_READY = 1 << 3 , OVERLAPP_SRVICE_REQUEST = 1 << 4 , DRIVE_FAULT_ERR = 1 << 5 , DRIVE_READY = 1 << 6 , BUSY = 1 << 7 };
但糟就糟在C++对按位枚举的支持并不好，由于C++默认将枚举类型作为整型值处理，所以常见的按位操作是默认支持的：
+
+|：按位或，合并存在的属性&：按位与，用掩码取出某个属性的值，例如flag & 0x0F可以单独取出低四位的属性值~：按位取反，用来反转所有属性值^：按位异或，用来反转某个属性值，例如flag ^= 0x08可以反转第4位属性的值
+但如果想重载一些特殊的运算，或是添加一些特殊的判断函数，枚举类型则显得无从下手了：
+
+-：删除某个属性+：添加某个属性contains(flag)：判断是否包含flag中的全部属性
+为了支持这些操作，可以使用C++的类对原本的枚举类型进行一次封装：将枚举类型声明在C++类内，使用一个私有变量存储实际的枚举值，并通过重载运算符的方式从而让类的实例能够支持上述所有的运算操作 。
+对于目前而言，为硬盘的状态属性定义类HDDStatusFlag，并将原先的枚举类型声明在这个类内：
+1 2 3 4 5 6 7 8 9 10 11 12 13 class HDDStatusFlag { public : enum ATTR { ERR_OCCURRED = 1 , IDX = 1 << 1 , CORR = 1 << 2 , DATA_READY = 1 << 3 , OVERLAPP_SRVICE_REQUEST = 1 << 4 , DRIVE_FAULT_ERR = 1 << 5 , DRIVE_READY = 1 << 6 , BUSY = 1 << 7 }; }
这样，如果想访问枚举类型中的某个常量值，例如BUSY，可以使用HDDStatusFlag::BUSY或是HDDStatusFlag::ATTR:BUSY访问到。
+由于0x1F7端口为8位端口，所以对于HDDStatusFlag这个枚举类，其实际需要存储的数据为byte类型，因此可以使用一个byte类型的变量作为其私有成员，用来存储实际的枚举值：
+为了能直接使用整型值给HDDStatusFlag类型的变量赋值，需要定义一个参数为byte类型的构造函数：
+1 2 3 4 public : HDDStatusFlag (byte flags) { _attr = static_cast <byte>(flags); }
有了这样的一个构造函数，类的实例就可以使用如下的方式构造了：
+1 2 3 HDDStatusFlag flag = HDDStatusFlag::ERR_OCCURRED | HDDStatusFlag::BUSY; HDDStatusFlag flag = 0x81 ;
至于其他的按位操作、特殊运算和判断函数的实现此处就不再赘述，无外乎就是对运算符进行重载，然后再对实际的值进行对应的运算或判断即可。
+在完成了硬盘硬盘状态类的设计后，就可以开始实现硬盘的读写函数了。以硬盘的读取为例，其分为两个主要的步骤：从硬盘读取以及写入内存中的缓冲区。
+由于目前在KernelLoader中没有一个完善的内存管理机制，而进入内核之后内存将可以通过堆分配器分配空闲的内存供程序使用，两者在内存申请上会存在很大的区别。
+如果让HDDManager自行管理其在读写时需要用到的缓冲区的话，就需要分别为KernelLoader环境和内核环境设计不同的缓冲区申请和释放的机制，相当麻烦。考虑到驱动的通用性，所以不妨让内存申请的步骤对HDDManager这个类完全不可见，由调用读写函数的调用者主动申请对应大小的内存，并将申请到的内存首地址作为参数传递给读写函数，所以读写函数的签名声明如下：
+1 2 3 public : bool readSector (uint idx, uint cnt, byte* dst) bool writeSector (uint idx, uint cnt, byte* src)
在读写函数的实现上，可以将多个扇区的读写拆分为多个单独扇区的读写，将单个扇区的读写函数作为私有成员仅供公有读写函数调用。
+1 2 3 private : bool _readOneSector(uint idx, byte* dst); bool _writeOneSector(uint idx, byte* src);
以读取的函数为例，单个扇区的读取步骤如下：
+
+向_secCntPort端口写入读取的扇区数量0x01
+向_lbaLoPort端口写入读取的扇区号低8位
+向_lbaMidPort端口写入读取的扇区号8至15位
+向_lbaHiPort端口写入读取的扇区号高16至23位
+向_drivePort端口写入读取的扇区号高4位以及驱动的参数0xE0
+向_cmdPort端口写入读取命令0x20
+等待硬盘就绪，从_statusPort中读取硬盘的状态，如果状态包含了HDDStatusFlag::DATA_READY属性，则意味着硬盘数据准备完毕
+读取512字节到缓冲区中
+
+其中，如果在等待硬盘就绪的步骤中发生了错误，则会使用false返回值表示读取失败。
+具体的实现如下：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 bool HDDManager::_readOneSector(uint idx, byte* dst) { _secCntPort.write (0x01 ); _lbaLoPort.write ((uint8)idx); _lbaMidPort.write ((uint8)(idx >> 8 )); _lbaHiPort.write ((uint8)(idx >> 16 )); _drivePort.write (((uint8)(idx >> 24 )) | 0xE0 ); _cmdPort.write (0x20 ); while (true ) { HDDStatusFlag status = _statusPort.read (); if (status.contains (HDDStatusFlag::ERR_OCCURRED)) { return false ; } if (status.contains (HDDStatusFlag::DATA_READY)) { break ; } } for (int i = 0 ; i < 512 ; i += 2 ) { uint16 tmpDat = _datPort.read (); *(uint16*)(dst + i) = tmpDat; } return true ; }
在读取多扇区的函数中，如果读取某个扇区时_readOneSector函数返回了false值，则会进而读取_errPort中的错误信息，写入缓冲区首2字节中，并返回false告知主调函数在硬盘读取过程中出现了错误。如果没有遇到错误，则继续下一个扇区的读取，然后向主调函数返回true。
+具体的实现如下：
+1 2 3 4 5 6 7 8 9 10 11 12 bool HDDManager::readSector (uint idx, uint cnt, byte* dst) uint offset = 0 ; for (uint i = 0 ; i < cnt; i++) { if (!_readOneSector(idx + i, (byte*)(dst + offset))) { uint8 err = _errPort.read (); memcpy (dst, &err, 8 ); return false ; } offset += 512 ; } return true ; }
对于硬盘写，操作则与硬盘读大同小异，仅仅是将数据的传输方向颠倒，从由_datPort读出数据变为向_datPort写入数据，从写入缓冲区变为从缓冲区取出数据而已，此处便不再赘述。
+完整的hdd.h头文件如下：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 #include "types.h" #include "memory.h" #include "ports.h" #ifndef _HDD_H_ #define _HDD_H_ class HDDStatusFlag { public : enum ATTR { ERR_OCCURRED = 1 , IDX = 1 << 1 , CORR = 1 << 2 , DATA_READY = 1 << 3 , OVERLAPP_SRVICE_REQUEST = 1 << 4 , DRIVE_FAULT_ERR = 1 << 5 , DRIVE_READY = 1 << 6 , BUSY = 1 << 7 }; HDDStatusFlag () {} HDDStatusFlag (byte flags) { _attr = static_cast <byte>(flags); } HDDStatusFlag& operator =(byte flags) { _attr = static_cast <byte>(flags); return *this ; } HDDStatusFlag& operator =(const HDDStatusFlag& other) { _attr = other._attr; return *this ; } bool operator ==(byte flags) { return _attr == static_cast <byte>(flags); } HDDStatusFlag operator +(byte flags) { byte newAttr = _attr | static_cast <byte>(flags); return HDDStatusFlag (static_cast <byte>(newAttr)); } HDDStatusFlag& operator +=(byte flags) { _attr |= static_cast <byte>(flags); return *this ; } HDDStatusFlag operator -(byte flags) { byte newAttr = _attr & ~(static_cast <byte>(flags)); return HDDStatusFlag (static_cast <byte>(newAttr)); } HDDStatusFlag& operator -=(byte flags) { _attr &= ~(static_cast <byte>(flags)); return *this ; } HDDStatusFlag operator |(byte flags) { byte newAttr = _attr | static_cast <byte>(flags); return HDDStatusFlag (static_cast <byte>(newAttr)); } HDDStatusFlag& operator |=(byte flags) { _attr |= static_cast <byte>(flags); return *this ; } HDDStatusFlag operator &(byte flags) { byte newAttr = _attr & static_cast <byte>(flags); return HDDStatusFlag (static_cast <byte>(newAttr)); } HDDStatusFlag& operator &=(byte flags) { _attr &= static_cast <byte>(flags); return *this ; } HDDStatusFlag operator ~() { return HDDStatusFlag (static_cast <byte>(_attr)); } HDDStatusFlag& operator ^=(byte flags) { _attr ^= static_cast <byte>(flags); return *this ; } bool contains (byte flags) return (_attr & static_cast <byte>(flags)) == static_cast <byte>(flags); } private : byte _attr; }; class HDDManager { public : HDDManager () {} private : const Port<uint16> _datPort = 0x1F0 ; const PortReadOnly<uint8> _errPort = 0x1F1 ; const PortWriteOnly<uint8> _funcPort = 0x1F1 ; const Port<uint8> _secCntPort = 0x1F2 ; const Port<uint8> _lbaLoPort = 0x1F3 ; const Port<uint8> _lbaMidPort = 0x1F4 ; const Port<uint8> _lbaHiPort = 0x1F5 ; const Port<uint8> _drivePort = 0x1F6 ; const PortReadOnly<uint8> _statusPort = 0x1F7 ; const PortWriteOnly<uint8> _cmdPort = 0x1F7 ; bool _readOneSector(uint idx, byte* dst); bool _writeOneSector(uint idx, byte* src); public : bool readSector (uint idx, uint cnt, byte* dst) bool writeSector (uint idx, uint cnt, byte* src) }; #endif
头文件中的函数定义则都存放在hdd.cpp中，完整的内容如下：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 #include "hdd.h" bool HDDManager::_readOneSector(uint idx, byte* dst) { _secCntPort.write (0x01 ); _lbaLoPort.write ((uint8)idx); _lbaMidPort.write ((uint8)(idx >> 8 )); _lbaHiPort.write ((uint8)(idx >> 16 )); _drivePort.write (((uint8)(idx >> 24 )) | 0xE0 ); _cmdPort.write (0x20 ); while (true ) { HDDStatusFlag status = _statusPort.read (); if (status.contains (HDDStatusFlag::ERR_OCCURRED)) { return false ; } if (status.contains (HDDStatusFlag::DATA_READY)) { break ; } } for (int i = 0 ; i < 512 ; i += 2 ) { uint16 tmpDat = _datPort.read (); *(uint16*)(dst + i) = tmpDat; } return true ; } bool HDDManager::_writeOneSector(uint idx, byte* src) { _secCntPort.write (0x01 ); _lbaLoPort.write ((uint8)idx); _lbaMidPort.write ((uint8)(idx >> 8 )); _lbaHiPort.write ((uint8)(idx >> 16 )); _drivePort.write (((uint8)(idx >> 24 )) | 0xE0 ); _cmdPort.write (0x30 ); while (true ) { HDDStatusFlag status = _statusPort.read (); if (status.contains (HDDStatusFlag::ERR_OCCURRED)) { return false ; } if (status.contains (HDDStatusFlag::DATA_READY)) { break ; } } for (int i = 0 ; i < 512 ; i += 2 ) { uint16 tempDat = *(uint16*)(src + i); _datPort.write (tempDat); } return true ; } bool HDDManager::readSector (uint idx, uint cnt, byte* dst) uint offset = 0 ; for (uint i = 0 ; i < cnt; i++) { if (!_readOneSector(idx + i, (byte*)(dst + offset))) { uint8 err = _errPort.read (); memcpy (dst, &err, 8 ); return false ; } offset += 512 ; } return true ; } bool HDDManager::writeSector (uint idx, uint cnt, byte* src) uint offset = 0 ; for (uint i = 0 ; i < cnt; i++) { if (!_writeOneSector(idx + i, (byte*)(src + offset))) { uint8 err = _errPort.read (); memcpy (src, &err, 8 ); return false ; } offset += 512 ; } return true ; }
现在，如果想要从硬盘中读取某个或是某几个扇区，例如，读取5~12扇区，则可以调用HDDManager中的readSectors函数如下：
+1 2 3 4 5 byte buffer[512 * 8 ]; memset (buffer, 0 , 512 * 8 );HDDManager ().readSectors (5 , 8 , buffer);
可以看到，代码明显比原先使用汇编时更加地简洁，也更易于阅读，这也就是编写驱动的目的。
+抽象FAT文件系统
+在BootLoader开启了保护模式之后，所有的一切操作，包括上一小节中编写的驱动都是在为了内核的加载而铺路。
+加载： 读入内存 中以及将内核的各个部分放置在正确的物理地址处 这两个步骤
+
加载这一个环节又自然离不开将内核编译后的可执行代码从硬盘读入内存的步骤
+在学校教程的实现中，内核被编译为裸二进制文件，也就是.bin文件，像MBR和BootLoader那样直接写入硬盘对应的扇区。在读取的时候，由于写入的起始扇区和扇区数量都已知，所以可以直接从硬盘读取对应的扇区到内存中。由于内核已经被编译为裸二进制文件，只需要将整个文件读取到对应的地址处就完成了内核的加载操作，而不需要额外的操作。
+固然，使用这个方式是简单而且方便的，但我始终觉得这样不够优雅。于是我简单地了解了Linux中一个叫做grub的启动引导程序，简单来讲，grub的启动分为了三个阶段：
+
+第一个阶段 (stage 1) 就基本相当于我们所编写的MBR部分，其负责从硬盘上加载中间阶段 (stage 1.5) 的代码的首扇区，也就相当于我们的BootLoader
+这个中间阶段 (stage 1.5) 首扇区代码负责将剩余代码载入内存，之后剩余代码会找到活动分区下/boot/grub/目录中的启动程序，也即第二阶段程序 (stage 2) ，然后加载到内存运行
+在第二阶段 (stage 2) 中，程序会解析/boot/grub/grub.cfg文件，显示一个启动菜单给用户，并且负责加载对应系统中的内核运行
+
+
+由于grub在中间阶段就引入了对文件系统的加载，从而可以从分区目录中读取需要的文件，看起来就比直接读取裸二进制文件要优雅得多了。因此我决定放弃学校教程的思路，转而在KernelLoader中实现一个简单版的grub程序，其可以从分区的/system/目录下找到内核文件并加载。
+为了能够在KernelLoader中读取分区中的目录和文件信息，就必须要让代码能够解析分区上的文件系统，由于FAT是一个成熟且简单的文件系统，所以在实验中硬盘采用了FAT格式进行格式化。
+尽管文件系统中存储的文件不尽相同，但对于同一个格式的文件系统，它们又都有着相同之处，例如文件系统包含了哪些结构，文件在文件系统中是怎样被组织的等等，这些不同中的相同之处就是我们解析文件系统的关键之处。
+我们现在所需要做的就是用代码表示出这些相同的部分，并探究这些相同部分中的信息如何给文件的读取以提示 ，如何帮助我们了解文件系统中的内容。在下一章中，我们会更进一步，了解如何通过这部分信息从文件系统中读取需要的文件。
+抽象：
+
简述文件系统与FAT
+
+文件系统是对文件的一种组织形式，所以文件固然也就是文件系统中至关重要的部分，了解文件系统首先就要了解文件的构成。
+不论是哪种类型的文件，不论是.doc、.ppt还是.txt抑或是.bin，在硬盘的视角来看，它们中的数据实际上都是一系列二进制的数据块，而类别的区别只在于这些数据内部的组织形式，并不会让它们看起来是除了二进制数据块以外的其他样子。
+但是如果一个文件只有数据块又不太够，文件名称 是用户用以区分不同文件的关键信息，文件名称有时候对于文件系统来说太复杂了，所以文件系统会用一些特殊的方式记录用户提供的文件名称并通过其来识别不同的文件，这种记录有时候会呈现以标识符 的形式，在FAT文件系统中则是一系列字符串。
+除此之外，文件还需要一些其他的信息，例如其类型、数据在硬盘上的位置、尺寸、访问权限、创建或修改日期等等。
+可见，文件由两个关键的部分组成，一个是文件的数据，也就是一系列二进制数据块，另一个则是文件的信息，它用来区分不同的文件并在硬盘上定位到文件数据的位置。
+
+在文件系统组织文件的时候，其实际上就是在建立索引文件的数据结构，由于文件是由两部分构成的，文件系统中也就存在着两种主要的数据结构，分别用来索引文件的这两个组成部分。
+其中一个数据结构用来索引文件的信息，这部分数据结构一般呈现树形的结构，文件系统中的文件目录就是由这个数据结构所维护的，树中每个节点都存储着一个文件或是目录的信息。
+
+另一个数据结构则用于通过文件的信息来索引文件的数据，由于一个文件可能跨越数个甚至数十、数百个扇区，由于文件时时刻刻都可能会被更改，所以没有办法预先给文件分配一段固定的、连续的、大小适当的空间，因此文件的数据往往分散在磁盘的各个位置，这时就需要一个数据结构来将这些游离的数据块串接起来。说到这里，可能大家就已经能猜到，这部分数据结构一般以链表的形式出现。每一个文件块都对应着一个下一文件块的位置信息，而第一个文件块的位置信息则存储于文件的信息中。
+下图表示了一个文件系统磁盘中可能的样子：
+
+#0标号的内存空间对应着系统的根目录/节点，其内部有两个有效的文件信息，分别是system和home，均为目录类别。system首文件块指向#8，并且#8为其最后一个文件块，因此#8实际上就对应着/system/节点，其中存储了kernel.elf一个文件的信息。对于home，首文件块指向#14，其下一个文件块为#16，并且是最后一个文件块，因此#14,#16共同构成/home/节点，在这个节点中存储了两个有效文件信息，分别是boo.baz和bar，分别是文件和目录。
+kernel.elf首文件块为#4，#4下一个文件块为#6，#6为最后一个文件块，因此kernel.elf对应的文件数据为#4,#6上的数据。boo.baz首文件块为#10，后续文件块依次为#12、#5。因此#10,#12,#5共同构成boo.baz文件的数据bar首文件块指向#18，后续文件块为#11，因此#18,#11共同构成了目录树中的/home/bar/节点的子树信息
+
+由上图可以看出，目录树的遍历方式是要与数据结构中树的遍历方式有很大不同的。每一个节点实际上都对应着一个存储着其子节点的文件的信息的数组 ，通过这个数组，可以获得子节点对应文件的首块信息，再依据链表就能够获得全部的文件数据。只有当取得了全部的文件数据，才可以进入下一层的节点。
+简单来说，就是在/目录下，我们只能得到system/和home/的信息，但是我们不能从这些信息中直接得到system/下或是home/下有什么文件，除非我们把它们的数据完整地读取出来。
+而在一般的数据结构中，对于根节点root，我们只需要访问child = root->children[0]就可以获得整个子节点，得到的child就包含了其所有的子节点数据，而不需要额外的加载操作。
+现在，假设我们需要访问/system/kernel.elf文件，那么就需要
+
+首先从树的根部开始，找到类型为目录，名称为system的信息
+从信息中读取出目录数据的第一个块#8，并根据链表中的信息读入整个目录，由于这里只有一个块，所以就读入#8
+在目录的数据中找到类型为文件，名称为kernel.elf的信息
+从信息中读出文件数据的第一个块#4，并根据链表读入#6，得到整个文件。
+
+不过，为了提高文件读写的速度，系统一般会维护一个打开的文件表 (Open-file table) 用于维护所有打开的文件的信息，所以一般来说，当打开一个文件的时候，除了会将它的全部数据就被读取到内存中，还会将其信息添加到打开文件表中，后续所有的增删改都只会对内存中的数据起作用，直到文件关闭时才再次写回磁盘。这样就避免了每次读写过程中对文件数据的定位以及读取。
+好戏还在后面
+
不过，上面只是对文件系统的一种简单的概述，不同的文件系统会有不同的组织文件的方式，但核心总还是离不开怎样组织文件的数据以及如何通过文件的信息索引到文件的数据，区别大抵是数据结构的差异以及具体实现上的差异。
+例如，在上世纪出现的FAT中，由于软盘随机读取的性能奇差，所以如果像上文中图片绘制的那样，在文件数据块的末尾添加上下一个文件块的信息，糟糕的问题就会出现：如果尝试在文件尾部添加些什么，那需要遍历之前所有的文件块才能知道最后一个文件块在哪个位置！
+为此，工程师们将所有文件块中关于下一个块的信息独立出来，存放在磁盘中的一个连续的空间内，这个空间也被称作文件分配表 (File Allocation Table) ，也就是FAT实际的意义。这样，只需要提前把这一部分空间读取到内存中，就可以很快地定位到文件任意个块的信息了。
+
+同时，这样做还有一个好处，一个512字节或是其整数倍的块需要分配几个字节给下一个块的块号，导致每个文件块实际数据大小不是2的幂，现在由于将这部分信息独立出来，所以每一个文件块都是完整的512字节或是512字节的倍数。
+但是，如果每个数据块只占据1个扇区的话，对于大磁盘来说，需要的块号还是太多了，于是工程师就提出了簇 (cluster) 的概念，一簇由许多个扇区组成，而这个簇就相当于前文中的数据块。
+这样，在FAT中存储簇号就大大减少了FAT的大小，虽然增加了碎片，但是提升了文件读写的效率。
+碎片：
+
第一篇文档
+在了解了文件系统是怎样组织和存储文件之后，对于如何从文件系统中读取文件应该有了思路。
+但是细细一想又会发现很多问题，例如：根目录存储在磁盘的哪个位置、如何知道一个簇有多大、文件名是如何存储的、怎样才代表当前的簇是文件的最后一个簇等等
+这便是因为文件系统很多具体的细节还没有落实，程序还无法从现有的文件系统中获得需要的数据。而这就是本节的目的，通过阅读微软关于FAT文件系统的规范文档 ，对FAT文件系统进行抽象，并且提供接口来解决上面提到的种种问题。
+下载FAT规范文档 我的服务器 上下载我做过简单批注的版本原链接 下载官方版本
+
定义与注解
+第一章大体可以略过，其中较为重要的概念如下：
+
+簇 (cluster)： 文件分配的单元 (A unit of allocation) ，其中包括了一组逻辑连续的扇区。卷内的每个簇都可以通过一个簇号N指代 (referred to) 。给任何一个文件所分配的全部空间的大小 *(All allocation for a file)*必须是簇的整数倍。分区 (partition)： 在一个卷内的一系列扇区卷 (volume)： 一个逻辑上的连续的扇区地址空间
+卷结构
+第二章主要介绍了FAT格式卷的结构，除了上文中提到的用来存储下一个簇信息的FAT区域 (FAT Region) 以及存储文件数据的区域 (File and Directory Data Region) ，还包括了一个保留区 (Reserved Region) 和一个根目录区 (Root Directory Region) 。
+
+一个FAT格式的卷结构大概长得就像下面这样
+
+陷阱：小端模式 小端模式 。
+
BPB数据结构
+在FAT格式的卷的首扇区，有一个叫做BPB (Bios Parameter Block) 的数据结构，其主要存储了关于当前卷上FAT文件系统的关键信息，包括了文件系统各个区域的首扇区号，以及簇大小等等。
+注： BPB_ 开头的域才是属于BPB结构体的域In the following description, all the fields whose names start with BPB_ are part of the BPB. All the fields whose names start with BS_ are part of the boot sector and not really part of the BPB.
+
对于FAT12/16和FAT32，它们的BPB结构在首36字节上完全一致：
+
+
+
+域名称
+偏移
+大小
+描述
+限制
+
+
+
+
+BS_jmpBoot
+0
+3
+跳转到启动代码处执行的指令
+一般为0x90**EB或是0x****E9
+
+
+BS_OEMName
+3
+8
+OEM厂商的名称，同样与实验无关，不需要关心
+-
+
+
+BPB_BytsPerSec 11
+2
+每个扇区的字节数 只能是512、1024、2048或4096
+
+BPB_SecPerClus 13
+1
+每个簇的扇区数量 只能是1、2、4、8、16、32、64和128
+
+BPB_RsvdSecCnt 14
+2
+保留区域的扇区数量 不能为0，可以为任意非0值
+
+BPB_NumFATs 16
+1
+FAT表数量 一般为2，也可以为1
+
+
+BPB_RootEntCnt 17
+2
+根目录中的条目数 FAT32： 必须为0FAT12/16： 必须满足( B P B _ R o o t E n t C n t × 32 ) ≡ 0 ( m o d 2 ) (BPB\_RootEntCnt \times 32) \equiv 0\;(mod\;2) ( BPB _ R oo tE n tC n t × 32 ) ≡ 0 ( m o d 2 )
+
+BPB_TotSec16 19
+2
+16位长度卷的总扇区数 FAT32： 必须位0FAT12/16： 如果总扇区数小于0x10000（也就是能用16位表示）则使用此域表示，否则也使用BPB_TotSec32域
+
+BPB_Media
+21
+1
+似乎是设备的类型
+合法取值包括0xF0、0xF8、0xF9、0xFA、0xFB、0xFC、0xFD、0xFE和0xFF0xF80xF0
+
+
+BPB_FATSz16 22
+2
+单个FAT表占用的扇区数 FAT32： 必须为0FAT12/16： 正整数值
+
+BPB_SecPerTrk
+24
+2
+每个扇区的磁道数0x13中断相关0x13中断可见的存储介质有关
+-
+
+
+BPB_NumHeads
+26
+2
+磁头数量0x13中断相关，实验不会使用，所以可以不用关心
+-
+
+
+BPB_HiddSec 28
+4
+分区前隐藏的扇区数 0x13中断可见的存储介质有关，但在实验过程中发现对于一个多分区的磁盘，这个域对应了分区首扇区在整个磁盘中的扇区号 ，例如首扇区位于磁盘2048扇区（从0开始计算分区号）的分区，其BPB_HiddSec域值就为2048-
+
+
+BPB_TotSec32 32
+4
+32位长度卷的总扇区数 FAT32： 必须为非零整数值FAT12/16： 如果扇区数大于0x10000，则为扇区数，否则必须为0
+
+
+从第37字节开始，FAT12和FAT16卷上的BPB结构如下：
+
+
+
+域名称
+偏移
+大小
+描述
+限制
+
+
+
+
+BS_DrvNum
+36
+1
+用于0x13中断的驱动器号，可以不用关心
+应当设置为0x80或是0x00
+
+
+BS_Reserved1
+37
+1
+保留位
+必须为0
+
+
+BS_BootSig
+38
+1
+用来检验启动扇区的完整性的签名，可以不用关心
+如果BS_VolID、BS_VolLab和BS_FilSysType三个域都存在有效的值 (present) ，则置为0x29
+
+
+BS_VolID
+39
+4
+卷的序列号，可以不用关心
+-
+
+
+BS_VolLab
+43
+11
+卷标，可以不用关心
+缺省值为"NO NAME"
+
+
+BS_FilSysType
+54
+8
+用来描述文件系统类型，但不能用来作为判断文件系统类型的依据
+“FAT12”、“FAT16"或是"FAT32”
+
+
+-
+62
+448
+空余，置零
+必须为0
+
+
+Signature_word
+510
+2
+校验位
+设置为0xAA55
+
+
+-
+512
+*
+如果B P B _ B y t s P e r S e c > 512 BPB\_BytsPerSec \gt 512 BPB _ B y t s P er S ec > 512
+必须为0
+
+
+
+相对的，从37字节开始，FAT32文件系统中BPB的结构如下：
+
+
+
+域名称
+偏移
+大小
+描述
+限制
+
+
+
+
+BPB_FATSz32 36
+4
+单个FAT表占用的扇区数 非负整数值
+
+
+BPB_ExtFlags 40
+2
+标志位
+[0:3]： 活动FAT表的标号（按照从零开始计数）[4:6]：保留位[7]：当FAT在运行时会自动镜像写入其他FAT表时，置零，否则对于只有一个活动的FAT表时置位
+
+BPB_FSVer
+42
+2
+奇怪的版本号域，文档中写了半天描述最后要求置零…
+必须为0
+
+
+BPB_RootClus 44
+4
+根目录的首簇簇号 B P B _ R o o t C l u s > 2 BPB\_RootClus \gt 2 BPB _ R oo tCl u s > 2
+
+BPB_FSInfo 48
+2
+FSInfo结构体所在的首扇区号一般为1
+
+
+BPB_BkBootSec
+50
+2
+备份启动扇区的扇区号
+设置为0或6
+
+
+BPB_Reserved
+52
+12
+保留位
+必须为0
+
+
+BS_DrvNum
+64
+1
+用于0x13中断的驱动器号，可以不用关心
+应当设置为0x80或是0x00
+
+
+BS_Reserved1
+65
+1
+保留位
+必须为0
+
+
+BS_BootSig
+66
+1
+用来检验启动扇区的完整性的签名，可以不用关心
+如果BS_VolID、BS_VolLab和BS_FilSysType三个域都存在有效的值 (present) ，则置为0x29
+
+
+BS_VolID
+67
+4
+卷的序列号，可以不用关心
+-
+
+
+BS_VolLab
+71
+11
+卷标，可以不用关心
+缺省值为"NO NAME"
+
+
+BS_FilSysType
+82
+8
+用来描述文件系统类型，但不能用来作为判断文件系统类型的依据
+“FAT12”、“FAT16"或是"FAT32”
+
+
+-
+90
+420
+空余，置零
+必须为0
+
+
+Signature_word
+510
+2
+校验位
+设置为0xAA55
+
+
+-
+512
+*
+如果B P B _ B y t s P e r S e c > 512 BPB\_BytsPerSec \gt 512 BPB _ B y t s P er S ec > 512
+必须为0
+
+
+
+文档在接下来的部分介绍了如何初始化一个FAT卷，由于目前只需要读取FAT卷，所以可以忽略章节3.4。
+在3.5章节中文档就介绍了如何在装载卷时判断FAT的类型，其中关键的判断算法为
+1 2 3 4 5 6 7 if (CountofClusters < 4085 ) { } else if (CountofClusters < 65525 ) { } else { }
也就是说，FAT的类型只与簇的数量有关，而与磁盘的大小、扇区数量，包括BPB中的BPB_FilSysType域都无关，其中
+
+FAT12不能有超过4084个簇
+FAT16不能有超过65524个簇，也不能少于4085个簇
+
+在明白了BPB的结构之后，就可以开始着手对BPB进行抽象了。
+最初我采用了两个不同的类来分别对FAT12/16和FAT32的BPB进行抽象，但这样的问题也是十分明显的，在我不确定FAT实际的类型时我把首512字节视为哪个数据结构都不是很合理。但如果我不通过抽象后的数据结构去解析首512字节，我又没办法判断究竟是那种FAT类型。为了解决这个矛盾，我甚至由引入了一个类来描述FAT12/16与FAT32相同的37字节数据，这就导致代码越来越乱，看起来也让人云里雾里的。
+但后来就注意到虽然对于FAT12/16和FAT32，它们在结构上存在一定的不同，但其BPB有效的部分都是首扇区的首512字节（如果扇区大于512字节后面的也仍然填充0，可以忽略）。
+同时，BPB需要提供的主要功能也是基本相同的，主要的区别基本都在于域宽是16位还是32位。
+如果在函数接口的上不区分FAT12/16和FAT32，只在函数的实现上根据FAT12/16和FAT32的不同从512字节的数据中取出对应需要的域，就可以实现功能的统一，调用函数的代码就只需要关心需要使用FAT的哪种信息，而不需要再关心FAT的类型。
+例如，BPB_FATSz16和BPB_FATSz32实质上都是为了提供FAT表的大小，它们是可以统一到一个接口uint32 fatSize()上的，需要关心FAT表大小的代码不需要关心具体是哪种格式的FAT系统，只需要调用fatSize()既可以取得需要的数值，具体的解析操作交给了函数本身去区分和实现。
+阅读上表，可以总结出BPB所需要提供的所有接口：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 uint16 bytesPerSector () ;uint8 sectorsPerCluster () ;uint16 sectorsPerTrack () ;uint16 headCount () ;uint16 reservedSectorCount () ;uint32 hiddenSectorCount () ;uint32 totalSectors () ;uint8 fatCount () ;uint32 fatSize () ;uint8 activeFAT () ; bool isFATMirrored () uint16 rootEntryCount () ; uint32 rootCluster () ; char * oemName () uint8 mediaType () ;uint8 driveNumber () ;bool hasExtendedBootSignature () uint32 volumeSerialNumber () ;char * volumeLabel () char * fsTypeLabel () uint16 fsInfoSector () ;
可以注意到，有些函数是只有特定的FAT格式才存在的，这时如果调用者强行调用了一个当前FAT格式不存在的接口，实质上是不安全的，因为这样并不会产生任何错误，同时还会返回一个不确定的值。但这样的弊端比起这种实现的优点而言就显得微不足道了。
+更进一步地说，由于调用接口的代码只能是操作系统的代码所调用，而操作系统代码只能由我们所完成，所以我们可以通过主动避免错误的调用来避开这个风险 ，抑或是，可以在函数内额外判断一次FAT类型，并在不合法的调用处陷入死循环 等等，有很多可以解决的方法。
+除了解析BPB数据的接口以外，由于BPB主要的作用是计算FAT文件系统各个区域的大小、偏移量等信息，所以也不妨将这部分琐碎的代码纳入类的函数作为接口提供给其他程序：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 bool isFAT12 () bool isFAT16 () bool isFAT32 () uint32 fatEntrySize () ;uint32 fatFrstSec () ;uint32 fatFrstSecAbsolute () ;uint32 fatTotalSec () ;uint32 rootDirFrstSec () ;uint32 rootDirFrstSecAbsolute () ;uint32 rootDirTotalSec () ;uint32 dataFrstSec () ;uint32 dataFrstSecAbsolute () ;uint32 dataTotalSec () ;uint32 totalClusters () ;uint32 secOfCluster (uint32 clus) ;uint32 absoluteSecOfCluster (uint32 clus) ;
于是，完整的BPB头文件fatbpb.h如下：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 #include "types.h" #ifndef _FAT_BPB_H_ #define _FAT_BPB_H_ class FATBPB { private : byte _data[512 ]; public : FATBPB (uint32 bpbFrstSec); public : uint16 bytesPerSector () ; uint8 sectorsPerCluster () ; uint16 sectorsPerTrack () ; uint16 headCount () ; uint16 reservedSectorCount () ; uint32 hiddenSectorCount () ; uint32 totalSectors () ; uint8 fatCount () ; uint32 fatSize () ; uint8 activeFAT () ; bool isFATMirrored () uint16 rootEntryCount () ; uint32 rootCluster () ; char * oemName () uint8 mediaType () ; uint8 driveNumber () ; bool hasExtendedBootSignature () uint32 volumeSerialNumber () ; char * volumeLabel () char * fsTypeLabel () uint16 fsInfoSector () ; bool isFAT12 () bool isFAT16 () bool isFAT32 () uint32 fatEntrySize () ; uint32 fatFrstSec () ; uint32 fatFrstSecAbsolute () ; uint32 fatTotalSec () ; uint32 rootDirFrstSec () ; uint32 rootDirFrstSecAbsolute () ; uint32 rootDirTotalSec () ; uint32 dataFrstSec () ; uint32 dataFrstSecAbsolute () ; uint32 dataTotalSec () ; uint32 totalClusters () ; uint32 secOfCluster (uint32 clus) ; uint32 absoluteSecOfCluster (uint32 clus) ; }; #endif
具体的函数实现则放在fatbpb.cpp中如下：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 #include "fatbpb.h" #include "hdd.h" FATBPB::FATBPB (uint32 bpbFrstSec) { HDDManager ().readSector (bpbFrstSec, 1 , _data); } uint16 FATBPB::bytesPerSector () { return *(uint16*)(&_data[11 ]); } uint8 FATBPB::sectorsPerCluster () { return _data[13 ]; } uint16 FATBPB::sectorsPerTrack () { return *(uint16*)(&_data[24 ]); } uint16 FATBPB::headCount () { return *(uint16*)(&_data[26 ]); } uint16 FATBPB::reservedSectorCount () { return *(uint16*)(&_data[14 ]); } uint32 FATBPB::hiddenSectorCount () { return *(uint32*)(&_data[28 ]); } uint32 FATBPB::totalSectors () { return *(uint16*)(&_data[19 ]) == 0 ? *(uint32*)(&_data[32 ]) : (uint32)(*(uint16*)(&_data[19 ])); } uint8 FATBPB::fatCount () { return _data[16 ]; } uint32 FATBPB::fatSize () { uint32 fatSz16 = (uint32)(*(uint16*)(&_data[22 ])); if (fatSz16 != 0 ) { return fatSz16; } else { return *(uint32*)(&_data[36 ]); } } uint8 FATBPB::activeFAT () { return _data[40 ] & 0xF ; } bool FATBPB::isFATMirrored () return (_data[40 ] & 0x80 ) != 0 ; } uint16 FATBPB::rootEntryCount () { return *(uint16*)(&_data[17 ]); } uint32 FATBPB::rootCluster () { return *(uint32*)(&_data[44 ]); } char * FATBPB::oemName () return (char *)(&_data[3 ]); } uint8 FATBPB::mediaType () { return _data[21 ]; } uint8 FATBPB::driveNumber () { if (isFAT32 ()) { return _data[64 ]; } else { return _data[36 ]; } } bool FATBPB::hasExtendedBootSignature () if (isFAT32 ()) { return _data[66 ] == 0x29 ; } else { return _data[38 ] == 0x29 ; } } uint32 FATBPB::volumeSerialNumber () { if (isFAT32 ()) { return *(uint32*)(&_data[67 ]); } else { return *(uint32*)(&_data[39 ]); } } char * FATBPB::volumeLabel () if (isFAT32 ()) { return (char *)(&_data[71 ]); } else { return (char *)(&_data[43 ]); } } char * FATBPB::fsTypeLabel () if (isFAT32 ()) { return (char *)(&_data[82 ]); } else { return (char *)(&_data[54 ]); } } uint16 FATBPB::fsInfoSector () { return *(uint16*)(&_data[48 ]); } bool FATBPB::isFAT12 () uint32 totClus = totalClusters (); return totClus < 4085 ; } bool FATBPB::isFAT16 () uint32 totClus = totalClusters (); return totClus >= 4085 && totClus < 65525 ; } bool FATBPB::isFAT32 () uint32 totClus = totalClusters (); return totClus >= 65525 ; } uint32 FATBPB::fatEntrySize () { uint32 totClus = totalClusters (); if (totClus < 4085 ) { return 12 ; } else if (totClus < 65525 ) { return 16 ; } else { return 32 ; } } uint32 FATBPB::fatFrstSec () { return reservedSectorCount (); } uint32 FATBPB::fatFrstSecAbsolute () { return hiddenSectorCount () + reservedSectorCount (); } uint32 FATBPB::fatTotalSec () { return fatCount () * fatSize (); } uint32 FATBPB::rootDirFrstSec () { uint32 resvdSecCnt = reservedSectorCount (); uint32 fatSecCnt = fatTotalSec (); return resvdSecCnt + fatSecCnt; } uint32 FATBPB::rootDirFrstSecAbsolute () { uint32 resvdSecCnt = reservedSectorCount (); uint32 fatSecCnt = fatTotalSec (); uint32 hiddenSec = hiddenSectorCount (); return hiddenSec + resvdSecCnt + fatSecCnt; } uint32 FATBPB::rootDirTotalSec () { uint32 rootEntCnt = rootEntryCount (); uint32 bytsPerSec = bytesPerSector (); return (rootEntCnt * 32 + (bytsPerSec - 1 )) / bytsPerSec; } uint32 FATBPB::dataFrstSec () { uint32 resvdSecCnt = reservedSectorCount (); uint32 fatSecCnt = fatTotalSec (); uint32 rootSecCnt = rootDirTotalSec (); return resvdSecCnt + fatSecCnt + rootSecCnt; } uint32 FATBPB::dataFrstSecAbsolute () { uint32 resvdSecCnt = reservedSectorCount (); uint32 fatSecCnt = fatTotalSec (); uint32 rootSecCnt = rootDirTotalSec (); uint32 hiddenSec = hiddenSectorCount (); return hiddenSec + resvdSecCnt + fatSecCnt + rootSecCnt; } uint32 FATBPB::dataTotalSec () { uint32 totSec = totalSectors (); uint32 resvdSecCnt = reservedSectorCount (); uint32 fatSecCnt = fatTotalSec (); uint32 rootSecCnt = rootDirTotalSec (); return totSec - (resvdSecCnt + fatSecCnt + rootSecCnt); } uint32 FATBPB::totalClusters () { return dataTotalSec () / sectorsPerCluster (); } uint32 FATBPB::secOfCluster (uint32 clus) { uint32 frstDataSec = dataFrstSec (); uint32 clusterOffset = clus - 2 ; uint32 secPerClus = sectorsPerCluster (); return frstDataSec + clusterOffset * secPerClus; } uint32 FATBPB::absoluteSecOfCluster (uint32 clus) { uint32 frstDataSec = dataFrstSec (); uint32 clusterOffset = clus - 2 ; uint32 secPerClus = sectorsPerCluster (); uint32 hiddenSec = hiddenSectorCount (); return hiddenSec + frstDataSec + clusterOffset * secPerClus; }
FAT
+回顾： (File Allocation Table) 。
+
对于不同的FAT格式，FAT表中每个条目 (entry) 的大小不同：
+
+对于FAT12而言，每个条目长12位
+对于FAT16而言，每个条目长16位
+对于FAT32而言，每个条目长32位
+
+这时候就发现了，原来FAT后面的数字就是指代的FAT表中每个条目的长度
+FAT条目中可能的存储值及其含义如下，其中MAX指代磁盘中合法的最大的簇号：
+
+
+
+FAT12
+FAT16
+FAT32
+含义
+
+
+
+
+0x000
+0x0000
+0x0000000
+当前条目所对应的簇空闲
+
+
+0x000 ~ MAX
+0x0002 ~ MAX
+0x0000002 ~ MAX
+当前条目所对应的簇存在内容，并且条目的值就是下一个簇的簇号
+
+
+(MAX + 1) ~ 0xFF6
+(MAX + 1) ~ 0xFFF6
+(MAX + 1) ~ 0xFFFFFF6
+保留的值，不能够使用
+
+
+0xFF7
+0xFFF7
+0xFFFFFF7
+当前条目所对应的簇是损坏的簇
+
+
+0xFF8 ~ 0xFFE
+0xFFF8 ~ 0xFFFE
+0xFFFFFF8 ~ 0xFFFFFFE
+保留的值，有时也作为指示当前条目所对应的簇是文件的最后一个簇
+
+
+0xFFF
+0xFFFF
+0xFFFFFFF
+当前条目所对应的簇是文件的最后一个簇
+
+
+
+陷阱：FAT32高四位保留
+
陷阱：FAT表首两个条目保留 簇号和实际的簇产生了2的偏移 ：对于任意簇号N N N N − 2 N-2 N − 2
+
FAT表中第一个保留的条目（FAT[0]）包含了BPB_Media域中的内容，其他的位被设置为1，对于FAT32高四位同样不进行更改。例如，如果BPB_Media的值为0xF8，那么
+
+对于FAT12，值为0xFF8
+对于FAT16，值为0xFFF8
+对于FAT32，值为0xFFFFFF8
+
+第二个保留的条目（FAT[1]）在格式化时会被格式化工具赋一个EOC值（具体用处不明）。对于FAT12而言，由于空间有限，所以并没有额外的标记位，对于FAT16和FAT32而言，Windows系统可能会使用高两位作为脏卷的标记位，其中最高位为ClnShutBit，如果该位置位，则意味着上一次该设备没有被正常卸载，可能需要检查文件系统的完整性；次高位为HrdErrBit，如果该位置位，则标明读写功能正常，如果置0则代表遇到了IO错误，提示一些磁盘扇区可能发生了错误。
+由于FAT表相当于一个数组，因此其不需要特殊的抽象。
+不过由于FAT12的特殊性，12位长度的数据并不能跟字节对齐，也就是说在FAT12中，一个条目从某个字节的中间开始，所以在根据下标从FAT从取值时可能会稍微复杂一些，在文档中也给出了具体的读取的代码。
+由于具体文件的读取在KernelLoader中进行，因此这部分的内容可以留待下一个章节再详细研究。
+目录结构
+到目前为止，BPB以及FAT表我们都已经清楚了，这样不论是FAT12、FAT16还是FAT32，我们都可以顺利地找到根目录所在的区域并且读取根目录所包含的所有数据了：
+
+对于FAT12/16，根据保留区的大小以及FAT的大小可以计算出根目录区的首扇区位置，根据根目录区首扇区位置和根目录区大小就可以读取全部根目录区数据
+对于FAT32，根据根目录区所在的簇号以及FAT表可以读取全部根目录区数据
+
+那么，接下来就要解决如何解析根目录内的文件了。更广泛地讲，由于根目录就像其他所有的文件目录一样，所以接下来就要解决如何读取一个目录，并且得到目录中各个文件的信息。
+实际上，目录同样是一个由目录条目构成的数组，其中每一个目录条目都是一个32字节长度的数据结构，而正是这个数据结构中存储的数据描述了一个目录中存储的文件或是一个子目录的详细信息，例如它的创建日期和时间、名称或是最重要的首簇簇号等等。它的完整结构如下：
+
+
+
+域名称
+偏移
+大小
+描述
+
+
+
+
+DIR_Name
+0
+11
+短名称格式的文件名
+
+
+DIR_Attr
+11
+1
+文件的属性标记
+
+
+DIR_NTRes
+12
+1
+保留位，必须为0
+
+
+DIR_CrtTimeTenth
+13
+1
+文件创建时间，单位为10ms
+
+
+DIR_CrtTime
+14
+2
+文件创建时间
+
+
+DIR_CrtDate
+16
+2
+文件创建日期
+
+
+DIR_LstAccDate
+18
+2
+文件最近访问日期
+
+
+DIR_FstClusHI
+20
+2
+首簇簇号高16位
+
+
+DIR_WrtTime
+22
+2
+文件修改时间
+
+
+DIR_WrtDate
+24
+2
+文件修改日期
+
+
+DIR_FstClusLO
+26
+2
+首簇簇号低16位
+
+
+DIR_FileSize
+28
+4
+文件的大小，单位为字节
+
+
+
+其中提到了一些概念，如短名称、文件属性以及一些仍然不明确的结构，如日期和时间的表示格式，如果继续阅读，则会发现文档也一一对它们作出了解释。
+短名称 为一种表示文件名称的格式，其11字节长度的域被分为8字节和3字节的空间，其中11字节用来存储文件不含扩展名的部分，而后3字节用来存储文件的扩展名，在存储名字的时候，所有的字母都会以大写字母的形式存储。
+同时，短名称的存储方式会在文件名长度小于最大长度时在其后面填补空格，例如FOO.BAR在存储时由于文件名为三字节，所以会在其后填补5个空格，存储为FOO BAR
+除此之外，短名称还遵循以下规则：
+
+若首字节为0xE5则代表当前条目为空
+若首字节为0x00则同样代表当前条目为空，并且还代表当前条目之后的所有条目都为空
+首字节不能为空格，也就是说文件名不能以空格开头
+目录中不能出现名称相同的两个条目
+不能出现小写字母
+ASCII值小于0x20的字符以及0x22、0x2A、0x2B、0x2C、0x2E、0x2F、0x3A、0x3B、0x3C、0x3D、0x3E、0x3F、0x5B、0x5C、0x5D、0x7C
+
+然而，如果文件名称很长的话，短名称就显得不太够用了，所以FAT还额外提出了长名称的解决方案，并且称存储短名称的条目为 SFNEntry ，长名称的目录为 LFNEntry 。
+在长名称的解决方案中，一个文件会对应一个短名称的条目和一系列长名称的条目，短名称条目存储文件名称的前数个字符和扩展名，而长名称则存储文件的全部名称。
+在目录中，一个文件对应的长名称条目和短名称条目连续存储，其中地址从低到高依次存储：
+
+第N个长名称条目
+第N-1个长名称条目
+…
+第1个长名称条目
+短名称条目
+
+其中，长名称条目的结构如下：
+
+
+
+域名称
+偏移
+大小
+描述
+
+
+
+
+LDIR_Ord
+0
+1
+当前条目在当前文件所有长名称条目中的顺序，从1开始计数0x40
+
+
+LDIR_Name1
+1
+10
+存储当前条目中文件名的第1~5个字符
+
+
+LDIR_Attr
+11
+1
+文件的属性标记，与短文件名条目的属性标记域保持相同含义ATTR_READ_ONLY | ATTR_HIDDEN | ATTR_SYSTEM | ATTR_VOLUME_ID
+
+
+LDIR_Type
+12
+1
+必须为0
+
+
+LDIR_Chksum
+13
+1
+校验位，用于校验当前条目是否与文件对应的短文件名条目相匹配
+
+
+LDIR_Name2
+14
+12
+存储当前条目中文件名的第6~11个字符
+
+
+LDIR_FstClusLO
+26
+2
+必须为0
+
+
+LDIR_Name3
+28
+4
+存储当前条目中文件名的第12~13个字符
+
+
+
+陷阱：LDIR_Ord从1开始
+
陷阱：长文件名使用Unicode存储 一个字符占据两个字节 。
+
对于校验码 ，文档也提供了算法，对应到实验中的实现为：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 uint32 DirEntry::checkSum () { if (isSFNEntry ()) { byte* pName = &_data[0 ]; uint16 nameLen; uint8 sum; sum = 0 ; for (nameLen = 11 ; nameLen != 0 ; nameLen--) { sum = ((sum & 1 ) ? 0x80 : 0 ) + (sum >> 1 ) + *pName++; } return sum; } else { return _data[13 ]; } }
文件的属性 使用按位枚举的方式表示，其中的六个二进制位分别如下：
+
+
+
+属性
+位
+描述
+
+
+
+
+ATTR_READ_ONLY
+1 << 0
+文件只读
+
+
+ATTR_HIDDEN
+1 << 1
+文件隐藏
+
+
+ATTR_SYSTEM
+1 << 2
+文件为系统文件
+
+
+ATTR_VOLUME_ID
+1 << 3
+文件用来描述卷标
+
+
+ATTR_DIRECTORY
+1 << 4
+文件实际上是一个目录
+
+
+ATTR_ARCHIVE
+1 << 5
+当文件被创建、重命名或修改时置位，指示文件是否被修改过
+
+
+
+陷阱：卷标文件只能出现在根目录 0x8，也即ATTR_VOLUME_ID，其他部分均为0。
+
文件的日期和时间 有特殊的存储格式
+其中文件的日期包括三个部分：
+
+[4:0]：日（从1至31）[8:5]：月（从1至12）[9]：从1980年起的年份偏移（从0至127）
+文件的时间同样也包括三个部分：
+
+[4:0]：从零起经过的2s间隔数（从0至29）[10:5]：分（从0至59）[15:11]：时（从0至23）
+可以看到，秒的精度为2s，这也就引出了CrtTimeTenth这个域，其精度为10ms，范围从0至199，正好填补了2s之间的空缺，使得精度提高到10ms
+在了解了目录的结构之后，就可以着手对目录进行抽象了。由于目录本身还是相当于关于目录条目的数组，所以根本在于对目录条目进行抽象。
+因为目录条目分为SFN（短文件名）和LFN（长文件名）两种类型，但其总长度一样，所以可以参考对BPB进行抽象的过程：将两种条目合并在一起，均视为DirEntry类，在调用具体函数的时候再根据条目类型的不同执行不同的判断。
+其中，由于文件属性的域涉及到位枚举，而C++没有原生支持位枚举，所以需要我们手动先在头文件中实现位枚举：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 class DirectoryFlag { public : enum ATTRIBUTES { READ_ONLY = 1 , HIDDEN = 1 << 1 , SYSTEM = 1 << 2 , VOLUME_ID = 1 << 3 , DIRECTORY = 1 << 4 , ARCHIVE = 1 << 5 }; private : uint8 _attr; public : DirectoryFlag (); DirectoryFlag (uint8 flags); public : DirectoryFlag& operator =(uint8 flags); DirectoryFlag& operator =(const DirectoryFlag& other); bool operator ==(uint8 flags); DirectoryFlag operator +(uint8 flags); DirectoryFlag& operator +=(uint8 flags); DirectoryFlag operator -(uint8 flags); DirectoryFlag& operator -=(uint8 flags); DirectoryFlag operator |(uint8 flags); DirectoryFlag& operator |=(uint8 flags); DirectoryFlag operator &(uint8 flags); DirectoryFlag& operator &=(uint8 flags); DirectoryFlag operator ~(); DirectoryFlag& operator ^=(uint8 flags); bool contains (uint8 flags) };
并在.cpp文件中给出重载操作符的实现
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 DirectoryFlag::DirectoryFlag () { _attr = 0 ; } DirectoryFlag::DirectoryFlag (uint8 flags) { _attr = flags; } DirectoryFlag& DirectoryFlag::operator =(uint8 flags) { _attr = flags; return *this ; } DirectoryFlag& DirectoryFlag::operator =(const DirectoryFlag& other) { _attr = other._attr; return *this ; } bool DirectoryFlag::operator ==(uint8 flags) { return _attr == flags; } DirectoryFlag DirectoryFlag::operator +(uint8 flags) { uint8 newAttr = _attr | flags; return DirectoryFlag (newAttr); } DirectoryFlag& DirectoryFlag::operator +=(uint8 flags) { _attr |= flags; return *this ; } DirectoryFlag DirectoryFlag::operator -(uint8 flags) { uint8 newAttr = _attr & ~(flags); return DirectoryFlag (newAttr); } DirectoryFlag& DirectoryFlag::operator -=(uint8 flags) { _attr &= ~(flags); return *this ; } DirectoryFlag DirectoryFlag::operator |(uint8 flags) { uint8 newAttr = _attr | flags; return DirectoryFlag (newAttr); } DirectoryFlag& DirectoryFlag::operator |=(uint8 flags) { _attr |= flags; return *this ; } DirectoryFlag DirectoryFlag::operator &(uint8 flags) { uint8 newAttr = _attr & flags; return DirectoryFlag (newAttr); } DirectoryFlag& DirectoryFlag::operator &=(uint8 flags) { _attr &= flags; return *this ; } DirectoryFlag DirectoryFlag::operator ~() { return DirectoryFlag (_attr); } DirectoryFlag& DirectoryFlag::operator ^=(uint8 flags) { _attr ^= flags; return *this ; } bool DirectoryFlag::contains (uint8 flags) return (_attr & flags) == flags; }
之后就可以根据上述表格完成DirEntry类的定义和实现了。需要注意的是，由于要从跟日期和时间有关的域中解析出对应的年月日或是时分秒仍然需要一步操作，所以我将条目中用到的时间和日期又额外包装成FATDate和FATTime放在fatdt.h中，并在这两个类中提供解析出年月日和时分秒的接口，在DirEntry的接口中不在返回裸的数值，而是将其转换为这两个类的实例进行返回。
+我所实现的fatdt.h文件内容如下：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 #include "types.h" #ifndef _FAT_DT_H_ #define _FAT_DT_H_ class FATDate { private : uint16 _date; public : FATDate (uint16 date); public : uint16 year () ; void setYear (uint16 year) uint16 month () ; void setMonth (uint16 month) uint16 day () ; void setDay (uint16 day) }; class FATTime { private : uint8 _timeTenth; uint16 _time; public : FATTime (uint8 timeTenth, uint16 time); public : uint16 hour () ; void setHour (uint16 hour) uint16 minute () ; void setMinute (uint16 minute) uint16 second () ; void setSecond (uint16 second) uint16 millisecond () ; void setMillisecond (uint16 millisecond) }; #endif
综上，可以完成fatdir.h文件如下：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 #include "types.h" #include "fatdt.h" #ifndef _FAT_DIR_H_ #define _FAT_DIR_H_ #define LAST_LONG_ENTRY 0x40 class DirectoryFlag ;class DirEntry ;class DirectoryFlag { public : enum ATTRIBUTES { READ_ONLY = 1 , HIDDEN = 1 << 1 , SYSTEM = 1 << 2 , VOLUME_ID = 1 << 3 , DIRECTORY = 1 << 4 , ARCHIVE = 1 << 5 }; private : uint8 _attr; public : DirectoryFlag (); DirectoryFlag (uint8 flags); public : DirectoryFlag& operator =(uint8 flags); DirectoryFlag& operator =(const DirectoryFlag& other); bool operator ==(uint8 flags); DirectoryFlag operator +(uint8 flags); DirectoryFlag& operator +=(uint8 flags); DirectoryFlag operator -(uint8 flags); DirectoryFlag& operator -=(uint8 flags); DirectoryFlag operator |(uint8 flags); DirectoryFlag& operator |=(uint8 flags); DirectoryFlag operator &(uint8 flags); DirectoryFlag& operator &=(uint8 flags); DirectoryFlag operator ~(); DirectoryFlag& operator ^=(uint8 flags); bool contains (uint8 flags) }; class DirEntry { private : byte _data[32 ]; public : bool isEmpty () bool isSFNEntry () bool isLFNEntry () bool isLastInSet () DirectoryFlag attributes () ; FATTime createTime () ; FATDate createDate () ; FATDate lastAccessedDate () ; FATTime lastModifiedTime () ; FATDate lastModifiedDate () ; uint32 firstCluster () ; uint32 fileSize () ; uint32 lfnIndex () ; void parseASCIIFileName (byte* dst) uint32 checkSum () ; }; #endif
完整的fatdir.cpp则实现如下：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 #include "fatdir.h" DirectoryFlag::DirectoryFlag () { _attr = 0 ; } DirectoryFlag::DirectoryFlag (uint8 flags) { _attr = flags; } DirectoryFlag& DirectoryFlag::operator =(uint8 flags) { _attr = flags; return *this ; } DirectoryFlag& DirectoryFlag::operator =(const DirectoryFlag& other) { _attr = other._attr; return *this ; } bool DirectoryFlag::operator ==(uint8 flags) { return _attr == flags; } DirectoryFlag DirectoryFlag::operator +(uint8 flags) { uint8 newAttr = _attr | flags; return DirectoryFlag (newAttr); } DirectoryFlag& DirectoryFlag::operator +=(uint8 flags) { _attr |= flags; return *this ; } DirectoryFlag DirectoryFlag::operator -(uint8 flags) { uint8 newAttr = _attr & ~(flags); return DirectoryFlag (newAttr); } DirectoryFlag& DirectoryFlag::operator -=(uint8 flags) { _attr &= ~(flags); return *this ; } DirectoryFlag DirectoryFlag::operator |(uint8 flags) { uint8 newAttr = _attr | flags; return DirectoryFlag (newAttr); } DirectoryFlag& DirectoryFlag::operator |=(uint8 flags) { _attr |= flags; return *this ; } DirectoryFlag DirectoryFlag::operator &(uint8 flags) { uint8 newAttr = _attr & flags; return DirectoryFlag (newAttr); } DirectoryFlag& DirectoryFlag::operator &=(uint8 flags) { _attr &= flags; return *this ; } DirectoryFlag DirectoryFlag::operator ~() { return DirectoryFlag (_attr); } DirectoryFlag& DirectoryFlag::operator ^=(uint8 flags) { _attr ^= flags; return *this ; } bool DirectoryFlag::contains (uint8 flags) return (_attr & flags) == flags; } bool DirEntry::isEmpty () return _data[0 ] == 0xE5 || _data[0 ] == 0x00 ; } bool DirEntry::isSFNEntry () return !attributes ().contains ( DirectoryFlag::READ_ONLY | DirectoryFlag::HIDDEN | DirectoryFlag::SYSTEM | DirectoryFlag::VOLUME_ID ); } bool DirEntry::isLFNEntry () return attributes ().contains ( DirectoryFlag::READ_ONLY | DirectoryFlag::HIDDEN | DirectoryFlag::SYSTEM | DirectoryFlag::VOLUME_ID ); } bool DirEntry::isLastInSet () return (_data[0 ] & LAST_LONG_ENTRY) != 0 ; } DirectoryFlag DirEntry::attributes () { return DirectoryFlag (_data[11 ]); } FATTime DirEntry::createTime () { return FATTime (_data[13 ], *(uint16*)(&_data[14 ])); } FATDate DirEntry::createDate () { return FATDate (*(uint16*)(&_data[16 ])); } FATDate DirEntry::lastAccessedDate () { return FATDate (*(uint16*)(&_data[18 ])); } FATTime DirEntry::lastModifiedTime () { return FATTime (0 , *(uint16*)(&_data[22 ])); } FATDate DirEntry::lastModifiedDate () { return FATDate (*(uint16*)(&_data[24 ])); } uint32 DirEntry::firstCluster () { uint16 frstClusterHI = *(uint16*)(&_data[20 ]); uint16 frstClusterLO = *(uint16*)(&_data[26 ]); uint32 frstCluster = ((uint32)frstClusterHI << 16 ) | frstClusterLO; return frstCluster; } uint32 DirEntry::fileSize () { return *(uint32*)(&_data[28 ]); } uint32 DirEntry::lfnIndex () { return _data[0 ] & 0x3F ; } void DirEntry::parseASCIIFileName (byte* dst) if (isLFNEntry ()) { for (int i = 0 ; i < 5 ; i++) { dst[i] = _data[1 + 2 * i]; } for (int i = 0 ; i < 6 ; i++) { dst[5 + i] = _data[14 + 2 * i]; } for (int i = 0 ; i < 2 ; i++) { dst[11 + i] = _data[28 + 2 * i]; } } else { for (int i = 0 ; i < 11 ; i++) { dst[i] = _data[i]; } } } uint32 DirEntry::checkSum () { if (isSFNEntry ()) { byte* pName = &_data[0 ]; uint16 nameLen; uint8 sum; sum = 0 ; for (nameLen = 11 ; nameLen != 0 ; nameLen--) { sum = ((sum & 1 ) ? 0x80 : 0 ) + (sum >> 1 ) + *pName++; } return sum; } else { return _data[13 ]; } }
抽象MBR结构
+上一小节中，我们实现了FAT文件系统的抽象，为从文件系统中读取内核文件奠定了基础。对于一个仅有一个分区的硬盘而言，如果其文件系统恰是FAT格式，那么就可以使用我们抽象出的接口访问其中的文件。
+但现如今磁盘中只有一个分区的电脑少之又少，如果磁盘中有多个FAT格式的分区，那么加载程序应该去哪个分区寻找内核文件，又该如何定位到对应分区的位置呢？
+这些就要依赖于存储在MBR中的数据了。在第二章：计算机是如何启动的 一节中提到，MBR在447~510这64个字节中存储了分区表信息，包括了分区的引导标志、起始磁道、起始扇区、起始柱面等信息。
+注：实验中使用的是MBR分区表
+
通过这些特殊的信息，加载程序就可以判断哪个分区是活动的，以及这个分区在磁盘上的位置，以及分区上文件系统的类型。在确定了这些信息之后，加载程序就可以使用上一节中关于文件系统的接口来读取和加载内核文件了。
+在经历了对文件系统的抽象之后，此时大家应该很快就能想到，为了能够方便地解析MBR中分区表的数据，可以对MBR的结构进行抽象。
+MBR结构
+参考资料：MBR结构 Wikipedia中关于MBR的页面 ，其中，实验采用了Classical generic MBR的格式对MBR结构进行解析。
+
在最一般的MBR结构中，其包含了三个主要的部分：
+
+计算器启动代码 (Bootstrap code) ：这部分空间用来存储计算机启动后要执行的第一段操作系统代码，也就是我们在第二章中实现的用来启动BootLoader的代码分区表 (Partition table) ：这部分空间由四个分区目录条目 (Partition entry) 组成，用来描述磁盘中的分区信息启动签名 (Boot signature) ：一般为0xAA55，用来向BIOS表示磁盘是可启动的
+它们的地址和大小如下：
+
+
+
+内容
+起始地址
+大小
+
+
+
+
+启动代码 0x0000
+446B
+
+
+分区条目1 Partition entry №1 0x01BE
+16B
+
+
+分区条目2 Partition entry №2 0x01CE
+16B
+
+
+分区条目3 Partition entry №3 0x01DE
+16B
+
+
+分区条目4 Partition entry №4 0x01EE
+16B
+
+
+启动签名 0x01FE
+2B
+
+
+
+Partition Entry结构
+同时，每个分区条目 (Partition entry) 又具有如下的结构：
+
+
+
+偏移
+大小
+描述
+
+
+
+
+0x00
+1
+描述分区的状态 0x80用来表示活动分区0x00表示非活动分区
+
+
+0x01
+3
+分区首扇区的CHS表示
+
+
+0x04
+1
+分区的类型
+
+
+0x05
+3
+分区末扇区的CHS表示
+
+
+0x08
+4
+分区首扇区的LBA扇区号
+
+
+0x0C
+4
+分区总扇区数
+
+
+
+其中，根据 Wikipedia上关于分区类型的页面 中的描述，实验中将会用到的分区类型以及它们的值为：
+
+
+
+类型
+值
+
+
+
+
+FAT12 0x01
+
+
+FAT16 0x04
+
+
+FAT32(CHS) 0x0B
+
+
+FAT32(LBA) 0x0C
+
+
+
+同时，扇区号的CHS表示又具有如下的结构：
+
+
+
+偏移
+大小
+描述
+
+
+
+
+0x00
+1
+磁头号 (head)
+
+0x01
+1
+由两部分组成：高2位为柱面 (cylinder) 第8-9位 低6位为扇区号 (sector) 第0-5位
+
+
+0x02
+1
+柱面 (cylinder) 第0-7位
+
+
+可见，对于一个分区条目而言，其主要的作用就是判断分区是否存在 、判断分区的状态（是否是活动分区） 、标记分区的文件系统类型 以及获取分区的首扇区号和扇区数 ，因此其接口就主要围绕这些方面进行设计：
+1 2 3 4 5 public : bool isPresent () bool isActive () uint32 firstSectorLBA () ; uint32 sectorNum () ;
抽象Partition Entry
+明确了分区条目的结构和需要提供的接口，可以迅速将分区条目抽象为Partition类型如下：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 class Partition { public : enum Status { INACTIVE = 0 , ACTIVE = 1 << 7 }; enum Type { EMPTY = 0 , FAT12 = 0x01 , FAT16 = 0x04 , FAT32_CHS = 0x0B , FAT32_LBA = 0x0C , }; public : uint8 _status; CHSAddress _frstSecCHS; uint8 _type; CHSAddress _lastSecCHS; byte _frstSecLBA[4 ]; byte _numSec[4 ]; public : bool isPresent () bool isActive () uint32 firstSectorLBA () ; uint32 sectorNum () ; };
上述接口则均实现在partition.cpp文件中：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 #include "partition.h" bool Partition::isPresent () return sectorNum () != 0 ; } bool Partition::isActive () return _status == ACTIVE; } uint32 Partition::firstSectorLBA () { return *(uint32*)_frstSecLBA; } uint32 Partition::sectorNum () { return *(uint32*)_numSec; }
同时，在分区条目的结构中涉及到的CHS扇区号由上文中提到的CHS结构抽象为CHSAddress类型，其只需要提供从3字节长度的数据中提取柱面、磁头和扇区号 的接口：
+1 2 3 4 5 6 7 8 class CHSAddress { public : byte address[3 ]; public : uint32 cylinder () ; uint32 head () ; uint32 sector () ; };
注：
+
抽象MBR
+实现了对分区条目的抽象之后，对MBR结构的抽象就易如反掌了，因为其实际上就是由一段长度为446的字节数组 (Bootstrap code) 、四个分区条目类型的对象 (Partition table) 以及一个两字节的数组 (Boot signature) 组成的：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 #include "types.h" #include "partition.h" #ifndef _MBR_H_ #define _MBR_H_ class MBR { public : byte bootstrap[446 ]; Partition partition_1; Partition partition_2; Partition partition_3; Partition partition_4; byte signature[2 ]; }; #endif
由于Partition类型的对象已经提供了足够使用的接口，因此MBR并不需要再设计额外的接口，而只需要将四个Partition的变量暴露给程序即可。如果程序想要从MBR中获得一个分区是否是活动的，以及其起始的LBA扇区号，其可以进行如下的操作：
+1 2 3 4 5 6 7 8 9 10 11 12 Partition p = mbr.partition_1; if (p.isActive ()){ } lba = p.firstSectorLBA ();
抽象页表
+实现了MBR和文件系统的抽象就意味着现在我们已经可以从硬盘中找到需要的内核文件了，并且借助硬盘读取的接口将内核的文件从硬盘中读取到内存。下一步就是将内核加载到正确的地址空间中，完成加载内核的全部步骤。但是在开始加载内核之前，需要先了解虚拟内存的概念以及分页机制的原理，并且实现对分页要用到的数据结构进行抽象后才能正确地对内核进行加载。
+简述虚拟内存与分页机制
+参考资料
+
既然要介绍虚拟内存和分页机制，自然就要从它们出现的原因谈起，而这就绕不开 “程序是如何运行起来的” 这个话题。
+在学完了『操作系统原理』这门课后，想必已经对程序的运行有了一个大致的认识，知道了程序运行的基础是CPU对机器指令的执行，而CPU执行机器指令由是由数个流水级逐步完成的，不考虑分支预测等等复杂的实现，CPU对指令的执行可以抽象为以下的步骤：
+
+存储指令地址的存储器（可以视作PC）提供了一个地址信号输入存储指令的存储器（在这里就是内存了）
+内存根据输入的地址信号在下一个时钟沿输出对应地址空间上存储的指令
+其他流水级完成指令的解析等，同时指令地址完成一次自增
+
+可见，想让程序运行起来，关键就是两步：
+
+把指令存到内存中
+把指令的地址放置到存储指令地址的存储器（PC）中
+
+这样，在下一个时钟周期到来的时候，CPU就会从想要执行的指令处开始执行了。
+把指令的地址放置到PC中就十分简单了，在汇编中常见的跳转指令都可以完成这一操作，在硬件上的实现想必大家也是历历在目的（小声），那剩下还要解决的就是把指令存到内存中这个问题啦。
+但偏偏就是把指令存到内存中这么一个看起来很简单的操作，背后却暗藏了各种难题，为了这么一个操作，曾经的工程师们也可谓是八仙过海，各显神通。
+还记得我们在第二部分：从代码到可执行文件 一节中提到的程序的链接步骤中提到，在链接时需要指定程序起始的地址，这个地址关系到了整个程序所有代码段中使用到的绝对地址的计算，这就为程序的加载带来了一个大难题：
+如果我不知道程序要加载到哪里，那我应当如何指定程序起始的地址？ 如果强行提前指定了程序的起始地址，那个地址被其他的程序占用了又该怎么办？
+
于是，曾经伟大的工程师们就提出了一个概念：让程序视角下的地址和它真正运行着的地址分开 。通俗点解释，就是令程序在执行的时候中，其指令中的各种地址都视为程序视角下的地址，通过一些手段，让这个地址和真正访问内存的地址不是同一个地址，但又存在着一定的映射关系：
+A c c e s s A d d r e s s = f ( P r o g r a m A d d r e s s ) AccessAddress = f(ProgramAddress)
+ A ccess A dd ress = f ( P ro g r am A dd ress )
+结合才学没多久的计算机组成原理课程的知识，可以大致理解为，在从指令中分离出地址后并不是直接送入内存，而是经过一个特殊的地址变换部件 (这也就是常说的MMU) 之后才会送入内存 。
+
+什么是程序视角下的地址：
+
就像上图，当程序在运行的时候，CPU会根据指令生成出一些地址的值，例如mov eax, dword [ebx]会从内存中加载4字节数据，其产生的地址是ebx中存储的值；或是jmp 0x7E00会跳转到0x7E00处执行，CPU会产生0x7E00这个地址送入指令地址寄存器。
+
然而，CPU所不断地产生出的地址的值，还需要经过地址变换部件才能成为有意义的地址。对于CPU而言，它并不知道MMU的存在，它只知道指令生成了一些地址，而且在运行的过程中这些地址确实产生了正确的效果，看起来就像是程序真的就放在这个地址上运行一样 ，而不知道这些地址实际上是由于MMU的地址变换作用才产生了正确的效果，所以这实际上这些未经变换都可以被称作是CPU“假想”的地址，也就是常说的虚拟地址 ，我个人喜欢将它们称为是程序视角下的地址 ，我认为这样说会更形象、更易于理解。
+
由于程序的视角其实通俗理解就是CPU的视角，所以在程序执行过程中由CPU生成的地址，其实就是程序视角下的地址 。
+
这些地址是虚拟的，是假定的 ，因为它们并不能代表程序在内存中存放的地址，这一点很重要 。
+
陷阱：程序某个部分在内存中的地址≠程序视角中这个部分的地址 程序视角的地址是“假想”的地址，是程序所认为的它在内存中的位置 的概念。程序在运行的时候由CPU生成的所有地址都不再一定是CPU想要从内存中获取的数据的地址 ，而是要经由一次MMU的映射才能获得程序想从内存中获取的数据的地址。
+
这样，即便程序都以0x0为起始地址，也可以通过不同的地址变换方式来达到将程序存储在内存中不同位置的效果。
+
+但是摆在工程师面前的，还有更多的问题：
+如何从空闲的空间中选择合适的位置存储需要加载的程序？
+
在操作系统运行的过程中，会不断有程序需要被加载到内存运行，同时也会不断地有程序结束运行。结束运行的程序可以释放出它本身占用的空间，需要加载运行的程序则需要申请能够存放其自身的空间。如此往复的过程中，不断被申请然后被释放的程序所占用的内存空间会让内存的地址空间中出现一个个的空洞 (Hole) ，原先连续的大片空闲区域就这样被分割成了不连续的许多小的空闲的内存片段：
+
+这听起来就不是什么好事，事实上也确实是如此，当操作系统要加载一个新的程序进入内存的时候，它几乎一定面对的是一个“满目疮痍”的内存空间，而如何从无数的空洞中选择合适的那个来存放程序，也就成了一个难题。过去的工程师提出了三种解决方案：
+
+最优适应 ：一种强迫症式的挑选方法，非得找到所有足够装下程序的空洞中最小的那个 ，在欧皇时刻这样挑恰好就能放进去，但是非酋时刻则会产生一个非常小的空洞，导致最后谁都放不进去，白白浪费。最差适应 ：一种走极端的挑选方法，你说最优适应会产生小空洞让谁都放不进去，那行，我就找到所有足够装下程序的空洞中最大的那个 ，在这种情况下，一般剩下来的空洞还是能够再利用的。首次适应 ：一种摆烂式的挑选方法，只要找到了能装下的空洞，啥也不管了，冲就对了，奥里给 ！但你说妙不妙，这样的策略竟然反倒在空间和时间方面都胜最差适应一筹，和最优适应难分伯仲，甚至还更快些 ！再次证明了开摆就对了！
+
+碎片：
+
在上面的描述的三种为程序的分配内存的方式中可以看出并不是每一次都能够为程序分配恰到好处的空间，往往一个新程序的加载会导致内存中出现小的空洞，这些空洞小到几乎不足以放下任何其他的程序，这就意味着这部分内存直到程序运行完毕被释放之前都不能够被操作系统用来为其他程序分配，这些实际上被浪费掉的内存空间就是碎片 。
+
碎片又分为外部碎片和内部碎片 ，前述的这种在为程序分配的空间以外的浪费空间叫做外部碎片 ，而如果操作系统为一个程序分配了多余它实际要使用的内存空间，那么其内部被浪费掉的空间就叫做内部碎片 ，这种类型的碎片将会在后面介绍分页机制时看到。
+
碎片对于内存空间的利用而言是致命的，试想一个充满了碎片的内存，明明其空闲的空间足够大，但是由于全部都是由碎片组成，而不能放入任何一个程序。
+
然而，上面的三种分配方式都仍然是将一个程序视为一个整体进行加载的，多少有点偏执了。
+假设内存中有 4 4 4 16 K i B 16KiB 16 K i B 60 K i B 60KiB 60 K i B 16 K i B 16KiB 16 K i B 16 K i B 16KiB 16 K i B 16 K i B 16KiB 16 K i B 12 K i B 12KiB 12 K i B
+
+聪明的工程师自然也想到了，所以分页 的概念也就应运而生。
+为了方便操作系统进行管理，工程师将内存和程序都按照一个相同的大小进行分割，例如常见的 4 K i B 4KiB 4 K i B
+对于内存而言，剩余不足一页的空间会被舍弃；对于程序而言，不足一页的部分也会分配一个完整的页，这时页中没有被使用的部分就是内部碎片，例如如果程序的大小为 4 K i B + 1 B 4KiB + 1B 4 K i B + 1 B 4 K i B 4KiB 4 K i B 4095 B 4095B 4095 B
+陷阱：对程序分页实质上是对程序地址空间进行分页
+
物理页和虚拟页：
+
在内存进行了分页之后，往后内存空间的分配和释放都会以一页为最小单位，因此当需要加载新的程序进入内存时，如果内存中空闲的页不少于程序运行所需要的页，则为程序分配其所需要的数量的页，并且建立一个从程序视角下的页到实际内存中的页的映射关系
+
+有了这样的映射关系，操作系统就可以对应着将程序的内容装载进内存，至于在程序视角下的地址空间内那些空间需要写入内存、怎样写入内存等等将会留到下一小节 介绍。
+但是这样复杂的映射关系，CPU是如何记住的呢？
+这就要提到本章节的主角页表 了。为了能够让MMU知道程序视角下的页与内存中页的映射关系，早期的工程师创造了一个类似FAT表的表结构，其中每个程序视角下的页都可以对应到一个表项，而每个表项中的内容都对应到一个内存中的页，这个对应关系使用内存页的首字节地址表示。
+
+不过CPU产生的地址肯定不会是页的大小的整数倍，而是可能对应着一个页内的任何一个字节，此时如果只有页的映射关系是否有些不够了呢？
+自然不是的。由于页在映射的时候是将一个页视为一个整体进行映射，所以同一个内容在虚拟页和物理页中的偏移量是相同的，在对CPU生成的地址进行变换的时候，只需要将页的地址和偏移量分离开来，通过页表得到物理页的地址以后，再将其作为基址叠加上原先分离出的偏移量，就可以得到映射后的地址了。
+P a g e O f f s e t = V i r t u a l A d d r e s s % P a g e S i z e V i r t u a l P a g e A d d r e s s = V i r t u a l A d d r e s s − P a g e O f f s e t P h y s i c a l P a g e A d d r e s s = f ( V i r t u a l P a g e A d d r e s s ) P h y s i c a l A d d r e s s = P h y s i c a l P a g e A d d r e s s + P a g e O f f s e t \begin{align}
+&PageOffset = VirtualAddress \ \% \ PageSize \nonumber \\
+&VirtualPageAddress = VirtualAddress - PageOffset \nonumber \\
+&PhysicalPageAddress = f(VirtualPageAddress) \nonumber \\
+&PhysicalAddress = PhysicalPageAddress + PageOffset \nonumber
+\end{align}
+ P a g e O ff se t = Vi r t u a l A dd ress % P a g e S i ze Vi r t u a lP a g e A dd ress = Vi r t u a l A dd ress − P a g e O ff se t P h ys i c a lP a g e A dd ress = f ( Vi r t u a lP a g e A dd ress ) P h ys i c a l A dd ress = P h ys i c a lP a g e A dd ress + P a g e O ff se t
+不过，只是得到虚拟页的首字节地址还不够，既然要在页表中寻找对应关系，就需要知道虚拟页对应的下标，也就是虚拟页在所有页中的序号。由于页的大小都是 2 n 2^n 2 n k k k
+V i r t u a l P a g e A d d r e s s k = k × 2 n = k < < n \begin{align}
+VirtualPageAddress_k &= k \times 2^n \nonumber \\
+&= k << n \nonumber \\
+\end{align}
+ Vi r t u a lP a g e A dd res s k = k × 2 n = k << n
+所以对于一个虚拟页，其在页表中的下标就可以通过虚拟页的地址移位得到。对于大小为 2 n 2^n 2 n
+V i r t u a l P a g e I n d e x = V i r t u a l P a g e A d d r e s s > > n VirtualPageIndex = VirtualPageAddress >> n
+ Vi r t u a lP a g e I n d e x = Vi r t u a lP a g e A dd ress >> n
+代入上式可得
+V i r t u a l P a g e I n d e x = V i r t u a l P a g e A d d r e s s > > n = ( V i r t u a l A d d r e s s − P a g e O f f s e t ) > > n = ( V i r t u a l A d d r e s s − V i r t u a l A d d r e s s % 2 n ) > > n = ( V i r t u a l A d d r e s s − ( V i r t u a l A d d r e s s − f l o o r ( V i r t u a l A d d r e s s ÷ 2 n ) × 2 n ) ) > > n = ( V i r t u a l A d d r e s s − ( V i r t u a l A d d r e s s − ( V i r t u a l A d d r e s s > > n ) < < n ) ) > > n = V i r t u a l A d d r e s s > > n < < n > > n = V i r t u a l A d d r e s s > > n \begin{align}
+VirtualPageIndex &= VirtualPageAddress >> n \nonumber \\
+&= (VirtualAddress - PageOffset) >> n \nonumber \\
+&= (VirtualAddress - VirtualAddress \ \% \ 2^n) >> n \nonumber \\
+&= (VirtualAddress - (VirtualAddress - floor(VirtualAddress \div 2^n) \times 2^n)) >> n \nonumber \\
+&= (VirtualAddress - (VirtualAddress - (VirtualAddress >> n) << n)) >> n \nonumber \\
+&= VirtualAddress >> n << n >> n \nonumber \\
+&= VirtualAddress >> n \nonumber
+\end{align}
+ Vi r t u a lP a g e I n d e x = Vi r t u a lP a g e A dd ress >> n = ( Vi r t u a l A dd ress − P a g e O ff se t ) >> n = ( Vi r t u a l A dd ress − Vi r t u a l A dd ress % 2 n ) >> n = ( Vi r t u a l A dd ress − ( Vi r t u a l A dd ress − f l oor ( Vi r t u a l A dd ress ÷ 2 n ) × 2 n )) >> n = ( Vi r t u a l A dd ress − ( Vi r t u a l A dd ress − ( Vi r t u a l A dd ress >> n ) << n )) >> n = Vi r t u a l A dd ress >> n << n >> n = Vi r t u a l A dd ress >> n
+以 4 K i B 4KiB 4 K i B 0xC00002a0，其高20位 0xC0000代表这个地址所在的页的序号 ，而低12位 0x2a0其实是代表着这个地址在页内部的偏移量 。也即在程序的虚拟地址中，0xC00002a0地址位于第0xC0000页中第0x2a0个字节处。访问页表中下标为0xC0000的项，得到虚拟页对应的物理地址，例如0x20000000，再将物理地址和偏移量合并，得到映射后的物理地址0x200002a0。
+
+不过，如果按照这样的方式映射，对于一个32位的系统来说，每一个虚拟页都需要4个字节来存储其对应的物理页的地址，而32位的地址最多可以取到 4 G i B 4GiB 4 G i B 4 K i B 4KiB 4 K i B S ( x ) S(x) S ( x ) x所占用的内存字节数
+S ( P a g e T a b l e E n t r y ) = 4 S ( V i r t u a l A d d r e s s S p a c e ) = 2 32 S ( P a g e ) = 2 12 ( 2 ) , ( 3 ) ⇒ P a g e C n t = S ( V i r t u a l A d d r e s s S p a c e ) ÷ S ( P a g e ) = 2 20 ( 4 ) ⇒ P a g e T a b l e E n t r y C n t = P a g e C n t = 2 20 ( 1 ) , ( 5 ) ⇒ S ( P a g e T a b l e ) = S ( P a g e T a b l e E n t r y ) × P a g e T a b l e E n t r y C n t = 2 22 \begin{align}
+&S(PageTableEntry) = 4 \\
+&S(VirtualAddressSpace) = 2^{32} \\
+&S(Page) = 2^{12} \\
+&(2), (3) \Rightarrow PageCnt = S(VirtualAddressSpace) \div S(Page) = 2^{20} \\
+&(4) \Rightarrow PageTableEntryCnt = PageCnt = 2^{20} \\
+&(1),(5) \Rightarrow S(PageTable) = S(PageTableEntry) \times PageTableEntryCnt = 2^{22} \nonumber
+\end{align}
+ S ( P a g e T ab l e E n t ry ) = 4 S ( Vi r t u a l A dd ress Sp a ce ) = 2 32 S ( P a g e ) = 2 12 ( 2 ) , ( 3 ) ⇒ P a g e C n t = S ( Vi r t u a l A dd ress Sp a ce ) ÷ S ( P a g e ) = 2 20 ( 4 ) ⇒ P a g e T ab l e E n t ry C n t = P a g e C n t = 2 20 ( 1 ) , ( 5 ) ⇒ S ( P a g e T ab l e ) = S ( P a g e T ab l e E n t ry ) × P a g e T ab l e E n t ry C n t = 2 22
+也就是说，光是一个页表结构就要占用 4 M i B 4MiB 4 M i B 16 G i B 16GiB 16 G i B 4 M i B 4MiB 4 M i B (Multi-level paging) 的概念，其中在32位的操作系统中使用最多的是二级分页 (Two level paging) ，而64位操作系统多使用四级分页或是更多级别的分页。尽管分页的级数会存在不同，但它们的原理都是相同的，而且都是为了解决一个问题：减少页表自身占用的存储空间。
+以二级分页为例，实际上就是将原先页表的结构同样按照页划分为块，对于上面提到的32位架构中的页表结构可以被划分为 2 10 2^{10} 2 10 一级页表 (Level 1 Page Table) 。每个原先的页表项此时就可以像虚拟地址那样，表示成为一级页表的序号和页表内的偏移，不过此时的偏移就不是以字节为单位的偏移，而是以页表项元素大小（4字节）为单位的偏移。
+对于一个原先页表项的序号 I n d e x Index I n d e x
+E n t r y P e r P a g e = P a g e S i z e ÷ P a g e T a b l e E n t r y S i z e = 2 12 ÷ 2 2 = 2 10 O f f s e t = I n d e x % E n t r y P e r P a g e = I n d e x % 2 10 P a g e I n d e x = f l o o r ( I n d e x ÷ E n t r y P e r P a g e ) = f l o o r ( I n d e x ÷ 2 10 ) = I n d e x > > 10 \begin{align}
+&{
+ \begin{align}
+ EntryPerPage &= PageSize \div PageTableEntrySize \nonumber \\
+ &= 2^{12} \div 2^2 \nonumber \\
+ &= 2^{10} \nonumber
+ \end{align}
+} \nonumber \\
+&{
+ \begin{align}
+ Offset &= Index \ \% \ EntryPerPage \nonumber \\
+ &= Index \ \% \ 2^{10} \nonumber
+ \end{align}
+} \nonumber \\
+&{
+ \begin{align}
+ PageIndex &= floor(Index \div EntryPerPage) \nonumber \\
+ &= floor(Index \div 2^{10}) \nonumber \\
+ &= Index >> 10 \nonumber
+ \end{align}
+}
+\end{align}
+ E n t ry P er P a g e = P a g e S i ze ÷ P a g e T ab l e E n t ry S i ze = 2 12 ÷ 2 2 = 2 10 O ff se t = I n d e x % E n t ry P er P a g e = I n d e x % 2 10 P a g e I n d e x = f l oor ( I n d e x ÷ E n t ry P er P a g e ) = f l oor ( I n d e x ÷ 2 10 ) = I n d e x >> 10
+通俗而言，就是原先页表项的下标的高10位为这个页表项所在的一级页表的序号，低10位则为这个页表项在其所在的一级页表中的下标。例如页表中原先位于0x80200（0b1000_0000_0010_0000_0000）的页表项，可以认为是在第0x200（0b10_0000_0000）个一级页表中的第0x200个页表项。
+在划分了一级页表之后，额外添加了一个页表，其中的每一项是32位的数值，指向这一项下标对应的一级页表所在的首字节的地址，这个页表就是二级页表 (Level 2 Page Table) 。由于在32位架构的设备上最多有 2 1 0 2^10 2 1 0
+2 10 × 4 = 2 12 B y t e = 4 K i B 2^{10} \times 4 = 2^{12} Byte = 4KiB
+ 2 10 × 4 = 2 12 B y t e = 4 K i B
+正好就是一个页的大小。
+这样，当要将一个虚拟地址转换为物理地址时，需要
+
+取低12位为页内偏移
+取中10位为一级页表内页表项的下标
+取高10位位二级页表内页表项的下标
+使用二级页表项的下标在二级页表中取得一级页表的地址
+使用一级页表项的下标和一级页表的地址取得虚拟地址对应的物理页的地址
+根据物理页的地址和页内偏移得到转换后的物理地址
+
+
+乍一看，好像二级页表的出现是多此一举，本来可以直接用下标在页表里定位到页表项，从页表项直接取得物理页地址，现在还要多此一举，先从二级页表拿到一级页表的地址，然后才能拿到物理页地址。仔细一算的话，对于所有的虚拟页都进行映射的情况，二级分页甚至还要比不采用二级分页多出一个二级页表的大小，这哪里节约了页表占用的空间！
+最初我也是同样对此感到十分地疑惑，一个不但增加了内存占用，复杂了流程还减慢了地址转换地速度的方案怎么就流传下来了呢？后来我意识到我忽略了一个很关键的细节：前文中讨论页表占用的内存是时始终是基于虚拟地址全部映射到物理地址这个前提进行的 ，然而事实上，大部分时候都不会需要将虚拟地址全部映射在内存中 ，甚至有时候内存根本就不够映射全部的虚拟地址！
+虚拟地址不完全映射到内存就意味着页表中有空的页表项，对于没有二级分页的方案，由于整个页表都相当于一个巨大的数组结构，即使一个元素为空也不能舍弃它的空间，所以不论映射了多少虚拟页，页表占用的大小始终是固定的 。然而对于二级分页的方案，由于二级页表记录的是一级页表的地址，这也就相当于拆散了原先巨大的页表 ，并且还使得拆分后得到的一级页表可以分散地存储在内存中。这样做还带来了一个巨大的好处，就是页表的内存不再需要一次性分配完毕 ，因为原先没有多级分页机制的时候，但凡需要页表，就需要一次性申请全部页表的空间，而现在即便一级和二级页表还是相当于数组结构，还是需要为每一个页表分配固定大小的内存，但是它们单个的体积从原先的 4 M i B 4MiB 4 M i B 4 K i B 4KiB 4 K i B 如果一整个一级页表内的表项全部为空，那么就可以不分配这个一级页表的空间 ，从而达到节省空间的目的。
+
+有了二级页表之后，现在摆在我们面前的只剩最后一个问题：
+
+早期的RAM相当金贵，远不及如今动辄16GiB、32GiB，能有个几兆几十兆都是奢侈。那如果一个程序就十分不巧，大小竟然比内存还大，那这个庞然大物该如何运行起来呢？
+这就要提到一个叫做 程序运行的局部性原理 的概念，它是指程序在一段时间内程序的执行只限于程序的一部分，就以我们熟悉的冒泡排序算法为例吧：
+1 2 3 4 5 6 7 8 9 for (int i = 0 ; i < n; i++) { for (int j = 0 ; j < n - i - 1 ; j++) { if (arr[j] < arr[j + 1 ]) { int temp = arr[j]; arr[j] = arr[j + 1 ]; arr[j + 1 ] = temp; } } }
即便程序的其余部分无比复杂，哪怕是3A巨制，但只要程序运行到这里，它在相当一段时间里只会在两个for循环里打转转，它访问的内存也只会局限在arr这个数组里，这就是程序的局部性，在这一段时间里程序所用到的空间就是程序所需要的工作集 。
+由于程序运行具有局部性的原理，所以不论程序占用的虚拟地址空间有多大，它在一个特定的时间长度内都不会访问全部的地址空间，这时只需要将其运行需要的部分加载到内存中，程序就可以正常地运行了。这就好比我们在玩Minecraft时候，往往我们的视野半径只有十几个区块，所以加载无尽的世界的所有区块（这显然是不可能的！）和只加载我们视野范围内的区块在我们看来效果是一样的（甚至肯定会流畅不止一点点），所以为了能让我们愉快的玩上游戏，游戏的设计者就不会让电脑加载视野范围外的区块，或者是限制加载视野范围外的区块，从而让我们体验不变的情况下让游戏能够正常地运行，电脑不至于直接冒烟。
+抖动 ABCDEFGHIJ，而内存只有9个页可供程序使用。ABCDEFGHI页，当它需要J页的时候，其发现页并不在内存中，就会尝试从磁盘加载这个缺失的页进入内存。ABCDEFGHI中的一个页，很快，程序又会遇到被顶掉的页，其又会加载并顶掉另一个页。抖动 现象。
+
抽象页表数据结构
+现在，我们知道了什么是虚拟地址，什么是分页，什么是多级分页。在实验中我们要用到的就是上文中提到的二级分页机制，它用到了一级页表、二级页表和其中的页表项三个主要的数据结构，而一级页表和二级页表实质都是页表项的数组，没有本质上的差异，可以视为同一个数据结构，所以我们只需要实现页表和页表项的数据结构就足够使用了。
+由于页表中需要用到页表项，所以我们首先来对页表项 (PageTableEntry) 进行抽象。
+前文中提到，页表项中存储的是一级页表或是物理页的地址，其实这个描述不是十分准确。如前文所述，由于页的大小固定，并且都是 2 n 2^n 2 n 0，这就意味着保留着些位是毫无意义的，例如，对于32位的架构而言，由于页的大小为 2 12 B 2^{12}B 2 12 B
+根据 OSDevWiki上关于页表项结构的描述 ，页表项 (Page Table Entry) 的结构如下：
+
+
+
+简写
+全称
+位
+描述
+
+
+
+
+P
+Present
+[0]页表项存在位 0：不存在1：存在
+
+R/W
+Read/Write
+[1]写权限位 0：不可写1：可写
+
+U/S
+User/Supervisor
+[2]访问权限位 0：用户级程序不可访问1：用户级程序可以访问
+
+PWT
+Page Write Through
+[3]写穿透位，实验中不会用到，可以不用了解
+
+
+PCD
+Page Cache Disable
+[4]禁用缓存位，实验中不会用到，可以不用了解
+
+
+A
+Accessed
+[5]访问位 0：页面在上次清除这个位之后没有被访问过1：页面在上次清除这个位之后被访问过
+
+D
+Dirty
+[6]脏位 0：页面在上次清除这个位之后没有被写过1：页面在上次清除这个位之后被写过
+
+PAT
+Page Attribute Table
+[7]用于指示内存缓存类型 (Memory caching type) ，实验中不会用到，可以不用了解
+
+
+G
+Global
+[8]全局页面位，使得TLB缓存中的页表项不会随着CR3寄存器的更改而失效，实验中不会用到，可以不用了解
+
+
+Address
+-
+[31:12]地址高20位
+
+
+
+尽管在前文的描述中，好像一二级页表中页表项结构是相同的，但实际上它们在某些位的功能上存在一部分差异，这部分差异即使是我自己在实现的时候也忽略了，直到写这一份日志仔细查阅Wikipedia时才发现。在二级页表中，它的目录项第6位、第7位和第8位的含义有所不同，其中第6、8位在二级页表的页表项中作保留位，而第7位的属性描述如下：
+
+
+
+简写
+全称
+位
+描述
+
+
+
+
+PS
+Page Size
+[7]页大小位 0：页大小为4KiB1：页大小为4MiB
+
+
+为了简便起见，我在实验中采用了不那么安全的实现：我将两种不同的属性合并在同一个位枚举类当中，并在后续的使用中主动避免使用不符合类型的属性。如同在硬盘驱动 和FAT 中介绍的位枚举类那样，页表项中的属性位可以抽象如下：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 class PageFlag { public : enum ATTRIBUTES { _EMPTY = 0 , PRESENT = 1 , WRITABLE = 1 << 1 , USER_ACCESSIBLE = 1 << 2 , WRITE_THROUGH = 1 << 3 , NO_CACHE = 1 << 4 , ACCESSED = 1 << 5 , DIRTY = 1 << 6 , HUGE_PAGE = 1 << 7 , GLOBAL = 1 << 8 , BIT_7 = 1 << 7 , BIT_8 = 1 << 8 , BIT_9 = 1 << 9 , BIT_10 = 1 << 10 , BIT_11 = 1 << 11 , _ALL = 0xFFF , }; private : uint16 _attr; public : PageFlag (); PageFlag (uint16 flags); public : PageFlag& operator =(uint16 flags); PageFlag& operator =(const PageFlag& other); bool operator ==(uint16 flags); PageFlag operator +(uint16 flags); PageFlag& operator +=(uint16 flags); PageFlag operator -(uint16 flags); PageFlag& operator -=(uint16 flags); PageFlag operator |(uint16 flags); PageFlag& operator |=(uint16 flags); PageFlag operator &(uint16 flags); PageFlag& operator &=(uint16 flags); PageFlag operator ~(); PageFlag& operator ^=(uint16 flags); bool contains (uint16 flags) uint16 val () ; };
对应的实现在复制之前的枚举类函数的基础上对参数类型进行修改，对应_attr变量的类型即可：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 PageFlag::PageFlag () { _attr = 0 ; } PageFlag::PageFlag (uint16 flags) { _attr = flags; } PageFlag& PageFlag::operator =(uint16 flags) { _attr = flags; return *this ; } PageFlag& PageFlag::operator =(const PageFlag& other) { _attr = other._attr; return *this ; } bool PageFlag::operator ==(uint16 flags) { return _attr == flags; } PageFlag PageFlag::operator +(uint16 flags) { uint16 newAttr = _attr | flags; return PageFlag (newAttr); } PageFlag& PageFlag::operator +=(uint16 flags) { _attr |= flags; return *this ; } PageFlag PageFlag::operator -(uint16 flags) { uint16 newAttr = _attr & ~(flags); return PageFlag (newAttr); } PageFlag& PageFlag::operator -=(uint16 flags) { _attr &= ~(flags); return *this ; } PageFlag PageFlag::operator |(uint16 flags) { uint16 newAttr = _attr | flags; return PageFlag (newAttr); } PageFlag& PageFlag::operator |=(uint16 flags) { _attr |= flags; return *this ; } PageFlag PageFlag::operator &(uint16 flags) { uint8 newAttr = _attr & flags; return PageFlag (newAttr); } PageFlag& PageFlag::operator &=(uint16 flags) { _attr &= flags; return *this ; } PageFlag PageFlag::operator ~() { return PageFlag (_attr); } PageFlag& PageFlag::operator ^=(uint16 flags) { _attr ^= flags; return *this ; } bool PageFlag::contains (uint16 flags) return (_attr & flags) == flags; } uint16 PageFlag::val () { return _attr; }
接着，就可以抽象页表项的结构了，由上表可以看出，页表项就是由高20位的地址位和低12位的属性位组成。在实现中我选择将整个页表项的值视作一整个变量进行存储：
+1 2 3 4 class PageTableEntry { private : uint32 _val = 0 ; }
然后再为类添加从值中解析出地址和属性或是根据参数设置值中的地址位和属性位的成员函数：
+1 2 3 4 5 6 public : bool isPresent () const uint32 address () const ; void setAddress (uint32 addr) PageFlag flags () const ; void setFlags (PageFlag flags)
为了方便类的实例或是指针的构造，额外添加构造函数和静态成员函数如下：
+1 2 3 4 public : static PageTableEntry* from (uint32 addr) PageTableEntry () {} PageTableEntry (uint32 addr, PageFlag flags);
小技巧： uint32 address = (*ptr) & 0xFFFFF000实现。PageTableEntry）的指针，然后就可以通过指针来调用类的成员结构，从而实现代码重用，并且也让代码的可读性得到了提高。uint32 address = (PageTableEntry*)ptr->address()实现，而这种实现不但可以实现address()的重用，还一下就能够看出语句的目的是获得页表项中存储的地址。static PageTableEntry* from(uint32 addr);这样的函数其实就是为了我们能够更方便也更美观地进行指针的类型转换：PageTableEntry::from(ptr)肯定要比(PageTableEntry*)ptr看起来更合理，并且在某些特定的情形下，这样的转换函数内还可以添加额外的判断，让类型的转换更加安全。
+
PageTableEntry类的全部定义如下：
+1 2 3 4 5 6 7 8 9 10 11 12 13 class PageTableEntry { private : uint32 _val = 0 ; public : static PageTableEntry* from (uint32 addr) PageTableEntry () {} PageTableEntry (uint32 addr, PageFlag flags); bool isPresent () const uint32 address () const ; void setAddress (uint32 addr) PageFlag flags () const ; void setFlags (PageFlag flags) };
其中函数的实现如下：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 PageTableEntry* PageTableEntry::from (uint32 addr) { return (PageTableEntry*)addr; } PageTableEntry::PageTableEntry (uint32 addr, PageFlag flags) { _val = addr & 0xFFFFF000 ; _val |= (flags.val () & 0xFFF ); } bool PageTableEntry::isPresent () const return flags ().contains (PageFlag::PRESENT); } uint32 PageTableEntry::address () const { return _val & 0xFFFFF000 ; } void PageTableEntry::setAddress (uint32 addr) _val &= 0x00000FFF ; _val |= (addr & 0xFFFFF000 ); } PageFlag PageTableEntry::flags () const { return _val & 0xFFF ; } void PageTableEntry::setFlags (PageFlag flags) _val &= 0xFFFFF000 ; _val |= (flags.val () & 0xFFF ); }
而对于页表而言，它的实现就更加简单了，由于它在 4 K i B 4KiB 4 K i B
+1 2 3 4 class PageTable { private : PageTableEntry _entries[1024 ]; }
而由于页表本身不需要实现太多的功能，在目前实验中只需要对页表进行初始化以及取出页表中的第idx个页表项，所以其成员函数也十分简单：
+1 2 3 public : PageTableEntry& at (uint32 idx) ; void init ()
除此之外，由于页表可能是一级页表也可能是二级页表，对于一级页表而言，一般一级页表都是直接拿到地址，所以需要添加一个由32位地址转换为页表对象指针的静态成员函数；而二级页表都是要从一级页表中获得了页表项，解析出地址，然后再转换为二级页表对象的指针，稍微有点麻烦，所以不妨添加一个由PageTableEntry类的对象直接转换为页表对象指针的静态成员函数。
+1 2 3 public : static PageTable* from (const PageTableEntry& entry) static PageTable* from (const uint32 addr)
完整的PageTable类定义如下：
+1 2 3 4 5 6 7 8 9 class PageTable { private : PageTableEntry _entries[1024 ]; public : static PageTable* from (const PageTableEntry& entry) static PageTable* from (const uint32 addr) PageTableEntry& at (uint32 idx) ; void init () };
其中的成员函数实现如下：
+1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 PageTable* PageTable::from (const PageTableEntry& entry) { return (PageTable*)entry.address (); } PageTable* PageTable::from (const uint32 addr) { return (PageTable*)addr; } PageTableEntry& PageTable::at (uint32 idx) { return _entries[idx]; } void PageTable::init () for (int i = 0 ; i < 1024 ; i++) { _entries[i] = PageTableEntry (); } }
勇者奖章
+
=piQnp5Y%KMmE6DUjWSJPL`j`3`epuw6{>#Y1{)aZ49Stn3O&niM
z3s0}~YE%FdBMUseq^+slt6f=M?XLK0Fhx5%=hws6+xmI<*3rcErwJKDA@2Pk{kn*ivA4V(?E?aW?#@YcZ0#0kL2`Fg9r^zZdp#=y|T`bXhEI{k+y
z{c5P+Yok{JFfy_*0)F_*kBjNWEUcYP9ACe!4V+CxOpNS|U)z!~u{Coxf3*$s&nA9U
z=H%>XVqgOgBN1k(udi>auP+6Z@DYv&4yvoS3nq{T4i^DV9oT7$2Vz0uEM!#6bcbD|
zuO!p_HYwK9Y_u%P@}S_eZnEWK#h1_OwU%Nbn*BSoOwvANfo*gAO&CsyqqerEF!bf_
z4!Jc~Qg=$dhZN&I@aWPcw$o+B*
z9L9Og+L;6PV5n#rby{5v6t4Cd`N55FBLJ>klZq7LDR)exerSDh_Sa(Ky|z*+rADT*zr!u8@
zG*SvJSR$p}>Vwg$O
zqE1S?*c8GF%oP&k#`RD}t7cOY6p2B=-bVOjW2IBTIqyA^K0q!UxXlv6(8Il=yD}NL
z9E~pk>#aG>p@7iM_oMIc?h(QCLEsJ*J|HrDhD19+l+Zk!CIx_FyU50W+jftf)=1K5HLa0?2>
z0Axo-F7X3K|1l)~0jR$WmLG$bot^bJnEe6P|1y++4B(&R*wMt+`E|_xxa249m^j(F
zI2yeUZl)hN_Ondb&er+$svkwKF!r-Z*2LJtK*-MhH3Gb%B7p66e6w>h{fq*_j&}Bc
zeMZsF`E`K5UjD}*@Jlnl0nJ-SJ0m3%=hu4aUtlyY
z(WoNe2Pn{sx;u+2{jB)MS#c%C*VC`4{EyRr1fie3|3^!|;tL}?!(Ri?p8-cEvIfCl
z04pG8^Ib?Zll^mu8&o-Rs2I5|DkK;QKtCVL#~YC>r14>YU0UyciV6j{`UJv|MYTBd
zM7aEu5tpMdvS`H@s#Lrh{nELafsIyg`Tm9~g-G=16L&p;2TzEhP)B%-e+^V9rk`hRNf_b2q)rXax7z}o4D?!aeyzbD|`zkup5Yc2$ejpP@gi)fQSuj)K9q|-nIM{;D$
z7gVJYZ#s`%5}u-7pPHO{akryD2D_G1Qwpf}rbRAFhbd?siGc4L-e%)AQXy`|nVxqv
zvco4*btG_&*}Vm|W!)M&IcWCCb$*v*GwPE6MiDU>Lv-F}?WCnjEBiD9^^IfYQtYAi
zP?j6A>bCHfH09|0xHW5Q@WZ${E}bcZW~7048`B_+`eWjlE}
zms@Ss-C`+M0`+=K;)}U_O~)N7&LfA(Q4(|nZeq1p%=mUMxzQL67K12SJG#g)89~71
z>UgL`Sr*HeKhKcqNt;D_i^Vk1
zmA`h2)IVBt98I2OZ#GcGVbu3BRJO+tna@QzQz&(3Z#Q7z%1a4y^ZN*(Z0PdWUl)y)YDaE&qT<@qUsp8CvcvH=h^cE}%+^CiQ;>
zxF3Z1--d`Evzs5$?l*||m1qCwAmUFGsQ&>({0
z&PZG4bn3_q%Co2d7(}x`uCj+*=9%Sf`kmYhMWV{4g!Pp+Gz^>f_-lAFs5$1#dPnTj
zPU^N@myX4$LRyC(dYEsuwiISrO`u^@>%{l1aAkJ)%r*-#oz|=~Bixn%d1Rw`UJnE%
zPU^`@LeqLGeZ!F@Q~Yp?G0A>$O&Bw~kjQmhoe
zh$a#4ngUPx?44~LRN-?=MTktJT(YaE&iW>!ou-xm473}Qk|y*dql=EAii?MnOdYPI
z8L@PRa731o>hOfio$3158^SK2tOMiIe|5tD7Qy-#di9?tS3jEgZE*YzCuDwgupcuu
z#aG|>_hQz6-#LHW^*_ZgMmDCu6~K1XR&7@~UIW-SPy!u*si@*&2kDzOmuZ`bhUzXN
zT8!F44k?@ASmXMaW#3T*QB6i#F0}e}T8s=p6EwY3|9r2AmC$!Rh&|pN
zkxaPmY|nO9%jWQU3Wm!|WN@N-ABTDL&dMvq9OCjRbZu%MMX$}riPVLB1V}1xv3Nge
zzED;ntilSDsKz6$Uba$d8?AmB<_(n@ruOX~Z6V)mUAp2SxD{_&*y%lFl*VD1WXDcV
znP;;_(mUp`&k*k;YU4$iKpvE+DyfWuE&xtPk@*r(HK!|2ueVW2ZrheUeIWZeceOc8
z!Ffs0j}9bn+m8VhNowV$&duqXEMm5zHPSCicvAwbLU@y7;$T?At0+om@y0m#d?9@hJ`B2!ySq3WvxI2(RjxNkDP^s
zP%tIfgwF-1rxyw*2=bMW(~h?AY3gjHo!(@H#0U%hf>Z@BE>ga+!@}LO&IZd_hV4`F
zQ3oYXeK-P0&2ffpqB{_`#0Fp>d(VN%6t3p(JM={rKV@G>*n2K2ZD4e|aI)3hBPx%f
zHvkLYKt+8usq3(iZ#gog;ZA7o34=RWOz*UZK$M1_UB5Y|kb1NWN<$^~@TOq#U=42O
zl}d;pa`rIX#MxuPh;p7s+mWI##3ij*-tV`Zet0g`POt>}Y1ECfA0JX=B0Ys?87efr
zwm;EYhg~+Q>K2}&R<@mQ^v!!HSDyzvveOQ`m1|jtjr!9J%Z7X5hWjwNTKHj7FPB@(
z1H=pM?c!i)R@}SYe57>0Y_;kc;)M%_5QCY*ns%s!$5b#mEnw8o`eiyvtU^^6_T?5^
zyrLx&o)(U9^v@CzRMOI(rW_=<4;6VTOQ86XR%NVIu>xV}RvK4QbyNA%H&2A-?W5*o
zqrI*wwsICZ+xJUf>^8-RxY#7JEMNo+CRn!Q>n@7z
zG_PgPSYfU+C%yNt<-Lm&5QXn)7;cKsSqK6iZ{Jb8NmqGyElcoJoK}WrJ=RJ-T$h)i
zAY6;AJ28+|%qMRGOx#G&wLZrd?q33XAh3R`)kqmMU`IcZvrQ&7pa9A`Od<)7BK;=F
zBim-?YxVxhGZKwh5L)J75p9%NEZi|cSx1SIAr89;@soPe5!Gj$Yu+r&ZG&_s{S1qd
zSXmk^I|KZ=>A;wExp&YEIN!b@T6#bxkei5jbv;6{kB>e-T}(WvEDrS)!u5-z71V`w)ZPkgLGL%8ELKGyZF48*9qq0x
z23BqP_NgNk9ot(0Gn?H)@4L44`<`-fp^O>7WiW1#C`s6ZX@=SReOMNPQLe9G{JUJ%
zDc$T831+bh8yEINap1&pyv$4Z;9D8Zz6^VkC2vD^hFK=0NV^!%JzP8J<4X`e2!nXK
z1Tq+AF&N?na6~(KUKi_$dTi7mW}x&7zk$rMN1|6Kd`YP_=TOtjySu=kxUl-nljsE)
z6;{9qu^El4JPJYe^GrShLS+`Om2>`fgpYDo8xj6acmI9mn=`^E3;f%7sL%IwvBAb|
z%S~kEF!#F{Wbh;~BTr-*}<=KX|Y$MFmn8&R?~~Uc7u`Q7gGK2
zX)=G(h5sS>GO{qU{~c~xuQuwq%7*qjeeKnm!Gi_9H+7XWG|O~Al`nE;LN)7#Bq1b(
zMlami=TETdD8d9Hjjuf-n?2}3MCtkj`E?DGvfUM{9T+C(eLUd3mp+Yg0Y
zym#x|rysXQD>ls{CJ|td^SbcEI$tE>p;El{0&6tnj87b|6LRlh2+>G4_cS2iR~uPD2Hdx=-I6P#jtW}2av
zud}Vx5pri&#oy(<;o2UYL6bt2VIhKM8tGo`Zu0z?efu6ZsNRc=|3cmx|e>3}hP;-p=v
zy_^f6=dO1t$z`@5AL0*TnHK!c#vP}zWs>&t+)hdcZi1*5@`XXQf=<)3-qx0S%r>lG
zwJw_s$u}(q0#;#41z0{3Hj#>JCV+mNBiO+e#-N1)n@W5%MA@Luo=-C8sCQgmH`{Ml
zQ|4ZzvQ1nIQ}p7N_^8>8xsD^)piO=KRv8ETtVKl%SB2ssM$8;pYZU%_S)PC@#d70Y
zyK*^emV`mr=rBOFI`OkBZIcRgc#2ki=vHL&v59q~%S2Lf8QLhR+9Me#ltKZb&2*rW
zSEUU_G&?I5s28eCH^cAlXUX@7VKE9BIX)KLq
zkJ^~g-%4RXAKE9Z
zHX^Pt_Q#Dc#xcc!70UH9ki7S@VMqcIh9V?nvsls@DT}{Lw(4&gzPW7~9vTfwU_cR!
z1#?${GQc1@nV4BnA=wH{nHy||-EvkO_kQ!z)EZdrl=}7%HN6@O@kpO_wZo_G4Z;8=
zbnk}^1}rbLhgKAc={|i4tcd5D?z4>?mVNMKVPnd0$(`hO+QcCbtLEv46)PhsY{U1+
z7~)@+rel=&k>TaPH46*Q5a#Kq&m76HOr5Z6UhGcqk~}I31zeN!<`ZazMZ<_qgM!Pu
zWVjNtec0nwwt?A!o|Z|uHk7{n7*Cxv?;|pB8Z{Pu@NBtZ+(3aqdm4BO2K+6&!ul;M
z@AS0-uTl@l+1GhvNJdek-MR6%8$D!MeB4*qk_GOH5um*R8R!MAR+d1J4K_Hk{R4{5
z`Ptvk4j*Q*iJ~FDJ&Ru#ywDr#*d3FGCs11xqgnx9(;Mg6A4?h*kJL20K5nugf
zMAMZO^Q8#ZJpC6MvW^I8@_pW|Z{pYel#PW=`&7p|LmFPThKS_)$4}c+MvX7~So1?_
zNn>>|BNe03?bI)esubMxx1YSbvg4P&Z*&v*XUDV1I*_sZEXW(-J*x|w@-=*s4;wr$
z(680yE@kIYNhs;nWYLItWVPC@X7ep0$ESki*5ayIE@7y*nvIECA~Azw1Se2Rjpk!n
zYdXV7;YF{g;xlF6Lp2%5lH1)Thp3w!CRme^52`do;oA(h<|(eM!wbp0f(Un6s5q9e
z*wey_sr#m%sNPuz#2F9X$L~gW3_&pp34GtQTIf9)Q8Yu(acjHx65fZ
zk#+(1eirBp925^oSaTqz00^eNkF-82Zk8z&A~&9b5K@GMP>+i;+^T^6S9Nd=`%Fl2
zX<(=apDsgL34wRUE8>J=EM$+CZ;;%lI=$Dwe*z<%xEuu9MXKZ$_L2okd@Z-#BzbD_d_|KwDf|K92v9&6o_bj?*v^*<*HYw(79bhHdhw()uv_
z#XQXXxDb>D{C!vmtb^?}YOk!AEy`I7vCw^2Ck-|DXz@CR4&tSRj$i30OPxf^=$MRw
zTzI9Q^vzsZR#}@N%ckkM9~)?cC~i2p$QH&V{s#N44?6f=CQ%XS-Ih0Wr*e(L$zafR
zt}1fI^_chMGi|?R!AUZis5R5MM4@uQ6{_^(q?!Pcfo<=Nb5^FYW^5{&NGUl~hzMr?
zqn!q|`uv@6Ov#W=ZbN3X?51L~Z1rGOdKap=Q*kh4`&09|F2}@fqA0!>Mk(%`sl25Q
z26{6m&))qM0n;Sl27cxYyYJJM2mjl-M4qFST3^5R=JGjm-;47DqvJBeu)Eun3u+ab
z+Y)UOvALt$%F+&$-S^@O!^+gD=h@%Q*Nt1K%FJA*AQ71mxG!)E&agVaE@>!zDJo0<
z2IsRm18xqVz#a9-9ThHkk&S=3SRx$bY?-G(EQ&+wBuHc&*_~;Loq1(Iy)OqJ)rxQ>
zruNp(XZ|y$6}X1lTt@!-@g~`r+VVJ@sgqn`GS-X5O66IJ&IUIYnSpCY&VhBG4r=;Gc%#2b6OTfCp+(eA%KcuT3r7EEB+u?
zzOD`ZT%r0Kbo<
zlhf@owvdjIcE%sM(G8n!d~Y{2UhE3X9P9BLAlb5~A_>vxf{f|6X7#Gc_IZbnB(|`M
z4J(){y&2Q7^T2|jpmi-W)BbbQoE-z!+*W##MZcXKey$`@6
zJtsWrt)S%zqj0BvEbkf;uiTFGOr-}bHW|f|?Qt6DlO6?@-H|*bSK5f1)okdwlHcy}
z&Cs3~<=x-TdtxxdAO+!zB!d}a$7)VAh8hz*_d$B~l~$Q3
z6bV7@A-@f&wZc4
z18i8(*|k`pu$ADO|4qCmu+a3U$HHo;*96b0A
z3*Qb(p0mG1+P#`fam6I35pyamWcmVfAIhk29TA*bgmvZ?>)%eNYI1-yCX;9eS!2?V)@)_pc+wrKY9@Q{#!ppHX
zvso?B092C^yYh?{$v&|XJ%3g<89qI)1z;u^)RMfE$jm3Nve}3&-E!oG+-hYu_+dmt
zc1fYTZW6e7!2ned{$+|xhtkX`G!Z<(2X03sH(uP6
z>H~N!YKX1uMo=3<1HtQie?~SLuP@cB(P%V2Vnzh%BOIEDW6F~g%AoL3SxI2cOi^;K
zYT?4!REYvMns{s;lur!KpEQEH^cTHwgB>mdf$iEl!;4&<(G(&Bsf6f*E5N1;uya>S
z;pc)tG(B0iz6sH=UbT@7$x?tyldO!f0_a;5{xUs7{ZSLWOS<*lx4y%5A;}=@ISSrki#t@#(M;49bs84pBwI*tD&k5Ul|O>)MuI&jFsOCdqN_
zSCM+3?un$WM=YdDkwSojpnVfvV2$OIHue%RvDsKcQ;G@kOR`~SA9%p4@X!VDru-h$
zF}+04WLW`&;`gd~k-AImIGC~0Mt79p#!|Vlu*c1mJBskbV5%AFyG6Gsml2654ugH5
zcQO-8Yg=Ok^BCLP(Bci~uHBoSxAvcK?Flg9GI^+|Tky@*IQ!IC9;w5wRqkQt-8QqlWnQVqsO_jQDi<+g{=!XI0)bW`MAQIK#BqO37)$iRFR0$?ul$iE$3nDj=nc$KwrTCdJjqt{e+&s^E
zI9FN~i3Tej^9T=;1D4Nh3_=MbveGSo?7Q+w7m5tW=rC27&6r*kBEh~RGM4IYBa;&eTyGQ@;<-1+9mxt2?p?Jm
zmLXIqr0<~n>j#&@38T@4P(FNdM#;f5jyHD|#(fDV$-NLiuW!84dQ;3Rk%
z=?7kjTP_+m>dcUW9A>#&^XO8W1o#GYbker`jZvI!p!EZ#oN!y&xv@LtXh7QmOUtoQ
zZpt~1t4AX>CwW^JIbzSuV$)B-`JugQQCygn4Tx{8V^hPdcyQR^5pav{9;9z00BLBj
z>_+p+qlE@tQo9Ex*T*M?3P2ELoY$lHkXMS@2rli_r+=K5;dX?q9U
z^K${ZLP{I4S)S}6Y2p*henwtEN=6MIqL)4aL=-Dg;d^fMcbi;J79N2U-QIl4PZr-H
zYxAm6q#KhpFhd~9~Pm;C~V=jE)%+Y1}}Y$Q-&7YRw(3I
z8H*#6dC5T|ZN)@L+{QT!(%xT-K-6U+8fsa^)AsTKQQ3^Kd4mOLtdt_K1!VNYS_+_c
zGa0z&;NrZKf*w2Wdv?j}2c;Iq%-B+y#7-{$6p*8PWaYS21NFCW8rf$51ulSLnL*I5yV-$jyYC$Cfr}dXEM_epnFRob&8Ea4aB@Xa}9{#HaP%i&n2uMyF)xDG6t1Xr6wU7+@ndwcOE+1Cpg+OL*W
zHl3}30PJ-4xW)G?H~nHnRi#kRkY}4jSj2ZqXi$_VXcuD4(fJ7EdtI}L
zBx#)#4`ZJudpbQmA6Yv7(2BGBVzj_TP7j^A&V2$kS*?px!*9M0Ed%ps7?IvFn4eKo
zJQ-Vv$4L2OGjep|jYHGR4NXlMEL?>pIx`^$RJIW72-m8fBfNAClc6fc=WlTf4)>410v21SqzEPHMJwg(9`nb>
zzs&bf9-U#9Ck7*HFdo8B)~Q?h#EX9B6ypBekss;dCRnEHYCLHtUXF^|N%)Z>BQnDs
zJ3z^(ieQR_C%q!)X>pF2E@~6Pt!y@`KxX)jB0F9wIE|&Hk;T3uLCsr;EdQEIVH^>t
zA^oiAFiCRC+Dh}o$pNr0+(9$N1`Bg|^p@_$pAQR_gd7R$8kf*++9yZd;l9cIWz+43^e
zmuX>F`pKb;7p=ukBH&JQ#`?378xBySXF4A%P=Q;LFM21rZ29*OiL*E#65qr^#4GtF
z3qjB;K7iC~JkX)M%M-jJ##4v4iZh9&+OT4!EwykZY-H(
zI^T{L+dUsHW?Ed+kroN!`8dgf@Fs|HnTRgX!-!W;QT}a5_E=oMBz%*WEdpU1rWp7XLs(Qut0u0%5Uqk%*Q>C&of{4`^g}dK4$1eh>G180lkW>~ltHdH%i?^B6&Cm7^dpT3MtqNYWgZ_qX^lW!
zYhW>9}zpa+!sPY~4+p
zMtZKekIvXNsSq!LEbhs5&J;ScLH3Xq1Ny
z@^(%TIBzC^k4M5&ip&LBgBQhTgeBft@meZQwzBxCzW*+gLpA^HJoK(C49bY8k34
z^;ZcW1UwR3SGZg%`Ao0+?f}~9l)S@tT-57xTzU?`I%N41>1%ym@}+OUm|b!3Gz9DB
zF}aeM)+yssLdT<}a$<=A@WNksyrHJbDU<1qJ03rVh>~hzH6f
ztm*N=A<0Jm1`!#h9Z(ntJ9(vZePyUtu3LaF1j5OGOFN?sH$(gB_5&o6y^VD}d&hl(
zBhZlh5Dm9W$36Ua86XHQ#2Usvgyl_blq+?2u%U+@*N)9e%=U*K{ykXwJ=li=*b^29
zkbR$#H?WDo-fw`|ZbHt;v#->0H!D@~rY`Zazxt&T76)KXoyiBTyMOE44(%Mnyx*Sm
zoj@Mr=wXhQxPin)&ce;Z($%x*6H>Y_xc_oeAT&89M@!=Gd@p>Dd`EFEKOh&En8&ki
z21olDNNn7dT9lm@cd~>p_vGD|ilc{~b?-dR^6a|Dbj{P*Z5GHawvXi1UyMX4gY9j+
z%QgB5Xk%VpGI$wFOXR(XRAr7+%_gr!`4{uD>4zSK81%BQ0#!X+^t~jp6ym
zL=D$jn5;WKlQUiGkayRoUkY_l
zq9Ku1l`R)sBCDxQs2fr&N`!7Qy$LlH0X!=AchJ#+S^h+*bUfhwlQyQ1m0@kaqeFix!a_8Gx6;RI6*oK!nx-mLB*eKIY;hVx2fb>NX{~E%8%SIxk{(C
zUue649&Ave|CRGH{b9G)zrlHb%`Ny%!F|mF{Eu_qKcvgQZe#necboigE4cqAoBhLL
z)$gM1>js~{A=)0R>BOuxqKmGWeG7rTHfcPcBBE4Od`je~yTF;K{DN0VYu!6#$-(T%
zIwLUSd4l#W<<`nqnqG1|q%UjU{maUS46tDY%FFXLr%nk1-%AP}V1mzn^8Qe^evjwO
z?e4q1V_x^Oq(P!l)J*4v0OUa6%J}L_k!tp_Pts>0rFZAbKtTs<1t`EiUHq=7+a&RP
zzM39&
z)$Ej4{MHFpPyC^%SQ8Fn9woFNwJBU<7>uJ)<#`0{-j_O+~mEkQE
zyYi{*@Vky&d#>ET`K$cMuWBwO)X`JilIYq`15SGAg?@P(s=>K`6~NvbPHM3XA?liDFw3U^(m
z>+8LW*`(J}m0>OmH8h`m#tut9f1CzmWmbjF5h*ac
z-N8{^He5CbrwV#TGma4Y&gf}9Uc}hFAAXB>_eFTal2CJU%Rx5j`r6R>>SlW|fV)Ar
zVmDHGTR~NQy0*3&zqcAsc6wB{DBiRv9Ad;Hho&;D=U%hPnVffSAwzvanK6bqKu0?v;Z>cM%(rTpc(W=oI7ki0B{&BE!zN2LOhUL5E0E+C&lm
zP*Q_OduEsq*t;h~DS@+C`F;|}pfSYX7zd{J+zz4nSKyuGbI*x#GoZU~9aiFaL7QrM
zK|Ht>KoaPU;Hcxw~&+H@W@+ICkI}!an8t2oYuc4(mA*h*{HJosoGmIeFA|OIh2w*E-x~
zkOc;ep$=2e*o95$oyWu^pP*;;Z0l(-GUA#+H~Uh0Jvk6@nQ=?nvEYWQQ17uWK82}$
z3+r52ijioCg~sF{sDN+h?}niD<=N5xs^0D!&Zbk5;(XCQx|%~ArWJ(sWg}mxyqoy(
zrcZXHyTksia^>uebopb`iwLK(aZ}kuwDQeKE|44^L1h(!toUA4>ET^KPy>IBN&}bT
zyqB`6xM>NH^(^<}Wx5XB`>lYAgmM3=w$%)!iA-ac{2|7^wEIR9N0gIyI{EZ(CvnrG
z3FTJpZ3CiD^_1%9r!=xGcl(y@hri$4i{W@j;2@;bd0huiQnWG14}2G2$4kq?EOe@S
z9=P&pu6o8V*Au_nFuIv#by9`X`}pHzR~snPAa~RtUtaK4XLp%w*zwxe7wUNKXqRhy
zYlkuRMw#MlG!hVeXcP%`5C5xmhC8}X1jYC_g5M+F9cxNn6vUWTF?i{jF{`lP9DSjz
z>{@QYM8;TFdW*ktSEOLrsvL{1kwD6+{mD)lzP#{}oJIN#D5AVkTZSS@7|vPP{V(Wp
z3f$sf7+mOgc^D;?L03ki4duW;We9Op<{gntwCkLPZkdVB+@KoNh-WI9Q2$<#0^SB9
z-3cjpMWS;!opg<+&KX)3nmH+%88#C=s%#<2(iWMB#J`4^lX!ZV~Sp=cp
z8>!vhaZr|OD-{6_Oz({khy;&dL9yKav}-#Dl$jQv>hLqs6x<8NEb?gqctB!?_;!hw
zMO(MCsR}*9PD)YMRi5kZdga31wsUZ+>XQuZ^M_I@u`PwfM5JE_<30=bCr%4GYPrJ_
zX`B!HVXdtIh=(`;$gmF!>T(|@t<5vZslhu*9#|pv)g9R$HAqEOX=I=_u|H~3U_kh9
zK=^ZRw(&2O^%9S0Ms;$Z=2Q}E2FfNv@9a6f!I)kAiuo1wyzSODx{hUHRM!-Fn4Qs~
z>FsofoQ@m|fM%%x?Nq^&&jaR~PHd8qlL058T>A!ZI3~Ao{FXK?wyzu5hwNPr4~Q#f
z#xQr1?uOI=<{dHdF0hI3^C0IrsPgv7o>#gOh2=UF%jLC1@ppP0V#buSFmfBS+={I2E>O3-3
zCl29~T>+r&_&GKn<6rfHF;6afiUBs?n%yKB-!S56AX)I>q>sO2vG;=*{l>TsU;M6P
z5;2kvD};A$(sx9zmr*zjt5`=yq+OES_UQS}qmHHuQ+k$9kvy^{C@3C(gZIAC%eoTI
z?*L{o=*T(zXj&;J@}nu@T6~0>lAg1tPezkYpP%&^Cbz)xU{aaN4aO+U=Pow2NrYua
zSjl>7?OtaMfKA94dJR0v1|iL6frm=v%IT6LB6O5!Osni29p3=?29H5&1IjvRrx@Bh0J%er3;J6`x^ni(Qa=x608QMB6}h5F!2UW
zQg?Ex6BQ+hz-YQDZ1na99M}5;txMVD?E=A#vm!
z&mCEK+e8R5Bf$s1IbK&(SRe7ymaF);I9n7pPNO#3iW^fEXw6Wp;0PSh?Gqolcy0Iq
zb$%!tAP|uBqJ-8Im2q{|KS*st?EU__UmBIcBjGQ2>K~G7{tce`%YyzNwb@^D5B`JN
z?2ktNH?`USQKrHFM34PL3dQdX_Q&fW{_C`Z_8)pI8%B2HjK!$rTtAS
zrR_g#h=rudXFUpYwWa$IYu_Z6_r-Pe@NZfpapIW;sXad;RozJr^si1%Y^JvNSC4Kk
z9BQHahwC@UOF3_bywUwI8^?8Qv{%|YvUgTYi!8LE9(KBQJ*40HEqp
z$l%%XHfh-{F8VY7VBzK)G)yGb{>Ay4P4f)QSi3~yj2*gV+-)>$`c{3i%MxBrc}@&|
zx?B+7KnyVEi-ri^-Jz!k6YtIaEV$EQBB=ET@R&N1Ro(}Wo2=?mnI2IFXyE3Pay@TK
znqIX?q;D&jh~E_|4;|^RZ5Ym|I?Z?7%Yf-C={q~Mi3TI1IF=%~4va6)O`;OE@*b1Yl{p-q3YrL);xL!`Kl95l14M%0vR`5bLu+pAH1_wctpqEU(H5A9utH{W4o2|c*d!D#Fa3@q%vnC&+>sjy%-(WiLW36spH4t
za`2n39S=lYv8#nfX)K-)A$EMa#90ipSnu{dZ&4zle^_!UWswl_xS+Oxd7BEhK3Vv!
z`f>I99zWV;G)COb)b}r6*zRCazED8LN?2hv+?Q$Yd-*L2y?2G)r^;>I>Cf`h)USOa
zk)4LG*3=+tgX^epOuTr)5!n=j&RJ}y+1^4`?Vi)g8@VkW>Ywze*;f+sODk{NB4j)N
zAoPXxb=@3W-ytlTG-W3@D{cb@l3h{*n1LX{k=~bIAIO>=iXjV>fcS-xZ>{*bwC_YT
zlroh~2ZIfs9~z-u!s*L%Oh-XQ)*H1b!FJTdbQMXuc-P+9=MIOv#?4|Em`GtV#qH+;
z#?ZG4A1WSAJX~$y@l5e1ul@MMYw$9UxCf55k-1y~nKs_^;)R0>!A+m{J~UM&Q_tpx
z92vuS#qp4Tz>POjzp73{?@E66?cT1ug%@%3vnu%UTb*_Ey9Y*eQh_55S=x8d$Xpdq
zeQEAno#?N`$
zG{=$g3iKKWL{hQ!sg3rk4o*FWrF{2(a`k9A3@f@#x{XU2%=dH5h(WrFGkEc`j^1ei
zda_OhE>IFFOpQ>76r*zvMoDy&FreZ^4w;}UZGx{{8i0tl)k0~beRGY@VmuKV0bPU`
zA1Xp;Iwl@>96$CM+mAGVWlflPrY3E~1kCl**DiYWNfBA;{_G?FLG+Z0(g<4L54Vnq
zp)sFg6;M0d1)^s8mZ5DYqCxPbh7DPI1T%yZ?QX2+-65daH=9nRn8Sg%br?XNF-vlU
z3@^8BV_b*vCjC~UaDahkBt_%Nd`y@+hR^Pmvch~aPny}6RV7g72~?=vGsC
zh|D{vJej1T4RukN6h3ELcGZ>f@Sy5jl|g5DPD?Z`q8V2qbduhO&47Wc%np17~3yTkUxmCDI-m~`ZtW7kwNGH>yya)yleSQ(0FKDiD5{I;LH
zv}i>@S$yn7>{}ZiYhqO}ZC!nAY;5qX0JUVw}G2$4C
z2n}@68#;s!^OWI=At)?0hP806Eh9CKrKizihbldx5n=e{DMwSARg2|vy8*&jQ5a*8
znLIkxQ(lQYP9FvRX=s$!0d2ZySV6?$Wu6v~nPoOgOU`2D#fxLU^S0s`!hV|qW7qXb
z=Ihj|B8Nr$EWFO2P>(br1HpI;UNE3;F1)`ZuXI&$3##A`S@|X(_Cv3*y#$q$qJ2O*
zcC|uhiTDtUo~-N$N3haRg#p}rYWN96Lpn+AYjMX{w$ECUR>?9s3oX%ZJ_~k2uB-<}
z&ix;ET5`+1jUIiU#v6CoAp?EiQZ`R%t$7q*s}v+PtV1cqeLPjZ8}RHpeQJ@Y;PvA$
z?s&hyy(QEJ1-@?2tsWwyy|$-8nLeFRQ#1%hQo%#RL-{
z6uXI%8c@07gu5juu7ns|tP^L1CgO~27-yQskqg~Ac!32GokgckeHr!k;K+!20llNvRwiN^=2Fah2j4sB
zm=z(7g-@0jKz>o}vTYVKp(d9%i8GBAMozUyK=y3vH*=
zt}q+Z!QQn33M4YXQW-GP>c((B1R_gRTui$Ka`oxiXC2)(!}$o&P;4va23mEVDwgLSW0_%s6VF3(0VVZ0}RBz3A(
zio;ISN3SlU6okfpJPu!WsXne))1Vsyw4o_pC~xbMoEVDMXWVk8+u^2_Expu6V!?
z)GrL*RB^VJ6ICvf_4$Z51rq>t_Q=*VK?9RU|!FIyKu_O<(kuHls&tsWl!oe@h~OM7hGr&CKnz
z2Paqsf%ZuZ%trvM4r-l9YN~4gIX?Gbb5PAFywZvzu0W8&A(9B+2qk~lZxCem_Q;R{
z|Ct5**_{YkG+`M4%;S&JhZ^3(EwY)i>z8YF&pix5><^s>Cu7a
zChqc4x08=2)1+0s@+h@Ro<~dS!iO|!`;w-1?VsAcA5UWp4X
zX}cB$#rte_dmm3EHe{wk4U5m1r^y~$ue!Q04p1goRdltrtRoS`WcpGeN-$nF9WQab
z<+aD)$Q6b@-m#6)``Uwrh};&S?xDH!%3CQX9);p-^9DY#Ddy&hCmLZZbs+R~Nd=VQ
zJ*U#yCf+fCI4#`SKaVay@lQlY%X`a{Vw_^x;6mAHMBP8Fu&lc9T=tpI9InA_ENuIQU@|f2dil4<~wxG0iF%7;pOrSTiw`3RfuqD~c
zinbNcoPF*OW1^=SZps><7&CX*X-%Uo1j)$&@)sY}!89qM~@x(PHE
zM-{}j@0rE2ma|YXNaQnT0UY(~72y?`J=^|8m8lIbjX^4BNJCJHxhZ+Znbpc%u4@UA3#b&ON*P*8SoB
z18co&jq$E$jydP^`GQuFJ!Y5-z1G5R69K}Zk$peM<10FQo;U7l!NW8ejp!Ji2W@M!
ztqcgZ=@15PB_rIp%I{ga7Z<1I=_6`NI87S6UFAU-uafoFVJ_EDE?>2$Y49XoVcJS*
zeGU#zS1q3@S`BXSRtBkb;hL^*h5r1Rft{+Uh-=sG#%juA;T9tdd1s*iSj_t-N`x$$
zol?_C(>t49#2TfB;E5Tqg+t9u%PUu2|IH?VPCMsa3WihOWkOpROih
zEYOpCRstzkvywlKxdBMTe#>iH69t(Fl8QV1xO#aT9hxhBdEH}homLl)j-2a!?@
zy`!^C#kdMPPCfz*6vz-JT$K#k?Qwb1AjdL?+f{w~AaF>*d!
zLc0aOFF>yqlpp$G+}Hq$9tB-JTm$pPW`!;ntTfUnS|m$2A-Lop;SbO6kDsmlkN5Ld
z4y`gjt9B^iGYv6q3v|VrETfU#s|AnpieWO|(fpa32#$o&#nq@9-k+SuiE{T|x6Pl7
zZ~Ik0@cDrRb=ZEs@oD>}S%Q(JRPtGFE)VX5_Opz1Fht4yPN>iF#O3bUgG_NY^o^Lpea0)n9VVGwr3aFq)^yG1{2T^`wm4&
zZ_YONv+|Sw!5ZBU+v9~+2&yTmyiK6bc!8Md0g=cqz%}Y&z~;;@<-{pFZ%@>+E-$3?
zu#_%5N5j^;-XJJ4VQG(
z(vy@1bR$k_%p-pGt!@U?AwX+e&$LL4tBD>yJ7MnXJV3YVfI~YiqjRFW*AQ$qMPxO9
zby8cr)3$<77Y6Jy+V)ci0{ILB8q|V6*)Vei28h?%*>a|vI$tfRKtoC^<&&%DsBJGd
zN5Yz|6Cf)?oZHM}M_9)SsnKdySjy9j(gbsJ!_75hEFBT0Wrxwg<@e(Qc+M@27YkK;
zWXX&hr86+2R4K=`tHfv%G|Ge5TPSowSBuq_=#i2c2ZirA{`n=9we-I_jr`2`|Xvmy7
zPqN)eNWRCd@rH@9$<>tKwvy?HtcQW%zBaq6wn;I^D{`Om&IR&03`&9B9(84a_N9OY_8WXRw
zVff5>T?N8+dUEBtVcvAlj&Y6hG+m>{9_8^f;2%gNc|N6qt&-m2r1z$XVM4l6MsXka
zIU4AM^tiaIAM~Fo?;$a?K!QZPH|?FDic?{sf~hY9XfKCv-~39qiCKk-cL{53-iO~a
z<72@BuGJ6p^sAio1(tdwSyzh_sm!R<#8*@rtNQaP+2jky*DDiYl`LDN&MMbfW{iBs
zkFYQ6ADh-r_Jr|(alyT8WW1OZ1=MS+Fe}l`W*y(Fkc#2lG;EFLoh5TACo>2q9p18f
zRuf93+hE6dm;NO6(%;{?RSoeU9>2&^2_H&t3o5SdVU!&)pE*zC@|RB+pR;UorX
zP{1s5!dg(nE{}(tQx-31CkeExELQc%n@^B_I%}eO;jylgYI8T#{RTzYZU_6R#Q)7a
zfhNyuMbgk+7$oAU2}?-D9t1j_8yZUPkVjj|CElzzGB9i^-|sjhK-ACevhXtEQLO{^
zKrq4|Y{pQ1J5Lk@Zv|7zY4yrrm}?XT3`LtU*h%C5fePuc^%z;IqV!
zJ__;4=A{%YvxLw@BOrr|I*&eDZX_!yq*1;QzNSNFJc>JHuzFFV7VaFntWWpswKA@T
zDx*rvB-$Alp;~k+V!`kU>f$Yq3J5RJh<#t-{A7zphDI9nG2T_lk#l3qEBRM>x>)XY
z*p7g`AVeiQYyy~Mn4b0AOD_svW!(cNlVX!lphac|qpF)XH8MA$1h!box?h=Ek+tMT
z>mJckE8b&E;RvX}$H)G7^u2k?Lb$D#hZV#6qUiHX$JDV{+J+CD>R{;q$8%vrJTUaffhm
z-zhyQ)2Fx!fdcQ>TZmGQ;5i=1q2-&Z=G%CSnOu>?crXm6+J-kDkzR?j}ao1Jss+{ij
z+s)1X;iRW@wHf#Mu}LkL>hIX?X1DZ*Kv`H_F;F3wtXaBljb<%Wz?&*4+eCH5wK>+A
zp};rqn@4d;8Pz$2A)A=lv{r3Uwn9T)}F
zMqJEWjQBA?@o|jYUQHPxcBGxZ+o-;>USt_$O5h4QdFI|JQa)5n@1%*NSM1fMd4flZ
zcAv)=5vH@gO}6~dzS#@F8SYJMInlOeZWY(VC$W6mf{@$5ON)j0GA9;#>x%llhx6(}
zq4B5NPyWgqg^XfnpauI14S*y0D;|qGYVdxR(AuYpG-Gfhl|GOMXpq;@qu}Q^>&_=w^uOx~S7QE6lgbYox&~%|*Kx
zPp*ehFNPbj{cV|!rtjoL9Ptql>^6d0tL8Dhbuz|f4g>25WP3Z#uIIK=$>ofNwd|>K_76;S!--WG$wd?Oy4(B!=
z4q5wt72k%z{eCgv{dS~I8*ytrL*`1Jh_#do{?3p^s_`1Qmy870hYKAsxLf;F(2axp
zs!2rY5))K$tR_grITHV=B&d!;ArMnoulihA%PO?_bzNI7!>{WW$Q94uh;t`R`H5*a
zM&0uoI>f@fJ4L@+U(H^-?p!g%fXKxbxAWpqaP_ui6v5dUPReOqD1t|yqPI8SY+3v=
zBaT3OMiC*3iAKrl!PqyFz^39rOsJLCwpT)zZm*9nbIQ+fdYsAdU_YIysG)l?H?s<@
zf?a6|z~5l1S*dLAR&~mtwTDzy)-D|BH1ViLdXO^j={t_Q!F!s|sqH)n%>Znd*3{CP
z-c4B51H_<#(?Ar4Ft^oF=Fp-7>XJ=CGNECdYS3Z1E@A7=es?P#rW4)o{z7Wt@A78;
z3myEYD&Su?_L%+vX#7J5{}E^Z8+GtM}E6>g)U
zrjVZ|Z5NIr#}H@6v|rZKfL5_;|7gMD@k0_c-^__;ya!(ZV-I6+<0oP6>I6iaU$-)Y
zCW17CvDpKCMowl#)g)23PSIb+@9n6v85g8i**|%)UI$i71~`4`u#zUk
zcX~7`BTTfH*le&|+CjcSIaldu#{7&?9X>bsP1!{KW9U8oQ5LOe{%ZxEem`yb1LulJ
zEqunp_tY79Y|7%;u(Jf)^lWM%|&iA
z2x8rz&284T>fUvXp&<83miQEDmbrm<3Yk{;&1CvQZdGjYm@X-I^S4Ld6^Pm+DaXHo
zZdrY@TsSbpKYu(pSMnOOBMSzOuABg2QL*JQChvhrKq1If>Kwq7kS>XXRK@$*pmYpj
zlnLr1b6p<~7n=wQ+I&Gq-DQtubJiM>7?LrBr2X=|%@^(ql+z{KnHydfS3wVG^NEes
zKmd_;$B@HtS8}mHOKwEV
znmsS2*qM5`M3ZQ>y!K2o&|OY4P-cSflBNOV6Z%UGy>)bsM6A~>9anZW
zS(R9wl0nAA+SlxhV$={f2r(-Wc8x1fFe}?QTPjuiX$`;tNeV3Jzv(k8s{xc&x~!nZ
zePupAb#R6OK66$$@_LqEtFj13MEvI9YKLkZO0RD+oyb&QhM0Vt4@l5und8N
zwT0P1EgdApmFZ|XCU}AaEDi#o2SRSQeyg6GLrf`}!{SJ~`7l&P$A%}ULhc@Q$MxKR5%`O--ElSU9W
z>VbI`4xqa`P2)gJyVh`r4@Xx^wx?oJ#$zDN(%)m&+sz)J@15(qSLiv~m%g{%`K`Q4
zW5R^JZR4NQTCC};G{_q_e^^EJB2y;hNsHy#3RLHRyWd;!kHK@rWzM@0aGBe(&Hzef
z&3qS|s_r9}@!7eaJHGF81InPuH1Mdz|9PzP%d#`d7Q+?Pz8BtOdSbm4w5JnE=+0&X
z72Q_0X0P{5xW#lx)VBJ5sSAni>3XYWvfB*nAf?vpm6a)zr;WA+A6c`R@|e#R?m7^F&C)jS=Ov*
zT>xpuu&NN&vJ6a!p(H2|wd#*@ZxL(Y6AI0P3I%4TloY3kkA-zGE~*ov0AdWc5qc`R
zUlqk=R*X%{Zh5nH0ZmiQ@>}qCi>tT&4kOxq`rUz=?(2uD^d)jMVrH|qvS{z(3b^0Y
zioM9hlqH`?!yyS_r{56We>PWfy!G^N(DH>$WFVTUnteOU?q2#p)dPTpL1z0GQ}s{v
zr2ocL{R1`gkE!~H1@&*7s{fSa{hOxhzh2S(%Tx9Lu%i2ANd1rJ?Vm!yKjtkX0+Y$
zq}lY#e>^rfMN(PII0K;A8T@PHKJn3!yC>Qa
ziq+HebNezOQkv#%^P$uao(~_MzhYtHhbL!XMDb$@T<65=@kSE?;f-Mk#9X_imHFtH
zYzZ1!>!{uu{8pDhrjm(dR+v+m05_M0*wwf#7koHn3MC@SK%WHw_rvqQz9sV*^wHh~
z5gYJ+g4!KHnrMB$%@HCPGOTc<7a%mB5YvpS7718$REAIrRmpGj$8$<<0xA;mTdT6W
zD1Y|3{>=03_CdF#WH=QOHVZM|hJgDWHTDHKnibk%Za5b@`mu0L9
z9VxglqSScT^Mex<*SRn_qXy_0GTu?^&efKDK)Cn3u~ODaDv?$oJiI$oh=}rnMci;G
zqaw4};xehb@7zbqNvbi|hb?R9W+vy-YLS=0rKi^?f@xG?901vhxSR~ks6P_p*rK1X
z$)W)%fflRZG(b>}lMED4kgU(pl!_N|!^*Agu_8tVM^4LS?j+lu>JboJ%m9w#e|HC2
z4s85lH;4{diYI`SgbJ4;6Dm)QU|zSFe^fIklH^`0(^)vA$Sn(39^8Te5ur;rt@Q?8
z$vC&t^Fg>de#6$t*v(GC){s|jHp}3BDi&`j!#a!zRFxwfpBE%U$CqP|0DEfuW?BAt
z;a(Qb?aPpNB#>HqS$za(xY<9;E$%2Jr^E+u=mpZ&+S_Fd;F`b(bd8ub%twxL3*p;E
zZ$iLDGE>FS2XyPIQ3GHT3WRO`0Qd;o*4d82cuhd#tetP2jRBVzJGwG$+qJmb4|u|V
z>E&=5qp0IRH6H}4flc6tVSjbW`+j#>a)u?GIC9H1ljA5P?Dh8WvFrZh{dyNOjxGcC
zM3!L!GEB6@+oQ$j40jf9Yx5EBc*q+7->F4OtlC@a_zH`&>hy@2FWZL&7UbB<_8sBz(H+9UY7MEZo=%2`~zHxJ(x4MeU+!1qqPZvhT$a3Ak$tp>jbULftPw%+o}Dq#?ig6LL0Js{v8w{INjXaKyxV
z7huW3lm<`Afg;ShS9@i&V?FNR)Pd2J1invhM-muov^%(c-!Rm7ObnnB_(H-dPEJSW
z$k*|<Jj
zLzpZff5S*^KO9&Bj1sg{nSDets{(1U%s1U#Zl>mUM8}!S^fR69+IcY?N?}-TK(Wv5
z5ij-_tk|>*T8Y`05M;!uj*hk>0926M_Z5!nD>mHg-w=;~CMW$mcn%{(1>DOvHEM4D
z2PKeP6s_OP034+>vPTk>$SWt^9i=VmD80FYl5{-*mg-qW&JHnzjsoV8dMS($EG%????Wk!Xs6lQ1LG-)4juV#84o0O%p6mym`<$*BG5
zU{lo=zA9*2q*b_!ZHzs((j?$7!bI34VBj})uRR`cXd^ZmH&*HJk25W=+z5pMxUdv<
zTn#_dN=w}GX~wnQb5Oa;NCR(-CKg!&ye&>)z$`Z>V){qfsRI^#M7XOEF%ki(xvaBs
zhDKxTCWw3pWqWSA1jUZsMor&PhtdgN6pZ<_N846<4PLDJOkJS)v0{;aE2&yGX5hv`
z>7Bxr&7@}Z-=aEPR_lV{nXE`S()0M)%TG}6heGhvV5CaHO)?C*@C`|#*|h4RrFUvnU0PCi-@rK<73M&fHo}foyX(JjOXUg+3iO827;}~
zGk2iVl#e}=FkoZKWNhX%;w@Y){7NW%sKPn8tDlyWO4E~UrNT{aq6#f7Rq`oI32^!?
zrVkN|(}|;DgDri>ERc95ax#x(g=etOT$?B;xvMv`(16sQp^}Lwj?+mA9OY3IIn0Ts
zuyNacv__6ge4*+LE06&JuqI@uN4}DVhybvet+|0
zMYf=(54mDUm5>1sUABC06*echR%o(FwaP@9o}#kj{H_XZ9|-fG!;PE7W+%Z){t
zdtQk4jq_d56-Zce#eG?yIvjF4G_)N%eg6XQ#giuq&X_2Es|#p)mv3qSk(^JOo2i|9
zqQA8A2WO&OyCDOa)1jm{hJ)q=m`q7AOuDr4;q&7tDZ)v$C*EU2!ugh+{A~RA*fLP)
zo6HCX&FhnoU2NUjpWg*bz#eBlA?X2_A^LLut2|}?7pHmsXEx#=%JU!L=U2P_KZT#n
zf5f5xK6&~dH~H^`pZ_Nw;{QGH{HMJ0Z|Ud%RBZmoYxqwUE=DGfzXXRlS6z=@Z^7^e
z>IA0a=}FBKRtULJ{+6{WQ?rRuv#ulU&!23b5k}og$de#3+bnI<{Bte`e6$#4IGfPg
zuNZAK73DWx*XJud@o@>hFdd@66+*8!2d@OxtUZP1V
zu^HA3^^ksZrN8?1KDVng))2YyopNjdzrVfk9fG1ucu$Ho{|x5Gz_&dR5{`KdjC96@TfIX^N7Yz08sHqx~o{LU!Zk&`gF%pZJA>7K-EzR`Q$VGhXoQ&Xl#_x{SfL5E}LX
zlOU9J?l$4}^X;>Vhu&l@%w0(`RRiwZ=Opett1REY=vkA^To2DLP}Ofv(`WGoCPCj~
zpf0%~8fQyi&E`Rd5!+#`_*Y!0WT)Fu#cXCqvs-gEfHw`Y!`7D^Gnw*hju!z4n&+(-AErY;Fr0Xn=D$%ZDV#I)
z6i?pKnMy<&rfZorB8sMhClFMW5-5Va#kS`kfK{{iS}|_hIqEhDDprg`YU3{yyTHW@
zSF(-uTmVZ_$f`M8t(M3M&7(UM%Sqx;P1iy^r?&sh;d^B(VbDt()ZtxoACmcT65yF%
zhv506l*a4_xCXeaRnKhMuqBC;y}7(Qeo7FfJfP9avi-2st`Kq%dk6dS^BjViBt|sS
z#g8MV>)$mkCu=29>MY8O+{c(?%I$QET^IG=USwe2hgiQQw+;2-8@=Be8P>YQPy8}N
z*9f%9L-JeSW&RW(N-AbQ8~?)V@B#arif-
z)L@KPnd?rC8rIfyhglW@(WAkR*GMni@*Oz9!AO#*9{ej4v
zQO|j{E6T93k{z{w1!I%PPz-+QgI;gj`+fymAGb*~EjpkH&vpQbKoR}9kIu`dIT4J-
z6MWGfz6+68&pG^X-96f_`YZ61A2-D#Sm=>CR8$&wm1hmT)*`W@!1Ky2#RqSc%U>LZ
zjrXH_C(FSoaJBTI>vM~N3x0N_K2CWX%VayBBGM?6?5dO_M(_}*w-PQ>Hc?4_BX7t1CRq1}$PH4Pjxz?5wAyK8&Cbq_fYHP!2P*oW6d
z{Aa^yQWV}bvQuH3t);n(}09?WR0epsSh_EKl_8t0!3s;KsqK&9i~hJKAQq}S&D-x`#Y4vyn6>C7322h}ulZ{ZAfzZP
zNDuKozMskto*$=^Z^rbKcDRUG`i9V@{zZ8tbjfSZi{b83O0}gg700sn*#}ljX=wv
zlv!9dq9KZjO@=Q+oTZgIHpAQGJx>sNRM;BJOGuCHXt+|r59DLo$r6C6_s@z^@wCm_
zuU(HBGk+03^q?Cc7OjfU;w<>pm7)GjG68z-YZj>zrl8TZ&y+TyEml?J_sr*sy=?B<
zac0wMNT&aq`@~WnUw|2Hzx}VTnQR2GQ#%fw23Ax=kEZgVhBqpY!K}kKDdMMg?RiQR
zSv0}lo)bTk2ky~pd?Jylxd`RVZh(;Sp@IaLQb5Ht38ZwCMJ6+NT#I~RBRcosdO?0A
zXwqX(VR^a(=R+tSg`7Kv%US4iGZqG>qll%Y#5W!DV$2$}T6M#fqQ3P}5g!XEDWmZ!
zWXSa_7JCUBXjZn$Vwd+sn6W*XO)b@7UY9)>nSUINA*>l2Mlnoo(bPth87
zoH@TM^RpJ=G?+qFRAIU#s8BYzD(Q_Euc}Ich=!9~gI8m*@Eh-@O)cZh_
zLJU$T9?O~W&TDLWtf-oewuD;CM(hvJyDe#(Q@(CFx47&bII6dWYD-9kLFAkiu(twh
zylH*BcLce&n|M`djrl|u%Z212wlmUaj?U7fcnI?D#8-23;T!-f#ui=u1zw>FmJ7(K
z;P2O*Vz7Tmw!ySPgF9Q?^2?nz(BLDkIVxuO>%uKR43}klW3qjc?HhNB?wOYTk)gqf
zP>Ke@{f^%xudB1?LY{49H<`{o9Pa$9!hc9=)NV#
zvn_C4D)Y6C
zi;&gu#gpL~!+`{Rp1e0IaXybUG^Hl}IzTodPh8xf4?ZQ=s-l~z^Rd|xFqV*D{Ktl3
zmJqrBidXw<&8rQEc8{r$THG&|4X1SjNa2e=<;eQqk=ihQ!=ZJ`+f$7jdveN{h2VRQ;Ye)5MM_S4Wq
z+3xI{LQzy3(brLnzAdq#5H06z#&|Mg;Yd_A1&@{Xg?|#L(G>#MASJ1JjgE2YsCgk&z|ufl=a0V1EUI}nPwI{WtxuP=IJ>#a!2W_plX%^socP-z`)uO@MBQ8
zuJZd^rUFN*I=Xf;EFmc(qb+mf@HhFkFwGa!sF=OZB&mWjRxP0)TPv3!XO%^nxdIMq
zF!xB+R&(6v!071#E<8PFE^00a4`I9)_t&)%4#653%#p#D2Tg@+77;b9ufZdm9!(Hb
zZz2bBo=Sl_Oc{Sqe$d#npv*-kFL%sRh4;v0%wX5ai55FOM5aQIWm-6#J86c%>egCj
z;hbheCf4fel{=JZuNGc1VoT4EYKXA4af>R{;&;##h;)l^AV!yC$tWI+5sG(uOH!Apyt+Jw*))sxJOp8SY6
z4@`pVbk+LI-nDq$=DHU`j|-s?P1M0fY0G(vYPWa{aqd2?CyEXWSm%fH
zlHR34DWIG-KC~>>lQYizM#3S|)Z>FObxCUQUu3f4cGhdMQsbxIRwakoqn8@*H4DGG
zi+)KoC03=%V0aNw`~qKbHnFZEoG3|61%|}fZ>w&eSGh9n%2`al2$1^1Abir+mL?;j
zF=V?g`mc3bQ`JH=xdw6^=S_PnFnw#DtD$+W$9qrfEZbcE!f!t(uC<+Hit5sCW#s@{
zlSPVIRrWexTr3_|6x5r6Rcb$lt;0gL^1fb^a&iMzXfIynQ~jQ@*}iaX=j7!BF@1hN
z**!T{b`DJPKtKe8
zt(1b8qL6&QxcyC1d`>dMHBj~uDL&mc81#Wfo2}cGfup-?P~&3S-hzI(`gP#Z>KyJ$
zAGkq{uC$Sma_=RBUL?@sxBZBTai;j;Etk=xo*;#Q#vXXSWL?W{8NsV_V575Z7~H8d
zt;Mdxc3xdOt)dOHQHQnKIR%dn7d4`C$xPIi|KzgCNAxX5Q#AOTsg~GtbTzJ)upT&H
zf7-V?GC8X-pDqRSwrVP+C=r+b+3ZB1#1}fMlh=&mez&p(A$
zqZ%rYbbp{V7}glZNyWZ?C=!=m#k-C?v&&0GvisHAp)A_Ek
zgd((*cfziA(`2!{OA9wuH=x{2{&(7gcas
z;2&`$W5gPY0xc_7!y(_B$dWp;ST{-!3mq0EO+0DYG(FGi4j|DKg?KG>39H$lK6Of#
zo=M_EK3lybamanS^k2|9I7Lef9qkP7o^xx8y?^TB7W(MoCh@Q1=|CR1O~-Pz^$+-#
zuu)y#lDiVQH6q)kREBl@hB7*PCzRkR{~5Q(DI2TBG&Ok^BqX?=__*DDMVgP6PzQCP
zET6&{U$lXE?D$k|Cnt*qW~_~Dtw9FtmZI9+Hh}GrPZK*QGwCWnz6<#GghE{fy?-noit6d*+G#?I6uGkbuv6
zSB%M_8@0ycJ+MTFQ4)>;BUm}3?uG;v9Zbgr^eBLL+<>+
zAo+U)&HP6w{cn^z|CEmZ|4{DyDMJ54?l3a`wKGo!RIP2-o4yS>^S$z27cebUmZF89
zHXF%cqN!^Poca>rK#3GvJJlJ5+JC=tvC(z;9OEGt(M;TK25ja>9?yfD9(TyT!v^m>
zL%hf3IHt0%!OBMy#=b{(e_IsT-#T+4@-GIGH7XSYo{&FgIG1O>a+??);6Cb9xT3u5
z>>}VLB+tGlq(9Dua6|0XaTxRKp74N6@B3uGfWJsQ*cICC?EsjPtKol%gl$8f@6QjRAMf%~4@
zZ+}wbprH=gIxVrf>O)_7Y$Qq|gGn0mig5U4my{3-@rKWJlFFSmW(D1Ap!|KHPNN5y
z8`}tOsd`M3eFnOrJyfLeFB*j3>7u`8wHt`yT=Y9UszOMYpV40xA4H7YuzdmV|
z#x7Wa3O=L<16R!SQ{OA@p)1Dxm_;l)mjS{l+SyN@tTae)I4Ik^w?<&+;_&zp0ccZ*
zx-OkBiQ_
z`t@g~XHa%B%e@5YtIAxCYytD{LVy&{uO2u0s$_z3XJxuH*vcY6eSdCxn1(*KzJP?L
z-Kk2kH5w#m^;OoWfBb9DevG{4f#h+Sk}EAKE-V*MT?Pip6bvpZ%Jzr7&+qx`;Q*$n
z3n4=l=>_7X?NZSihT=w6fBirE+CaFsdOnLvc3^VZZQvgCuHJ
z@&@=agAt;ZKh}p*;vNV6B|_h4On>zRrs_-d;rOny(F>i^k3Gsvyu#l+;09U=Pa}FR
z)E5Q^s&qpp2~$Zf_YN3emKjZ<%b
zH3pLEPRw1vxBwGfDPIlCtv3U))&{Gzc_4PSXtVE}RvmnEtVbnwdVSa?i;snJS|l%E
zoKB1OeG!EODT4SA>}JydFt6SLlZ7#gvb_={Vo{3JNEeb9+yKSdjy7&#s*MQ`=
zchfnPfOV^3XxMN&m%z7GZF=m`u~>*Dj}2H>G)c|O+-Na8YrfGKltFa
zn?_3@P!2&zmTcUzg{!XnXAEcR#d7Z>KA(q`lhbt%d1eo62hKBKkRgRJsAE&Wed_LZ*047&;8V@d)wSq$)HT4>svuLwRe}&M_{bccyh2@};d-UBYMsd>tc5IZHdMKzI
z6V^Ax8g`!AQC6XcT6kwVatIOpnnHj)nn>*H7rY944HAbuvMmi!%c+#WJ!H)$cg!g+
z3O6kv9ttY^`204d(C!Y*Y-WT@UI0Vq2Ao0B$fq-P67yLdc?KpQm5edFb)XF)YbAGg
ztM|+UDcbv)k%KE{-Ef#|ZIZ#ng2KIwa&c+ua>hf!#6`V!M%o&8@u`!FA;_{5X_<5E
z-i`;s(~F7ulG%s;-rf`2*hlJq;dNRnSf~6@bF4#mIR27rD4wKogGvUyTQGQahNJD4
zn)wuJ;^}HGX9NRGK$f-0HnSO5EBF>1Tp0mZ4JiM5X3rJbUi;eTUlewnbGmHjobc{0
z7cm-+1imGwXj9N0&j|qQ02|<_JxTf_h3J}Lr0lm<&Ybs6W1$uL8n0=5#Kw<2u8Ye0%O&}(x<@<
zJ$i$Z{DsdC;@Z0^e0>K+ZQ;37JN&kl1In$S<}t?*Qfm!^pTNtQE^4nUAAYkCe6CHffRKx9vJY5;VB9L65B1aTlPb^ZWy)^f%dKlU|KW|SyE*@l5H_<~q
zy8vzy!!U`FeU9Qqu~x@2upT}@E@nqr`V|)Fr)#M_IJv5rg=k5!Ez<2bad7+dY#hqY
zRibthWTnSEXC@d@9c@;^u+d@k^2_aUq%aN(&=v{+XCk3#1r4V>07Lg447aczstrym
zx2?=~N&^TBw|^WEtoGbJ;@+%uj}{}j81au_o!CKGciS9mY8SEl4FYM818n8$S7>ES
zAc$>};$Z|=YPlyjzekw)1o8R2z
zedRpYkK-rEhF=Ba*tU0%CsVB5wj5@+BEogd0DSX?Itw_A#v?HK$Ug6F`<|7~{w*I^+VhH@ipV@pZH&&NL$-%9_K$E6l4bN{0ATVMR~LKPO07^F?1UUCP*+S8?D@&dogWH>Z?@oT-r#^SucR`AM1Rc4`)!8@52^*u1>Vi9I
z!9+5<#3S8%eVxRL(k*B{ITM1qu1tE@C`?{pl8pdMJ(R7UQ8FmVE(!fU4x;Q?*orVa
zGmjC{2uMbbk-(T<*cO7_4j%G&Q~hnoC&<>!q}wc_{S3;HZg;RJ6C8
zlgo^L^E`*2`>mVT^yL@*c%<0=tZkXk)pawZfFf)tK2C1Q`Y`%8r_bm8Hxa8Hh;3jAL^VZ~9KoB{H+sMml`Cy#)ENKo$7?&G_B-;W0NG
zZ_0Z=%6~sP1#PG>JV4Nar$J#oPQ~Fj);Rs%tb}}+yZaQ{@0oxo^KO_*AB1q!sSH~u
z7k0*RkuhFx{7qX)NJn6$n8Mt0O0s&Y_9tBgby>~B^gJfmx8DO#p3Sy%-G&KTr`t&p
zr+HnG7UD*zDJQK130B&8W_p<`)pX8xZ6$jH<@n{b-=~)wD?{yQJRm
zAzt=AThIIyY!4X~=t`oaW^dbVEEZT{pIOG1kd$?`M@s`8(omP>^7yYL&2$OElk4IS
zRnuZ+Kp~lbR^U6VD9vn|2k`R&S=hoXbbwlv0G|f164R@))Y$sZ0#%7|N1uAkuISKY
zNFFtT`zrp}bj22#=BJ^Em>cW>I|sxg+t
znirVw#7nQGJ|TUJEEB2;_TgMNm~!|BTaXDHyiijAyFwWY2d|bO^8m1@7Tfg)Jg!{;
zcy0|z6$0?JDLb}yAF$152RY8(Yp2@^Or=*8H4YLvDv`8tHTwPM)0JUDklC+g^h}6-
znw^gpU@08U2+1Gy9_XGxTA(jAB@APbp|+jMc0aOI>@#kF@4uvEQ+=3BM+E%%;Rxi^
zvyE)&?-h1^Hn)I$D}Y%60=TR6SZBxlAFLDzzi;zZdQvx=s-ez+X~Tq4fcD%TZCoo+
zT4XAS7@u}@3@ghE+k9>7s7K6D`yOwYJzud{aMWNHLEjCmB`G%!U>2q@i`+mZl*A^*
zD`+E}lJW2RozhsLz3XV_-+-#e2$PjTzyJK8JQQm8ry(^jU9*@Q?TICfURG^M28=!j
zVw?0(K9x9Dj{v&)5~knOsX#i(9T|^F<0#Ka2U2-5HO>8q`I)Bp
z3MvuFK?akxTcJdiQ_iYPtfb7iI4+l`GZ-9VjiFGeln_kMK%likaD-~Y%jp7G1i=Ri+sI26
zlOpE@pjtw1azAV+jGZ839m
z>^sPx15D^sWcF3OJV<1wnyt*#o-X`;pR&OgV_5m8-D`|8YG~~|Ht0Y
zpLiF4%fkL~IN1M-G8oIBvb;acp|4Fp`oFSyu<$qf#TUHKKF0qCIWgL*i^3C+4Ca1@)jN}GL?Yyur!CZP4hl7dpBXyAJw}4;#yFBuJ
zUM+y4yPzFzV*2JdJQ)mXNoH~Whpof_x*&n>HI2eM2rAt+m1$1c>SD-800GBiP_qO<
z2*M+w^eQMms~RXO&uBE%8Ay^CA;&|Qk#b})`fmj4TB7FL`Q0-7-0sI~E=Lqx3+Ve_?6x>GU`
z*4TTs3Sh65%T5tQUxBY#`O16nvLjx^v~W*W-*P3()l*V9i+mqcPB-O|i!6t^j)2rX
z+WCRx$_N|-A*l^{9R;JXd5J_Xu5Wfn43{DBK`AF)C;Rdq%873R<|z_#5DNk{0^ALD`2q1eLias(BO8
zCf>4fUEpu);na0JHMqFKXmh%Fu{u+E0WEsY
zP*JQ3KVD5IwhGRjxu)5I>nKAqoZ8e}WP-L=s`u@!srNT+0e6Q9O^GY{1$dO>M*0L-X5z^I4{!JJ~Wi?KF7A|zufXIxc`z^Rh
z|5U_@!8pN%)sK}rUZzWa-{@!J1I&&VJm4>n(&_Vu2s6hG8pKP1w_iLc5{o0BW>K8|
z2Q{JtFw4De$vx%bb`pNl!zRTWHWx7i3eam8Dn#FHcKrS>kB(ThP_FWOlebZ&BYozHt8&`>HePUba4cOS1Q7(*i
z7&3HzjO)%lm*qzDgjh_9CnUe8e2_F*k!oUb*qeMn`EMWP|9b=CbdfD?V@OW;?7d+0ZbrIDNsds1H$aPo|7uw7^W
zIvCpPlp{S#MT9HHIJ(P6ylyrdoSJExfER)mf~{I1B#%@jdV0?qC~l!aNRu5GD>B^*
zZlKccQ0FjY-p}Ei=ey$yUsvLC8=-$-6cpKA9f+H2Ru-OI0R{{PC9%IUUz%35><{|@
z|0xW8+>1?mZ&28k6k&M>YFXOPmQ+#0-w{!kg3)3gILV03yaFSH+cpaSi@J9Xu65Cu
zMPu8x?PP{CwlRYl+nKR#+qP}nwrwXf=FL8**4bCsJw0mD|o4+zDqc}+s|&AGHgL#
zuQ%_qJdN=!MZ4-UYRal6u}Q668hyIO*nPBV!z`Lf{4Tkf7%GXpWKD?QAL
znn49#&CsqbK*a)g`R-+#YGRiD82Bbc?^=d&&?_=aY6?N8h``Fr*o8Ao`NQSnJs`dW
zq~VF+^m6W}!DT*BN^vJ8YH59;&n!&9@nz34gTJ+cQpY2goRqndOF}YXiPP>6XG?5@
zCYNZi84d`o!f-+TfTA2qyvsvgk)UR2&9pG%N4ULD^w<|2=n!Pi3aABDEW)EV0?x~8
zeg&Pn>a3oq^ywLrr(h#n!Ci;_yl)G+I0-vSmpf(7KG-<|1!(AFNLQXS_79H1wnM1R
zo7nB+&>msw6sRGi0#MY%p6FA4k$82wZ1;eYTa_>W8Zzr*MsrpsRlqyOOk{J#vN
z-@b~X{@@1x)FJf`e}exSeEpMo^as8&F@9}4{Tr8k4R
zd6iYNEQWYeoPYB*AEA#d5q+W6aqrMUKWW)WSrfB}3eslLv%#stl3{v2Jo3@Y<)NGH
zyV`ymTbeb6PrENyng;9J>d`qo_&gnpIZc
zYRcbTFL3lWvJ8NrmvPNMz`TFR7Hxg{>SiBvx1tDrDaxICLz~l1N#wS5{_X(QG
zqbkaU{AH&S?j@Pi=N^}n^gZQaHT16-pD!n81J}jIdH}5zPwSD{2fR9GxYeXkKTYt_
zS~n4@t{_BynWD6|8&6LZoq1_>wY+2MFg~Z^==k{yrbb⋘V5+M(@B=XJ$L=a(U)!
zQ2V~Oe1zdAY}VIRiU1Oa!&}z}Tzv>?T}@dyW3p6*2bvFCPX^KFN0b7dCngI4M0X9p
zyFc9$&t@lpm8=i4X;LD+6hNYIhOD-f7C_QgS{#aIU-pE1C+c9`HmUBLI*;;OlUhup
zPt?~U&2_<`050|zgF6SYZuwT53o`!1Iet)7G*%)0Yg0=2D>Nt!2%Buz@B<~iw@|#-
zmFUa^y%%b{cx_}QYcDv5ivowENI);f!J&jI#%(1u76&TnRA2c`aHewPDz}8xMK#P!
z_3MPDw3uXf=A0^_;Yty%7%GD!PZ#OV1^zH#PFL&b*-GPkdnuU;&-eO#a0%LPT8lRN
z7%{eK2fMKbNKoo1E{nb2CLdenkQ+Cw2MT!9^iFGn;em6x-`?N`bjOLm_CC$dBH)31
z4+dYx+UX?a8$?x$YuR!iLEt}$u|i}+o$kTR)JkXIvm$bLBQ@oi!EW}?tMLxVDuF$F
z=`zSXe?+BzBklp!fm;`x6d^MvbQ3BVO?}I%=+i{w&U3QI%iFA}xdBQQ8qs&}cW>f!
zpc|jlyzTFSf%EO=GRd^nvJOozmd+tmX+j!|t@174=MUsU@0Y36j?tQN2jvOu+7(U7#Yr_Iojlsi8r$^R%LMGK1p~-3=TeV7z!LLdx;kh!c6?@r0*Jp@Rl17OLHkd#Rnx1(TH=UKpUbEM3V8Fk-P
z$ocq3_e=X!YNCxn-l8VF6f}I0w0R}kH2H3dL~T{~T}C{^RkDANKsJI&8v--}h(#h|
z2c5W@Bua2?d0E7aNgY&y;A=?Ell@*9;u_dpk=X(k%j5U2fR`0c@uQj9$t1}O8mXM0
z|9m&-cRg&5TMVo)grVw{q@wDb9!86Kcij6`25r_Z3y(XWIBv|?gDAd13rOGVUr#BU
z>;oPZw7Rh_F%`{Gs|%Zmuwg9~w!|^nZcIUo7uC`x-pdbC;h6A&6RBl(^Bu?O+}`xR
z>>&3J{Riyw^tZ#Nh_+1CQN*q?QgnxkP#qaeg%!~fR6g3Zj@9(%>gp0O8$SvhrPQvH
z`j2vj%Yad>*xbh445j0gsdL8TWn{&(LV?A5Uj?wD&f#$9A>(mcOJ!5x(Qt8rFg2y?H*qjk$1Hqf$M+&;K?>3Ve7z`}H8B|IoY#bQ%!ynQLp`g**DK
z%p9YL7p7VF$XBe0S~FbIdzzvb&c$4bPFslGSP~_#m2zJ3a5X76c?j_5gAqT
zs4-n)upt~!5HW00B4+s+DZ=S$oTX;>ey7v5ac^ftcd{gnsQ;Ly_qXJ6;9m8E8a@acH{ue=Bn`nTK)j2+63Rfm<9b*GcGK1k%P;D{m6V=3^HoBNp?>ZT@zI7
zO1V|zDq01vdK9L&uClH31Ma;_5($VIHr)s#w=)qrNIIp;3mseHnWa|bdpY^&YwJv^
zTb_5kf#Wa@lccV5H90o(^w`c{rDS)MQ
zXxHOd9Ghc
z7yX4?@E^RI|9f2UFQI?`@%{XhA;QGS@Ndz-`md<*9vf1{x#nk1)Lmi-0tjDS(MoxS
z)My)XgTleCcmV-aB1euGD!&!-#b{E`s5N1FY
zf%gf?zdawE}HtBe5vO#ohI0&SLF-;gm1Af_x`@`eF`I;LR
zV8Fl}ji?{sez&cJ>ZgjgY-1h3;**#B_?tHfAgu1MWEUs+$E}_Xboq0x&T^1zS5SDv
z_p}e2t$K~k4I17&52Nw9?`uQaFACy#;pfzT`Bt2|k=v3lQUZG1wNFD*uZAxT1BLMf
z!ZQiduxW+r;uL4(7qT9Ti_?}M$@JHUcevOt8XOE(=p9mR5a=Toi8Jp!kC
zKL`(JEj41->_*9)B5K*CU&3{y*usJZ2?IcL=fyx+mQWhagD|Xp#>B_KNF@4xPyhbl
z!LXkcB@w?6o6GExduOp@zPIcf~QfU(uPtz3@v{XqICH*I9-hvoOVl
z*Ac$`i~;%;jt6(NwAM3$8a-N93JC3B=#Y{7dhfmJ3J;Ih{mL~gq#~40=Dqg(0}M9R
z3cdiPiA>>bwpk0xBr_96R+!|j)B4nS92{({?DU|Ke$3ki#E}i|$$WaLDfrGjl={B**uq3;K_nT{PFrLbGFQqy$SCT)X=kc6&}JN}PAKu4j!K4C?^TU2
z-sY-dgpCvy`6L<1@HsUy!hydqa8Ztr(E!(FW~3O3wt(sjMMiGALQ}AcYI-h3=WSZ6
zE1==9PL112Lck~^iu4A1AQg8|YstHyhNDbTVrn>=7pn(8b~_BSYOd?bE(>F@2rnO_
zTa0EdL1bk#O${aUWWB>!(>1XO;p)g!gern2V`=!v&~M~Xz$!g|3JKhe+-nl{T60EO
z>ti(71rkrms})(OCdHh53#p6@hXu({#megLd-YAd?AktG>n1GNRD%g(;82xwb^j`wgf~i0+iU7Z^-&XU5v&EkK(bKY{u?o41xT>
z#^525W9wu7MK1nC6?rC(Dfw4e9v;T0QZ|FL$(oFIu64J&If8;nM&g`~zb3j{EHMaCW&h=-3+I^39)y3meJb+eC)W&Q--x;{Hz
zNE!k}7qKUb)#^zlaSVU&+6gxt*6Mkl@5h5&W^jWZYaPE-i64-6CUoREcw7YK8@as`
zc=lW`aywdf5s=I^qV>#UB%?$X--jCgei0*c_}Qiz2bYQafwAF
zc!?9AoexY_56LO<@xn`jy#{UwF@d0zx)MLlune^7-oj;zq=IE*k3#`2l-PTrseIT?
z%mAs;CB?K)8jSEeTuJ=S3Ylr>vwJ0gwb`abDnwcyD;IU2#NteorIE~m9cnTd&DQqP
z?L#c0p{QKdX3UT=D;8_iH)m3oR7ELFxl^o+ihtFhgX<{*4w9#?oM2ixw7j&@vKa+ikhW>C*SAinqJTF2^GJ3l64
z4CJ-bfkeN;;}6SdVoC_UANI+^H*>((#QB*IPrOt~uO@)opMaRB(L7wb(w*|B?B)(J
z1@*rWhA@lFE9_|`C|lb3dF->`n2G%~8^Nx?VCgHl@D90`OuPn1YR86ol)ooN%Nqss
zid@}G>oT#3mP2ed4Yro~v@3G(>eT`vO}s!Mx{sCMEa?5Y&Da}hP5bMFM0rK{UGKC6
z9y3~{e1UAqs|+^Hk?;(6Qr5w!grobi?hy0#2)Wjk9!>P)7dgB)ZWQI2{u*ZXOoc5~_%-R2Wx-|vve8q%ALD}n(Cp3Gz}StdE+c#X;rk&Kz*LDZz4_p&@<#?-ZXF!aK
zW89_b*|I*nu(`PRfG{LikkJTOp;%G11{UzYFdNSkmjr3pk2GHTy14Ar11`sGiycp;lIblFs!~51MJu(=`>Bq8~c~wiKt^R3q-9yMNG$z8DW`J{i^w@)p-1C8M
zUw^{qF9RL|7szG19pi43G*iUsMprOu?H<>~2s0S1)^FjFawToX6VFC+Q!FsdZWeK+
zG`3bVjR*-RH9AOE@k3<2h@LLJSn~x+N=0iySpKU1SoHa8t84^MH5*L!)~Zp}_It(I
zhMXV`1sBZs?Hqn09TFt@WxpNxp3{@~La7oahBn(oN@aRmzj)m{I`doCvspegrU^De
zHUi|KTEX2})k_%t#G=h8idro&pd<^`TU|^TNk*DJT};?9XH~L3CI=lRXyxzDKoki0
z-EWt5o`Y!D-y8*a0`YLa!IS^8sOSqWn^{^a=9E>8bwyP#0)fnbwXu0Xno6w!qTp)X
zMV}$yp7xGV?w;IH4Ztx>6ZDDA8oiK-Br*2)1RZ&<+2_6#Aa?jRv1`45U(vlv-sg!b
zS8DA}xs9LF-N%6p^wT1HeQOQm{K-j!&7yjOOFdiP2R|ILbH*$0Q~gfXxV0M^hxJ~H
zG8RRYi$~FR(^AH0bbj2o1P@d=JyMkakZDY~QWBjZD}e6=BBBN$@=&t5zMv3#I*wm4
ziW4#z0y@vlJFeUDtnup?Ll@OdVjUmdnjdSghFg
z%n<^TrQ0UT2Bd%$=wzsSvrW-#>;vcN9IHK0z^xM>7nbB#Ea8A0@FlVH8Ld2-?B0G;P
zWwo)ooRM>lm2KCdAzJpF87WDktDy0BrQ-bfzGdYqd0~jqw;MY`_^s42A9u)uMiaXV
zwX~$lI3b$*xpk4Ntc9M7PC{BG%fNIg_G#Ob-945)f72}Z@+_UuUovTT`j$9>Gt-jf
zAuUg$8>%++r-kD-2JNfE!dBvYlinl-^6sK(nRl9;kp(NOkCOR@e#9%FvP8>
zaJ?KP>uC!PJ}Z?86I2>vQX0Yfi`yvn7ZY?h}L}{pBB=yZ_VpD%+oI$Uh*QiJ5`p
z--B=s>-|Plku~FYa3D~qmU|m&)I)3((KCEh5yx61LjHn=P5RU`7J657&9-`%_Y1~{855G-!S-HdZr_<2f
zGcc9?VMvZhx#PZ4fD7EqsK5Zb1NRn3t#n0v`T9*x7Jvwl9=?t+7Y-;0sS8}+${nW+
zP7vfMyZTPM^|GM%LaJ%b6_j0rcP%O+5yY9$U=S3B@Qx$e3o-N=l})Q1S7YrNZprgIZfF|(nl0qTn~gfjC`V0
zQ0n*<*}&PXTj+}@_6^A{<>AWY?dnWtIr-`d
zKwwrgzNYhTvzu%m1u95Q6dSnWL&&=50Fw{*U+fYc_zwd#*M1jGik
z*lCdrHTb;Q#mweDMzgWxx1g>oxYP1AZ+~Bu`N)js4TYn#x?y?
z>ZvrYi})8*QYJ{p#dY1K%yM*fV34;a_3aQ$d2eEL4{48VNjHddW&tNry&WrdyysbL
zk_o0%FAE6^xuaExTcUiR3LQ1c+y+
zbv>Rhuac@JClOOH2o%0K-=#ljkKqCql0=7@7I!~Ipa}5v=rV+Z+Yk_P#K$n<40!!H{UMPqQ;x#I@cim)2Pnc9iZC735!W$ND
z-K=nZ>HIbI`z%eJpf$G#pERcTtAB(lbTZ#Blyx);1E|%p7XUoijTbH--)!HGm1=w#
z9K250iOc{M4Vw#eQ7tT5LS~XgT>?e2mOY4Wplztk{~;TaVEdHRYvlty&}XeO;r<8}t^QxI)&Vy`~OtaZ*f0Eyiv
z4li?B0j-!tk0)c4HpP0e?N_^zaqsy7QHceAl-j!@W1D8b1=?wNpsdfa?x*q4b<(z`
zKD4dI^$z*171(|F?pR|Lx&yabDN{VJda0vizC3*jBJIw%8~2JdT~28I!~1aBIw`L~
zd%*0K#1v%a%t^We?d$T-`#kd>UW-kib#=Uc79s&^s9jz_eF#Iqfjqh&5tDeNVXkz!hK3SZmEtIBbkuoZJ
z&FcsWm{}hyJWEV%Otg$KOO=_~pp$hPw6sy;o6Y{Vqs76}pa4B*Dbp%>N|NAVN((}bTjg-w_Di*WL#G~wNT=BK5ELZ3NFUXR|y=U6!G1x^6Vu0vRU_G
zj~D8SQI++kqIaQ93eLEX{nP%F?Z*+|RS31TSZPI6_KKSWrI1>fNFBRSp|o9kIkHuf
zpn0+&KQXgq6(uLdW)-Hx1QLlX!S2ElK5qC3k;Aln_vBe)7?9)X1Y(Hw-=!kEyes$y
z6%ulZ^&vU&q4o4ZFa*S#`=>vt!s@BRbYv4rLd;$AYLzV=aKjm*Oc;cbp&CPVe@_dD
z7(&IigEaZv2<9xA`eVHhAAFbNEs1Z1Gi4`O%|HLT11Pd{Qv8rpaVk)^m%_WX)!=cn
z8>mYw`xeZS^^*~R5_aX+(wyp9K7}j`Sh6$YYcL6;-I@1bke?i=VceNwOufz5%Gp3F
z_4*LZ%L0-0>ZJ{(ylD~}%A}oQFa@)eNVqS0f_T@dm5X7brj+~zs
zAesI%70XshpEwH)bdX{;rII4?wnh0+cs=a$s0bX&27^DLQmd9c2Bq+7I9`6_1Ai1$
z(QnzPzM9lu;U%5q9xk$Y=v?Iqt-zm8%N^S>UtMW6HFF%_J93HjlRngHBw6Q{CoC;w
z%Y;e!!uGa>VUdq49Bx=xK=Ra`iGo6P%Cl+l!C^v7;257ZceW5jM
zOrf<_e48$jc(KBo$cJeRInuLh%K5DtNxZaBp6p0lk3wxYPBr+LcUMq9>p{0xed|7v
zMcyXS5HxJMl7}OSY7B;qBe^>bTg1k3+&ac%B4{}pKra-%VTEc5)6%~6UZ<;jsiSZ!
zSXhkUCu*iho+tBRUg7gW(og1@9+h&ka}QO?Z0658kn&rMDx>tC|!
z&XDmVz$r?uG@;N8VBh{*;Osy-$Mo;CmFeGXk01MLk4K}ODu0IW$S>@NYrUB)CmFJhA679N7DscG0QIFs
zgo7xa&c^$lG0CM>!tFM^*O
zWogojc(k2To3z)buaLxiJO1?jdE8`={x18#&v$L2D$R<~kVoNz4;Hm4{yt0Z6y(20
zN^Td}E16_pL*Y5FNqf504iYS?P915n99VXLk4rMb-c0U-V}H-b*DQw?XVa@gfgNd*
zCN6DsCpl~VDb8Kqt7aUl#Ht3VPs=*UVZpFG4K`8Y)iUJ5a{GXz8iG1GR+`(Ia|nt(
z7fz0XM$Dwoa#BHr)>5egKh>X0OJ0cPlU>8Qg779#0CGA8rf29v>CpwoXf}*amn0j_mXc3z~e|X`_E6!1l
zU6B^$XG%s*@StgIDa-97$z#HZtl~1VliGr#m9Udd16O_JcZb(=~z8DWV`iB5PqS
z1H&NDk{$*{hm2oX;qrERXQ%rt-?0mNs>5ZG#`g9pK}gl8*h{gWwnB{*l>~~S;!EwU
zL0YH{YG_7tJ?3@k2RPfPPXiq*q+GloGKx2UH(RPqw&AxKeO>tLjyiReYToK8rf3$b
zy>*m+$C=aNWLM>7-NZY4d%!`E;}ge0@r!WxWYzwek?Hl;BP~3I@v{ZdE>)GCLz+j>
z2%nkYe5rh0y_LDbn8u!#}`1M$~=zU?V|@5f5k0A>dF)&>>!sxA>hj~^a^JZ3f=5Jf>74$v#a%Ml+WIVvFEcGH
z2f4V&SBSimP2ycih&XV(7bxsL?sNVsc2e&#?Vc~5ed`6NxyLM8h-dsf3f))$;hy8H
z?iDD=HPD{!6o<#uRXP?XxcqeS4j3YLv$0kca)bK*7FvCcRAro=KDf6puy 
