MIPS中addi指令被分成三条指令的问题

问题

基于MIPS写CPU时，突然发现addi指令有时会被mars拆解为三条指令，再转为机器码。
发现这个问题是因为显然我们有为一个32位寄存器赋值的需求，使用addi $t1, $zero, imm来实现很方便。但addi指令中的imm(立即数)字段只有16位，如果立即数太大了，mars并不会报错，而是自动地用其他可行的语句实现我们的需求。

实验

case1：

addi $t1, $zero, 0x8000

汇编程序将其拆解为三条：
lui $1, 0x00000000
ori $1, $1, 0x00008000
add $9, $0, $1

case2：

addi $t1, $zero, 0x7fff

汇编程序翻译：
addi $9, $0, 0x00007fff  # 16位立即数能表示的最大正数为0x7fff

汇编默认程序员输入的常数如果不带负号就是正数（方便编程，如果想用一个负数还需要手动转它的补码表示，肯定崩溃了）。16位立即数能表示的最大正数为0x7fff。当addi中的立即数太大，超过0x7fff时，addi指令中的imm字段放不下。但ori指令的按位或并不care最高位是不是符号位，借助lui和ori即可实现。

当然，这种”默认“不是没有底线的。如果程序员输入的常数大于等于0x80000000，超出了32位寄存器能存下的最大正数，汇编程序再怎么搞也不行。这种情况下，mars只能将其理解为一个负数（仍然不会报错）。

case3：

addi $t1, $zero, 0xffff7fff

汇编程序将其拆解为三条：
lui $1, 0xffffffff
ori $1, $1, 0x00007fff
add $9, $0, $1

case4:

addi $t1, $zero, 0xffff8000

汇编程序翻译：
addi $9, $0, 0xffff8000  # 16位立即数能表示的最小负数为0x8000

这两种情况和上面的case1和case2是类似的，负数如果太大，imm字段就放不下，借助lui和ori实现。

总结

• 当立即数在0x00000000~0x7fffffff范围内时，mars认为你想表示一个正的立即数。
  • 0x00000000~0x00007fff，imm字段能放下，一条指令实现。
  • 0x00007fff~0x7fffffff，imm字段放不下太大的正数，三条指令实现。
• 当立即数在0x80000000~0xffffffff范围内时，mars认为你想表示一个负的立即数。
  • 0x80000000~0xffff7fff，imm字段放不下太小的负数，三条指令实现。
  • 0xffff8000~0xffffffff，imm字段能放下，一条指令实现。