> constants are sliced and shuffled I can see you haven't looked at RISC-V :-) There are two reasons RISC-V shuffles constants: 1) to keep rs1, rs2, and rd f

> constants are sliced and shuffled I can see you haven't looked at RISC-V :-) There are two reasons RISC-V shuffles constants: 1) to keep rs1, rs2, and rd fields in the same places in every instruction that has them. I can't think of any other ISA that does this consistently. The place it show up the most is in load and store instructions. In most ISAs the "same" format is used for both, except that the register field that is used for the data to be stored in a store is used for the place to put the loaded data in a load. RISC-V uses the normal rs1 and rs2 fields for store address and data, and rs1 and rd for load address and place to put the result. 2) to give a different range of constants for conditional branch and jump offsets, where odd offsets are not possible, so what is bit 0 in arithmetic instruction constants is instead used as a hi bit -- but not the sign bit but the next one, so that sign extension is always (as mentioned for PA-RISC) always from the same bit. These two things do genuinely make small microcontroller class RISC-V CPUs smaller and faster than they would otherwise be. The cost is it takes half a dozen lines of code in assemblers and disassemblers and JIT and emulators to encode or decode constants. Code that can be written once and put in a function and put in a library, so it's a (very small) one-time cost for programmers. No big deal. It also of course requires a few more instructions each time its run, but it doesn't have any significant effect even on interpretive emulators, let alone transpiling ones.