ysyx: 指令规则的匹配

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是符号拓展的宏，只需要给最高位使用；此外，部分指令的立即数是负载，最低位不使用，所以左移时要注意左移的位数。