The beq
instruction is an I-Type, which means that part of the instruction encodes a 16-bit signed immediate. The instruction is a conditional branch. The immediate for this instruction is used as the taken branch target. If the condition is:
false, then pc := pc + 4
is the operation it performs (fall through to next instruction). Since the branch is not taken, this advances the pc in sequential manner just like any other instruction, such as add
.
true, then branch is taken and the operation is that pc := pc + 4 + sxt32(imm16)*4
, which transfers control to the target, usually a label in assembly language. However, since the immediate is zero, this equation evaluates to pc := pc + 4 + sxt32(0)*4
, which is pc := pc + 4 + 0
-or- pc := pc + 4
.
Thus, whether condition is true or false, whether the branch is taken or not taken, it has the same effect of merely advancing the pc by 1 instruction.
Using labels instead of an immediate:
beq $t3, $t9, next
next:
...
This will also produce an immediate value of 0 in the machine code for the beq
.
If the immediate for a taken beq
is -1, then it branches to itself, which will cause an infinite loop. If the immediate is -2, then it branches backwards by 1 instruction; if the immediate is 0, it simply goes on to the next instruction; if the immediate is 1, the branch skips one instruction.
Removing the instruction will reduce code size and could improve performance but will not otherwise affect the logic of the program — assuming the program does not somehow depend on code size or position.
Let's note that code using branches with immediates tends to be dependent upon position and if you remove an instruction, you may have to fix up these branches — that's why we use labels instead, to get the assembler to compute the proper immediate (so we're free to add and remove instructions, just reassemble).