andresag01
commented
1 year ago It is worth considering that RISC-V already embraced the "easy-mode-switch" idea in the vector extension. The RISC-V vector extension has a group of instructions, i.e. vsetvl, vsetvli, etc, to easily change configuration including the vector length, the element size, etc. Those instructions are key to implementing strip-mining, so are executed fairly frequently.
I think standard RISC-V also has precedent on using groups of instructions to save encoding space. For example, RISC-V does not have an indexed-load instruction of the form load rd, rs1, rs2, it only has load rd, rs1, #imm. RISC-V instead uses add rd1, rs1, rs2 ; load rd2, rd1, #0 to emulate the indexed load and rely on microarchitectural optimizations like instruction-fusion. The idea with this proposal would be similar, for example, cchangemode cap ; load-cap-via-cap; changemode int to avoid the need for load/store (.ddc/.cap) in the other mode.
Morello has the BX instruction which allows the mode to switch between integer and capability modes.
For RISC-V we have CJALR which installs a new PCC, and PCC.flag determines the mode.
For a simple in-order pipeline without a mode predictor, it's not known whether CJALR will change mode or not, potentially causing a pipeline flush if it does.
To simplify this, simple 16-bit instruction(s) which either
makes the mode switch very predictable, avoiding the need for a predictor (although for a wide decoder you'd probably want to predict the presence of this instruction anyway as it affects the decode of later instructions in the decode bundle).
Should the instruction also return the existing mode? Certainly for 16-bit encodings, adding a register specifier uses a lot of encoding space. I think that this can be done instead by reading the PCC and examining PCC.flag as this will happen less frequently, so the performance matters less.
Also, having a quick and easy mode switch should help encoding space as it reduces the need for load/store in the other mode (.DDC/.CAP variants).