RTFSC
既然TRM那么简单, 就让我们在NEMU里面实现一个TRM吧.
不过我们还是先来介绍一下框架代码. 框架代码内容众多, 其中包含了很多在后续阶段中才使用的代码. 随着实验进度的推进, 我们会逐渐解释所有的代码. 因此在阅读代码的时候, 你只需要关心和当前进度相关的模块就可以了, 不要纠缠于和当前进度无关的代码, 否则将会给你的心灵带来不必要的恐惧.
ics2017
├── init.sh # 初始化脚本
├── Makefile # 用于工程打包提交
├── nanos-lite # 微型操作系统内核
├── navy-apps # 应用程序集
├── nemu # NEMU
└── nexus-am # 抽象计算机
目前我们只需要关心NEMU的内容, 其它内容会在将来进行介绍. NEMU主要由4个模块构成: monitor, CPU, memory, 设备. 我们已经在上一小节简单介绍了CPU和memory的功能, 设备会在PA2中介绍, 目前不必关心. monitor位于这个虚拟计算机系统之外, 主要用于监视这个虚拟计算机系统是否正确运行. monitor从概念上并不属于一个计算机的必要组成部分, 但对NEMU来说, 它是必要的基础设施. 它除了负责与GNU/Linux进行交互(例如读写文件)之外, 还带有调试器的功能, 为NEMU的调试提供了方便的途径. 缺少monitor模块, 对NEMU的调试将会变得十分困难.
代码中nemu目录下的源文件组织如下(部分目录下的文件并未列出):
nemu
├── include # 存放全局使用的头文件
│ ├── common.h # 公用的头文件
│ ├── cpu
│ │ ├── decode.h # 译码相关
│ │ ├── exec.h # 执行相关
│ │ ├── reg.h # 寄存器结构体的定义
│ │ └── rtl.h # RTL指令
│ ├── debug.h # 一些方便调试用的宏
│ ├── device # 设备相关
│ ├── macro.h # 一些方便的宏定义
│ ├── memory # 访问内存相关
│ ├── monitor
│ │ ├── expr.h # 表达式求值相关
│ │ ├── monitor.h
│ │ └── watchpoint.h # 监视点相关
│ └── nemu.h
├── Makefile # 指示NEMU的编译和链接
├── Makefile.git # git版本控制相关
├── runall.sh # 一键测试脚本
└── src # 源文件
├── cpu
│ ├── decode # 译码相关
│ ├── exec # 执行相关
│ ├── intr.c # 中断处理相关
│ └── reg.c # 寄存器相关
├── device # 设备相关
├── main.c # 你知道的...
├── memory
│ └── memory.c # 访问内存的接口函数
├── misc
│ └── logo.c # "i386"的logo
└── monitor
├── cpu-exec.c # 指令执行的主循环
├── diff-test
├── debug # 简易调试器相关
│ ├── expr.c # 表达式求值的实现
│ ├── ui.c # 用户界面相关
│ └── watchpoint.c # 监视点的实现
└── monitor.c
为了给出一份可以运行的框架代码, 代码中实现了mov指令的功能, 并附带一个mov指令序列的默认客户程序.
另外, 部分代码中会涉及一些硬件细节(例如nemu/src/cpu/decode/modrm.c).
在你第一次阅读代码的时候, 你需要尽快掌握NEMU的框架, 而不要纠缠于这些细节.
随着PA的进行, 你会反复回过头来探究这些细节.
大致了解上述的目录树之后, 你就可以开始阅读代码了. 至于从哪里开始, 就不用多费口舌了吧.
嗯... 如果你觉得提示还不够, 那就来一个劲爆的: 回忆程序设计课的内容, 一个程序从哪里开始执行呢?
如果你不屑于回答这个问题, 不妨先冷静下来. 其实这是一个值得探究的问题, 你会在将来重新审视它.
在PA0的强迫之下, 你不得不开始学习使用vim. 如果现在你已经不再认为vim是个到处是bug的编辑器, 就像简明vim练级攻略里面说的, 你已经通过了存活阶段. 接下来就是漫长的修行阶段了, 每天学习一两个vim中的功能, 累积经验值, 很快你就会发现自己已经连升几级. 不过最重要的还是坚持, 只要你在PA1中坚持使用vim, PA1结束之后, 你就会发现vim的熟练度已经大幅提升! 你还可以搜一搜vim的键盘图, 像英雄联盟中满满的快捷键, 说不定能激发起你学习vim的兴趣.
NEMU开始执行的时候, 首先会调用init_monitor()函数(在nemu/src/monitor/monitor.c中定义)
进行一些和monitor相关的初始化工作, 我们对其中几项初始化工作进行一些说明.
reg_test()函数(在nemu/src/cpu/reg.c中定义)会生成一些随机的数据,
对寄存器实现的正确性进行测试.
若不正确, 将会触发assertion fail.
我们在PA0中提到, 运行NEMU会出现assertion fail的错误信息,
这是因为框架代码并没有正确地实现用于模拟寄存器的结构体CPU_state,
现在你需要实现它了(结构体的定义在nemu/include/cpu/reg.h中).
关于i386寄存器的更多细节, 请查阅i386手册.
Hint: 使用匿名union.
然后通过调用load_img()函数(在nemu/src/monitor/monitor.c中定义)读入带有客户程序的镜像文件.
我们知道内存是一种RAM, 是一种易失性的存储介质, 这意味着计算机刚启动的时候, 内存中的数据都是无意义的;
而BIOS是固化在ROM中的, 它是一种非易失性的存储介质, BIOS中的内容不会因为断电而丢失.
因此在真实的计算机系统中, 计算机启动后首先会把控制权交给BIOS,
BIOS经过一系列初始化工作之后, 再从磁盘中将有意义的程序读入内存中执行.
对这个过程的模拟需要了解很多超出本课程范围的细节, 我们在这里做了简化,
让monitor直接把一个有意义的客户程序镜像guest prog读入到一个固定的内存位置0x100000,
这个程序是运行NEMU的一个参数, 在运行NEMU的命令中指定,
缺省时将把上文提到的mov程序作为客户程序(参考load_default_img()函数).
这时内存的布局如下:
0 0x100000
-----------------------------------------------
| | |
| | guest prog |
| | |
-----------------------------------------------
^
|
eip
接下来调用restart()函数(在nemu/src/monitor/monitor.c中定义),
它模拟了"计算机启动"的功能, 进行一些和"计算机启动"相关的初始化工作,
一个重要的工作就是将%eip的初值设置为刚才我们约定的内存位置0x100000,
这样就可以让CPU从我们约定的内存位置开始执行程序了.
monitor的其它初始化工作我们会在后续实验内容中介绍, 目前可以不必关心它们的细节,
最后通过调用welcome()函数输出欢迎信息和NEMU的编译时间.
monitor的初始化工作结束后, NEMU会进入用户界面主循环ui_mainloop()(在nemu/src/monitor/debug/ui.c中定义),
输出NEMU的命令提示符:
(nemu)
代码已经实现了几个简单的命令, 它们的功能和GDB是很类似的.
输入c之后, NEMU开始进入指令执行的主循环cpu_exec()(在nemu/src/monitor/cpu-exec.c中定义).
cpu_exec()模拟了CPU的工作方式: 不断执行指令.
exec_wrapper()函数(在nemu/src/cpu/exec/exec.c中定义)的功能
让CPU执行当前%eip指向的一条指令, 然后更新%eip.
已经执行的指令会输出到日志文件log.txt中, 你可以打开log.txt来查看它们.
在cmd_c()函数中, 调用cpu_exec()的时候传入了参数-1, 你知道这是什么意思吗?
执行指令的相关代码在nemu/src/cpu/exec目录下.
其中一个重要的部分定义在nemu/src/cpu/exec/exec.c文件中的opcode_table数组,
在这个数组中, 你可以看到框架代码中都已经实现了哪些指令.
其中EMPTY代表对应的指令还没有实现(也可能是x86中不存在该指令).
在以后的PA中, 随着你实现越来越多的指令, 这个数组会逐渐被它们代替.
关于指令执行的详细解释和exec_wrapper()相关的内容需要涉及很多细节,
目前你不必关心, 我们将会在PA2中进行解释.
opcode_table到底是个什么类型的数组? 如果你感到困惑, 你需要马上复习程序设计的知识了.
这里有一份十分优秀的C语言教程.
事实上, 我们已经在PA0中提到过这份教程了, 如果你觉得你的程序设计知识比较生疏,
而又没有在PA0中阅读这份教程, 请你务必阅读它.
NEMU将不断执行指令, 直到遇到以下情况之一, 才会退出指令执行的循环:
- 达到要求的循环次数.
- 客户程序执行了
nemu_trap指令. 这是一条特殊的指令, 机器码为0xd6. 如果你查阅i386手册, 你会发现x86中并没有这条指令, 它是为了在NEMU中让客户程序指示执行的结束而加入的.
当你看到NEMU输出以下内容时:
nemu: HIT GOOD TRAP at eip = 0x00100026
说明客户程序已经成功地结束运行.
退出cpu_exec()之后, NEMU将返回到ui_mainloop(), 等待用户输入命令.
但为了再次运行程序, 你需要键入q退出NEMU, 然后重新运行.
在程序设计课上老师告诉你, 当程序执行到main()函数返回处的时候, 程序就退出了, 你对此深信不疑.
但你是否怀疑过, 凭什么程序执行到main()函数的返回处就结束了?
如果有人告诉你, 程序设计课上老师的说法是错的, 你有办法来证明/反驳吗?
如果你对此感兴趣, 请在互联网上搜索相关内容.
最后我们聊聊代码中一些值得注意的地方.
三个对调试有用的宏(在
nemu/include/debug.h中定义)Log()是printf()的升级版, 专门用来输出调试信息, 同时还会输出使用Log()所在的源文件, 行号和函数. 当输出的调试信息过多的时候, 可以很方便地定位到代码中的相关位置Assert()是assert()的升级版, 当测试条件为假时, 在assertion fail之前可以输出一些信息panic()用于输出信息并结束程序, 相当于无条件的assertion fail
代码中已经给出了使用这三个宏的例子, 如果你不知道如何使用它们, RTFSC.
- 内存通过在
nemu/src/memory/memory.c中定义的大数组pmem来模拟. 在客户程序运行的过程中, 总是使用vaddr_read()和vaddr_write()访问模拟的内存. vaddr, paddr分别代表虚拟地址和物理地址. 这些概念在将来会用到, 但从现在开始保持接口的一致性可以在将来避免一些不必要的麻烦.
你需要结合上述文字理解NEMU的框架代码. 需要注意的是, 阅读代码也是有技巧的, 如果你分开阅读框架代码和上述文字, 你可能会觉得阅读之后没有任何效果. 因此, 你需要一边阅读上述文字, 一边阅读相应的框架代码.
如果你不知道"怎么才算是看懂了框架代码", 你可以先尝试进行后面的任务. 如果发现不知道如何下手, 再回来仔细阅读这一页面. 理解框架代码是一个螺旋上升的过程, 不同的阶段有不同的重点. 你不必因为看不懂某些细节而感到沮丧, 更不要试图一次把所有代码全部看明白.
讲义中的知识点很多, 在实验的不同阶段对同一个知识点的理解也会有所不同. 我们建议你在完成相应阶段的任务之后回过头来重新阅读一遍讲义的内容, 你很可能会有不一样的收获.
事实上, TRM的实现已经都蕴含在上述的介绍中了.
- 存储器是个在
nemu/src/memory/memory.c中定义的大数组 - PC和通用寄存器都在
nemu/include/cpu/reg.h中的结构体中定义 - 加法器在... 嗯, 框架代码这部分的内容有点复杂, 不过它并不影响我们对TRM的理解, 我们还是在PA2里面再介绍它吧
- TRM的工作方式通过
cpu_exec()和exec_wrapper()体现
在NEMU中, 我们只需要一些很简单的C语言知识就可以理解最简单的计算机的工作方式, 真应该感谢先驱啊.