i took a look at the RVC format, and it's nothing like the 32-bit format. the key difference is: rs2 is where rs1 is placed, and rsd/rs1 is placed where rs2 is placed, if you line up the bits so that at least funct and the 5-bit boundaries line up. so... there's no point trying to optimise the format to fit the rs/rd registers, however there _is_ a point to lining up the immediate to match imm[15:0]. adding in some of the C formats (the ones that make sense): | 4 | 3 2 | 1 | |7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6|5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0| |F E D C B A 9 8 7 6 5 4 3 2 1 0|F E D C B A 9 8 7 6 5 4 3 2 1 0|F E D C B A 9 8 7 6 5 4 3 2 1 0| |-----------------------------------------------------------------------------------------------| immN0 | funct7 | rs2 | rs1 | f3 | rd | opcode7 |f| len | 00|page | 00| 11111 | PFX ... immediate[N..15] ... immediate[14:0] |f| len |ssp| rd^ | sp| 11111 | LDI ... immediate[N..15] ... immediate[14:0] |f| len |ssp| rd | sp| 11111 | JAL imm15 | funct7 | rs2 | rs1 | immediate[14:0] |f| len | rd |spc| 11111 | PACK imm15 |fn789| funct6 | rs1'| f2| rs2'| immediate[14:0] |f| len |ssp| rd' |spc| 11111 | CArith imm15 |fn456|func3|imm?which? | rs2 | immediate[14:0] |f| len |ssp| rd' |spc| 11111 | CStackST imm15 |fn567| func4 | rs1 | rs2 | immediate[14:0] |f| len |ssp| rd' |spc| 11111 | CReg ^^^ imm[N..15] * CReg is actually identical to PACK (just with rs2 and rs1 reversed) once funct bits 5, 6 and 7 are added, so is redundant. * CStackST (Stack-relative store) is too awkward: the immediate from stack-relative store messes with the positioning (and dynamic extendability) if you try to keep imm16 in the same place as well as immed[15:0] in the same place. how do you extend the instruction to use imm16+ and place the bits between funct3 and rs2 in that? too much of a mess. scrap it. * CArith sort-of makes sense as long as rs2' and rs1' are put back in their original slots (clifford you swapped them). rs2' lines up with the 32-bit decoder, the 3 bits for x8-x15 still match up with their 32-bit equivalents, just with a hard-coded 0b01 for the top 2 bits. however.... rd is *already* specified in bits 7-9 of the extended format, funct6 doesn't line up... * CWideImmediate doesn't make *any* sense (unmodified): rd' already exists in the proposed 48+ bit format, the imm field already exists in PACK... basically, fitting C in here is going to take a lot more thought. personally, i would feel much happier with a completely revised C format (with a reservation made to be able to do that over time), that better fits the fact that rd' is already part of the proposed 48+ bit format. especially given that... hmmm... who was it... xan phung? sorry, it was over a year ago now: the guy who did that study and came up with RV16, an alternative Compressed format that saved a whopping *25%* code-space *compared to RVC*. so that leaves: | 4 | 3 2 | 1 | |7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6|5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0| |F E D C B A 9 8 7 6 5 4 3 2 1 0|F E D C B A 9 8 7 6 5 4 3 2 1 0|F E D C B A 9 8 7 6 5 4 3 2 1 0| |-----------------------------------------------------------------------------------------------| immN0 | funct7 | rs2 | rs1 | f3 | rd | opcode7 |f| len | 00|page | 00| 11111 | PFX ... immediate[N..15] ... immediate[14:0] |f| len |ssp| rd^ | sp| 11111 | LDI ... immediate[N..15] ... immediate[14:0] |f| len |ssp| rd | sp| 11111 | JAL imm15 | funct7 | rs2 | rs1 | immediate[14:0] |f| len | rd |spc| 11111 | PACK imm15 |fn789| funct6 | rs1'| f2| rs2'| immediate[14:0] |f| len |ssp| rd' |spc| 11111 | CArith ^^^ imm[N..15] with room in CArith for fn789 (and bit 15) to decide what to do with immediate[14:0]. having rd' *and* rs2' *and* rs1' *and* a 15-bit immediate is pretty neat.