> Why do we need a special function return instruction? Functionally, BR LR would do the same job as RET. Using RET tells the processor that this is a function return.
I'm not sure this is a good design. Those two opcodes perform the same logic function but have different branch prediction hints.
Meanwhile, there are other cases where an existing instruction is reinterpreted with new semantics:
* On x86, `XCHG eax, eax` is `NOP`.
* On x86, `XOR reg, reg` is `MOV reg, 0` and breaks dependencies for the purposes of register renaming.
* On x86, various examples of macro-op fusion and micro-op fusion.
* On various RISC architectures, `ADD r1, r0, 1234` is `MOV r1, 1234`.
* On some RISC architectures, conditionally branching if r0 == 0 is the only way to express an unconditional branch.
I see no reason why `BR LR` can't be the standard function return instruction and involve the branch predictor.
I'm not sure this is a good design. Those two opcodes perform the same logic function but have different branch prediction hints.
Meanwhile, there are other cases where an existing instruction is reinterpreted with new semantics:
* On x86, `XCHG eax, eax` is `NOP`.
* On x86, `XOR reg, reg` is `MOV reg, 0` and breaks dependencies for the purposes of register renaming.
* On x86, various examples of macro-op fusion and micro-op fusion.
* On various RISC architectures, `ADD r1, r0, 1234` is `MOV r1, 1234`.
* On some RISC architectures, conditionally branching if r0 == 0 is the only way to express an unconditional branch.
I see no reason why `BR LR` can't be the standard function return instruction and involve the branch predictor.