dummy的反汇编表:
80000000 <_start>: 80000000: 00000413 li s0,0 80000004: 00009117 auipc sp,0x9 80000008: ffc10113 addi sp,sp,-4 # 80009000 <_end> 8000000c: 00c000ef jal ra,80000018 <_trm_init> 80000010 <main>: 80000010: 00000513 li a0,0 80000014: 00008067 ret 80000018 <_trm_init>: 80000018: ff010113 addi sp,sp,-16 8000001c: 00000517 auipc a0,0x0 80000020: 01c50513 addi a0,a0,28 # 80000038 <_etext> 80000024: 00112623 sw ra,12(sp) 80000028: fe9ff0ef jal ra,80000010 <main> 8000002c: 00050513 mv a0,a0 80000030: 00100073 ebreak 80000034: 0000006f j 80000034 <_trm_init+0x1c>
nemu的框架已经提供好了,只需要在inst.c里继续增加指令规则就行。从最简单的dummy开始,nemu报错提示没识别到指令时,就可以仿照已有的例子继续添加了。在这里提供一个方便分析指令的网站:rvcodec.js (luplab.gitlab.io) 反汇编表提供的是已经分析过的汇编代码,并不是这条汇编命令的原貌,所以debug时使用这个网站会更加方便。
在nemu中,已经写入多条指令规则,但是出问题时难以判断具体问题出在哪条指令上时,可以参考讲义,搭建difftest。具体原理参考讲义。简单地来说,就和PA1里面的expr-gen原理类似。每执行一条指令,就和参考模拟器进行寄存器逐项对比,以此判断自己的代码是否正常运行,也能快速定位出问题的指令。 在补充好difftest的代码后,在nemu文件夹下通过menuconfig启动difftest。
遇到的一个很吊诡的事,就是在使用difftest之前,我就已经写入了部分规则,通过了部分测试文件的检测,但是启动difftest以后,原本通过的程序反而不通过了。但是在逐条检查代码时,可以发现,原本的指令规则确实是错误的,但是以一种难以理解的方式通过了测试。这些指令一直保留到后期会导致bug更加难以察觉。所以,为了减少这种不必要的麻烦,最好尽快搭建difftest。
一些需要注意的点:
1. rd需要用宏R()来访问,但是rs1/rs2 (src1\src2)不需要,直接用src1/src2表示的就是寄存器的值。
2. dnpc是会自动增加的,不需要每条规则手动写,但是这并不代表所有指令都不用写,跳转指令是需要提前保存好下一条指令地址的。同时,又由于dnpc会自增,所以在跳转类指令里还需要减去一条指令的地址,也就是-4,是不是很意外?
3.一些指令,比如add和sub,它们的opcode是一样的,但是funct3和funct7不一样,这一点要在规则匹配里体现出来。不能用add尝试顶替sub。
4. 如果指令的规则写对了,但是结果不对,可以试试在规则里插printf,看看立即数对不对。如果立即数不对,那说明imm()函数就已经写错了。
5. 有一条指令比较独特,mulh,它是乘法的升级版,两个数要先变成64位,计算完成后取高32位给rd。问题就在这里:需要留意怎么正确地让rs1 rs2这样的无符号32位变成有符号64位,正确的符号拓展是关键。
6. SEXT是符号拓展的宏,只需要给最高位使用;此外,部分指令的立即数是负载,最低位不使用,所以左移时要注意左移的位数。
标签:匹配,nemu,sp,ysyx,a0,指令,规则,difftest From: https://www.cnblogs.com/namezhyp/p/18282003