为什么我们在加载字指令中要签名扩展？
我正在学习 MIPS 32 位。我想问的是，在存储字的情况下，为什么我们要在将 16 位偏移量（在单周期数据路径中）发送到 ALU 之前对它进行符号扩展？
I am learning MIPS 32 bit. I wanted to ask that why do we Sign Extend the 16 bit offset (in Single Cycle Datapath) before sending it to the ALU in case of Store Word?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我不确定现在对您是否有帮助，但无论如何我都会发布它。
让我们从非常非常普遍的意义上考虑，C++ 中的指令数组，即 A[0],A[1],A[2] .....
任意两条指令之间的“象征性”距离是 1 个单位。
让我们用 MIPS 来类比。在 MIPS 中，象征性地每条指令都由“1 UNIT”分隔，但是，在 MIPS 中，1 UNIT = 4 字节。每条指令都是 4 字节长，这就是为什么当从一条指令移动到另一条指令时，PC 会增加 4，即 PC+4。这样，指令 i 和指令 i+2 之间的间隙是“象征性”2，但实际上是 2*4=8，即 PC+4+4
回到分支指令中指定的偏移量，该偏移量代表“象征性”距离从下一条指令（分支之后的指令）开始。因此，为了获得“真实”距离，偏移量需要乘以 4。这就是我们被指示将偏移量向“左”“符号扩展”2 位的原因，因为将任何二进制值左移n 位导致该值乘以 2^n。在我们的例子中 2^2 = 4
所以分支指令的实际目标地址是 PC+4+4*Offset。
希望这有帮助。
I am not sure if it's helpful for you now, but I am posting it anyway.
Let us consider in a very very general sense, an array of instructions in C++ i.e. A[0],A[1],A[2] .....
The "figurative" distance between any two instructions is 1 UNIT.
Lets take this analogy to MIPS. In MIPS, figuratively every instruction is separated by "1 UNIT", however, 1 UNIT = 4 Bytes in MIPS. Every instruction is 4 Bytes long and this is why when moving from instruction to instruction the PC is incremented by 4 i.e. PC+4. So that way the gap between instruction i and instruction i+2 is "figuratively" 2 but actually 2*4=8 i.e. PC+4+4
Coming back to offsets that are specified in Branch instructions, the offset represents the "figurative" distance from the next instruction(the instruction following the Branch). So to get the "real" distance, the offset is to be multiplied by 4. This is the reason we are instructed to "sign-extend" the offset by 2 bits to the 'LEFT', because, left shifting any binary value by n bits results in multiplying that value by 2^n. In our case 2^2 = 4
So the actual target address of a branch instruction is PC+4+4*Offset.
Hope this helps.
听起来16位偏移量是一个带符号的2的补码数字，即它可以可以是正的，也可以是负的。
当转换为32位时，需要将最高有效位复制到高16位，以保留符号信息。
Sounds like the 16-bit offset is a signed 2's complement number, i.e. it can be either positive or negative.
When converting it to 32 bits, the most significant bit needs to be copied to the upper 16 bits in order to keep the sign information.
据我所知，在加载或存储指令中，偏移值被添加到临时寄存器中的值（作为 temp）。寄存器是32位的，不能进行16位和32位的加法运算，该值是符号扩展的。
To the best of my knowledge,in load or store instructions the offset value is added to the value in temporary register,as temp. register is 32 bit and addition operation of 16 bit and 32 bit is not possible,the value is sign extended.
我认为你的概念在这里有点错误。
您认为进入 ALU 内部的 5 位实际上进入寄存器内存以选择 32[2^5] 寄存器之一。
每个寄存器本身都是 32 位。因此，要将偏移量添加到寄存器值，您需要将其符号扩展为 32 位。
ALU 操作始终在 MIPS 的单周期数据路径中两个相同大小的寄存器之间进行。
I think you are getting your concepts a little wrong here.
The 5 bits that you think are going inside the ALU, actually go inside the register memory to select one of the 32[2^5] registers.
Each register itself is of 32 bits. Hence, to add the offset to the register value, you need to sign extend it to 32 bits.
ALU operation is always between two registers of the same size in the single cycle datapath for MIPS.
在 32 位机器的硬件中，大多数 ALU 都采用 32 位输入，并且所有寄存器都是 32 位寄存器。
要处理您的数据，它必须是 32 位宽，这就是我们进行 SIGN 扩展的原因，然而另一种方法是零扩展，但是当您处理立即数和偏移量以保留 2 中的符号时，会使用 SIGN 扩展补充。
In the hardware of a 32-bit machine most ALU's take 32-bit inputs, and all registers are 32-bit registers.
To work with your data it must be 32-bits wide, this why we SIGN-extend, however another approach would be to ZERO-extend, but SIGN-extend is used when you are dealing with immediates and offsets to preserve the sign in 2's complement.
例如，在 M68xxx 机器的情况下，仅在加载地址寄存器的情况下才会发生符号扩展。对于数据寄存器而言并非如此。
例如
在数据寄存器加载到 $0000FFFF 的情况下， 导致
然而地址寄存器加载到$FFFFFFFF。
要理解这一点，请构建带符号负数的两个补码
演示文稿，$FFFF，将数字扩展到 32 位并重做两个-
补码，找到对应的 32 位表示。
干杯和亲切的问候，
斯蒂芬·S。
Sign extension happens e.g. in case of M68xxx machines only in case of loading the address registers. Not so in case of data registers.
having e.g.
leads in case of data register loading to $0000FFFF, in case of the
address register loading however to $FFFFFFFF.
To understand this, build the two complement of the signed negative
presentation, $FFFF, extend the number to 32 bit and redo the two-
complement, finding the corresponding representation in 32 bit.
Cheers and kind regards,
Stephan S.