grayresearch
commented
9 months ago Hi Ceslanon, thank you for your question. Sorry for the slow response.
There is no good reason not to use custom-3 opcodes. The current spec reflects discussions 2019-2022 and through that design period we never concretely discussed custom-3, so being conservative I did not include that in the draft proposed spec. Indeed I was surprised to hear one vendor express interest in using custom-3 opcodes for always-on legacy custom opcodes even while custom-0/1/2 are multiplexed under the control of mcx_selector.
As I mention in the CX design and rationale talk [https://www.youtube.com/watch?v=7daY_E2itpo&t=1977s] , the specific behavior of the custom-* opcodes when CX multiplexing is enabled was a matter of serious debate during the first rounds of CX design. There are design problems we want to address (e.g., means to encode dependence or non-dependence of register operands) and new features we want to address (e.g., post-V1 CX memory access instructions) so this will be revisted and redesigned during the anticipated 2024 CX TG work. I expect when we reopen this can of worms custom-3 will definitely be on the table too.
Also please note in the latest draft spec, the mcx_selector CSR now has a .version field (replacing the .en(able) field) so that CX-multiplexing-enabled custom instructions behaviors can change cleanly over the years. Therefore implementing our best guess at CX custom instruction encodings in 2024 will not keep us from implementing better ideas in 2027 and again in 2030, etc., without breaking old software on new processors and vice-versa.
Thank you for your question. I will add a comment to the spec about custom-3 and then will close this issue.
The RISC-V spec defines 4 reserved opcodes for custom use, custom-0, custom-1, custom-2 and custom-3. The proposed CXU spec defines instructions using custom 0, 1 and 2, leaving custom-3 unused.
I haven't found a stated reason as to why custom-3 isn't used. Future compatibility with RV128 could be a reason but then using custom-2 would also be a problem.
Maybe i am missing something in either the RISC-V or CX spec but specifying custom-3 as a CX opcode would open up more instructions space for future CXUs. I can imagine cx_flex using custom-2 and cx_flex25 using custom-3 for example.