x86的mov指令执行例子剖析
我们举两个mov指令的例子, 它们是NEMU自带的客户程序mov中的两条指令:
100000: b8 34 12 00 00 mov $0x1234,%eax
......
100017: 66 c7 84 99 00 e0 ff movw $0x1,-0x2000(%ecx,%ebx,4)
10001e: ff 01 00
简单mov指令的执行
我们先来剖析第一条mov $0x1234, %eax指令的执行过程.
取指(instruction fetch, IF)
首先通过inst_fetch()取得这条指令的第一个字节0xb8.
译码(instruction decode, ID)
在fetch_decode_exec()函数中用这条指令的第一个字节0xb8来查找switch-case的分支, 发现这一指令的操作数宽度是4字节的mov指令, 形式是将立即数移入寄存器(move immediate to register).
事实上, 一个字节最多只能区分256种不同的指令形式. 当指令形式的数目大于256时, 我们需要使用另外的方法来识别它们. x86中有主要有两种方法来解决这个问题(在PA2中你都会遇到这两种情况):
- 一种方法是使用转义码(escape code), x86中有一个2字节转义码
0x0f, 当指令opcode的第一个字节是0x0f时, 表示需要再读入一个字节才能决定具体的指令形式(部分条件跳转指令就属于这种情况). 后来随着各种SSE指令集的加入, 使用2字节转义码也不足以表示所有的指令形式了, x86在2字节转义码的基础上又引入了3字节转义码, 当指令opcode的前两个字节是0x0f和0x38时, 表示需要再读入一个字节才能决定具体的指令形式. - 另一种方法是使用
ModR/M字节中的扩展opcode域来对opcode的长度进行扩充. 有些时候, 读入一个字节也还不能完全确定具体的指令形式, 这时候需要读入紧跟在opcode后面的ModR/M字节, 把其中的reg/opcode域当做opcode的一部分来解释, 才能决定具体的指令形式. x86把这些指令划分成不同的指令组(instruction group), 在同一个指令组中的指令需要通过ModR/M字节中的扩展opcode域来区分.
接下来还需要识别指令的操作数. 对于mov $0x1234, %eax指令来说, 识别操作数其实就是识别寄存器%eax和立即数$0x1234. 在x86中, 通用寄存器都有自己的编号,I2r形式的指令把寄存器编号也放在指令的第一个字节里面, 我们可以通过位运算将寄存器编号抽取出来; 立即数存放在指令的第二个字节, 可以很容易得到它. 需要说明的是, 由于立即数是指令的一部分, 我们还需要通过inst_fetch()函数来获得它.
此外, x86的译码辅助函数的命名很直观, 直接反映了操作数的类型和数据流向. 以nemu/src/isa/x86/instr/decode.c为例, 其中的译码辅助函数主要以i386手册附录A中的操作数表示记号来命名. 例如I2r表示将立即数移入寄存器, 其中I表示立即数, 2表示英文to, r表示通用寄存器, 更多的记号请参考i386手册.
执行(execute, EX)
对于mov $0x1234, %eax指令来说, 执行阶段的工作就是把立即数$0x1234送到寄存器%eax中. 由于mov指令的功能可以统一成"把源操作数的值传送到目标操作数中", 而译码阶段已经把操作数都准备好了, 所以只需要针对mov指令编写一个执行辅助函数即可. 这个函数就是exec_mov(), 它是通过def_EHelper宏来定义的:
def_EHelper(mov) {
write_operand(s, id_dest, dsrc1);
print_asm_template2(mov);
}
其中write_operand()函数会根据第二个参数中记录的类型的不同进行相应的写操作, 包括写寄存器和写内存. print_asm_template2()是个宏, 用于输出带有两个操作数的指令的汇编形式.
更新PC
调用update_pc()即可.
复杂mov指令的执行
对于第二个例子movw $0x1, -0x2000(%ecx,%ebx,4), 执行这条执行还是分取指, 译码, 执行三个阶段.
首先是取指. 这条mov指令比较特殊, 它的第一个字节是0x66, 如果你查阅i386手册, 你会发现0x66是一个operand-size prefix. 因为这个前缀的存在, 本例中的mov指令才能被CPU识别成movw. NEMU通过一个ISA相关的译码信息成员s->isa.is_operand_size_16来记录操作数宽度前缀是否出现, switch-case语句中的case 0x66分支实现了这个功能. case 0x66分支对s->isa.is_operand_size_16成员变量做了标识之后, 通过goto语句回到函数的开头重新取出操作码, 此时取得了真正的操作码0xc7. 由于s->isa.is_operand_size_16成员变量进行过标识, 在set_width()函数中将会确定操作数长度为2字节.
x86的操作数宽度处理
大部分x86指令都有不同操作数宽度的版本, 因此x86的操作数宽度信息记录会更复杂: 首先通过set_width()函数记录译码查找表中记录的操作数宽度; 若这一操作数宽度结果为0, 表示仅仅根据操作码来判断, 操作数宽度还不能确定, 可能是16位或者32位, 需要通过s->isa.is_operand_size_16成员变量来决定.
接下来是识别操作数. 根据操作码0xc7查找相应的case分支, 调用译码辅助函数decode_mov_I2E(), 这个译码辅助函数又分别调用decode_op_I()和operand_rm()这两个操作数译码辅助函数来取出操作数. 阅读代码, 你会发现operand_rm()最终会调用read_ModR_M()函数. 由于本例中的mov指令需要访问内存, 因此除了要识别出立即数之外, 还需要确定好要访问的内存地址. x86通过ModR/M字节来指示内存操作数, 支持各种灵活的寻址方式. 其中最一般的寻址格式是
displacement(R[base_reg], R[index_reg], scale_factor)
相应内存地址的计算方式为
addr = R[base_reg] + R[index_reg] * scale_factor + displacement
其它寻址格式都可以看作这种一般格式的特例, 例如
displacement(R[base_reg])
可以认为是在一般格式中取R[index_reg] = 0, scale_factor = 1的情况. 这样, 确定内存地址就是要确定base_reg, index_reg, scale_factor和displacement这4个值, 而它们的信息已经全部编码在ModR/M字节里面了.
我们以本例中的movw $0x1, -0x2000(%ecx,%ebx,4)说明如何识别出内存地址:
100017: 66 c7 84 99 00 e0 ff movw $0x1,-0x2000(%ecx,%ebx,4)
10001e: ff 01 00
根据mov_I2E的指令形式, 0xc7是opcode, 0x84是ModR/M字节. 在i386手册中查阅表格17-3得知, 0x84的编码表示在ModR/M字节后面还跟着一个SIB字节, 然后跟着一个32位的displacement. 于是读出SIB字节, 发现是0x99. 在i386手册中查阅表格17-4得知, 0x99的编码表示base_reg = ECX, index_reg = EBX, scale_factor = 4. 在SIB字节后面读出一个32位的displacement, 发现是00 e0 ff ff, 在小端存储方式下, 它被解释成-0x2000. 于是内存地址的计算方式为
addr = R[ECX] + R[EBX] * 4 - 0x2000
框架代码已经实现了load_addr()函数和read_ModR_M()函数(在nemu/src/isa/x86/decode.c中定义), 它们的函数原型为
void load_addr(DecodeExecState *s, ModR_M *m, Operand *rm);
void read_ModR_M(DecodeExecState *s, Operand *rm, bool load_rm_val, Operand *reg, bool load_reg_val);
它们将s->seq_pc所指向的内存位置解释成ModR/M字节, 根据上述方法对ModR/M字节和SIB字节进行译码, 把译码结果存放到参数rm和reg指向的变量中. 虽然i386手册中的表格17-3和表格17-4内容比较多, 仔细看会发现, ModR/M字节和SIB字节的编码都是有规律可循的, 所以load_addr()函数可以很简单地识别出计算内存地址所需要的4个要素(当然也处理了一些特殊情况). 不过你现在可以不必关心其中的细节, 框架代码已经为你封装好这些细节, 并且提供了各种用于译码的接口函数.
本例中的执行阶段就是要把立即数写入到相应的内存位置. 译码阶段已经把操作数准备好了, 执行辅助函数exec_mov()会完成数据移动的操作, 最终在update_pc()函数中更新PC.