我研究了 mips 一段时间，关于（ RIJ ）格式以及在处理 I 格式时何时需要符号扩展。
但是在 lh(Load Half) 或 lb(Load Byte) 的情况下，一旦它们从内存中取出，它们的符号就会从 8 位/16 位扩展到 32 位以避免潜在的错误，但是什么时候会发生这种情况?
符号甚至在进入 ALU 之前就扩展了立即数，但是在从内存中读取所需的数据之后，需要在将其保存到寄存器之前进行符号扩展。
但是 mips 架构的覆盖（单周期）在 WriteBack 阶段没有符号扩展步骤，这是如何工作的？
您不能太认真地对待这些框图；他们缺少很多真正的处理器必须做的事情。
例如，通常缺少用于处理jal将 PC+4 捕获到$ra返回地址寄存器中的数据路径和控制信号，以及用于处理jr $ra返回到调用者操作的数据路径和控制信号。
更多的通常也会丢失。缺少乘法和除法——这些涉及 2 个额外的寄存器以及另一个专用 ALU（在原始 MIPS 上）。协处理器功能也没有（协处理器 0 与异常和中断有关，协处理器 1 是浮点单元）。
一种可能性是数据存储器执行符号/零扩展工作，因为它的输出已经是 32 位宽，但是当然，它需要大小信息并知道是零扩展还是符号扩展，并且未显示控制信号在那些图中。
你是对的，它也可能在 WriteBack 期间发生在寄存器中，但我发现随着我们转向流水线处理器，b/c 的可能性较小，从 MEM 阶段输出到 EX 以及从 MEM 到 MEM 的转发，以及值forwarded 需要已经完全形成，因此不能等到流水线处理器中的 WriteBack。
MIPS 最初是作为流水线处理器开始的，这些单周期图基本上是理论上的，并且是为教育目的而制作的。因此，如果他们必须处理它，可能会像在流水线处理器中一样完成，也就是说可能在数据存储器块之内或之后（并且内部或之后之间的区别主要是图表和分组的问题）块的功能）。
您在解码期间和到达 ALU 之前对指令立即字段进行符号扩展也是正确的。需要明确的是，这只是 16 到 32 位的扩展，通常仅作为有符号扩展进行图解，但必须能够进行符号和零扩展，例如对于addivs. ori。（指示立即数的扩展形式的控制信号通常也没有显示。）此外，进行立即数扩展的硬件正在使用中，因此不能用于数据存储器输出扩展的扩展，因此字节和半字不在其中被延长。