Per https://github.com/grayresearch/CX/issues/27#issuecomment-2026645068, we should replace
imm[7:0] cf_id[3:0] rs1[4:0] 000[2:0] rd[4:0] custom1[6:0] cx_imm
with
imm[11:0] rs1[4:0] cf_id[2:0] rd[4:0] custom1[6:0] cx_imm (I-type)
which is much more regular, provides 4 more immediate bits, and will shave unnecessary operand muxes in any CXU-LI compatible CPU, especially since it also conforms to the layout of CSRR* instructions with insn[31:20] = csr[11:0].
Against the significant upside, the downside of this is: 1) it only handles 8 CF_IDs, not 16 CF_IDs, and 2) it surrenders the present design's future opcode reservation in the func3 field. That's fine, we have mcx_selector.version, as well as uncommitted custom3, for near and long term future CX custom instruction formats. And no doubt, plenty of enthusiastic redesign of the whole thing if/when we get to reopening that can of worms within a CX TG.
grayresearch
commented
5 months ago
Per https://github.com/grayresearch/CX/issues/27#issuecomment-2026645068, we should replace
imm[7:0] cf_id[3:0] rs1[4:0] 000[2:0] rd[4:0] custom1[6:0] cx_immwithimm[11:0] rs1[4:0] cf_id[2:0] rd[4:0] custom1[6:0] cx_imm (I-type)which is much more regular, provides 4 more immediate bits, and will shave unnecessary operand muxes in any CXU-LI compatible CPU, especially since it also conforms to the layout of CSRR* instructions with insn[31:20] = csr[11:0].Against the significant upside, the downside of this is: 1) it only handles 8 CF_IDs, not 16 CF_IDs, and 2) it surrenders the present design's future opcode reservation in the func3 field. That's fine, we have mcx_selector.version, as well as uncommitted custom3, for near and long term future CX custom instruction formats. And no doubt, plenty of enthusiastic redesign of the whole thing if/when we get to reopening that can of worms within a CX TG.