The sign-extend unit works for I-type instructions, what would be it's output for R-type instructions? 32 zeros?

Dani AI

Generated

Short answer for : the sign-extend unit is not magically forced to produce 32 zeros for R-type instructions. As noted, the output exists but the datapath does not use it for R-type ops — the ALU input multiplexer selects the register file output instead (ALUSrc = 0 in the usual control scheme). So the sign-extend output will reflect whatever the unit computes from the instruction bits, but it is effectively ignored for R-type execution.

A few practical clarifications worth keeping in mind: logical immediates like ANDI/ORI are defined to be zero-extended, so real datapaths either have a zero-extend path or a control to select zero-versus-sign extension. Shift amounts (shamt) are taken from the R-type encoding and routed to the shifter separately; they are not read from the sign-extended immediate. In a pipelined MIPS the immediate is still produced in the decode stage and carried forward (wasted for R-type), but that is normal and not harmful beyond area/power.

If debugging or designing HDL: verify the control signals (opcode decode and ALUSrc) and watch the ALU-input multiplexer in simulation. Test with pairs like R-type add, I-type addi, and andi to see the difference. For low-power or optimized designs you can gate or skip computing the sign-extend when ALUSrc = 0, but that is an implementation choice rather than a functional requirement.

[15:0] is always fed into the sign-extend. However, since it's an R-type instruction, we don't really care about the output. If you want to know what the value it, it's [15:0] of whatever the instruction is sign-extended. It's not usually meaningfull though.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.