3 ms·
Having one instruction that can be a branch, call, or return seems super weird, what’s the reasoning for it?
by DuckConference 7y ago
Having one instruction that can be a branch, call, or return seems super weird, what’s the reasoning for it?
- Jasper_ 7y agoI'm guessing some misguided attempt at unifying: "They're all a kind of branch". The instruction here is JALR rd,rs1,offs. It takes three arguments: rd, the destination register to put the return address in (it should always be the ABI-defined link register, e.g. t1), rs1, the source register that jump should be relative to (it should always be the link register for a return, and 0 for a call/branch). To a software guy, there's elegance in unifying the three cases, but there's really no such principle in hardware. It just makes the implementation more complex, since branch/call/return all greatly differ for prediction, prefetching, etc.
- tachyonbeam 7y agoI would argue that it's not that elegant in software either. By unifying the instruction, you lose semantic information about what the program is trying to do.
- CodesInChaos 7y agoThe basic idea is that the unconditional jump instructions can optionally write the address after the jump to a register, which allows reusing them as call instructions (it stores the return address in the register). Since calls don't manipulate the stack, return becomes equivalent to an indirect jump to the return address. Thus indirect call, indirect jump and return all become the same instruction. I think this is elegant, at least superficially. However this ambiguity makes tracking the callstack harder, which RISC-V solves by introducing the convention that the x1 register is used for the return address. Which means that the normally irrelevant choice of register suddenly has performance implications, which is not so elegant.