3 ms·
I have a question about RISC-V: Why is the OpCode on the 'wrong' end of the instruction? Has there ever been ANY machine that puts the op code in the low-order
by GeorgeTirebiter 5y ago
I have a question about RISC-V: Why is the OpCode on the 'wrong' end of the instruction? Has there ever been ANY machine that puts the op code in the low-order bits?
It doesn't really matter -- buy why? Most RISC-V decisions were made for some good reason. (also, I'm not convinced RV32E makes sense anymore.)
- zozbot234 5y agoIt's a little endian architecture so the low-order bits are found "first", directly at the insn address. This matters because of the variable-length insn support.
- GeorgeTirebiter 5y agoYes, and, RV32 is 32-bit, and although addresses access bytes, generally, the hw I've seen fetches at least a word at a time. Such a word may be 2 packed instructions, true. But I still see no advantage putting the opcode in the low-order bits. Now, there is a bit-serial implementation of RV32I, which may indeed benefit from this bit ordering. However, optimizing for an unusual hardware approach (bit-serial) seems sub-optimal. In other words, I would hope there would be some demonstrable benefit to putting the opcode in the low-order bits when memory fetches are at least 32-bits wide in even the simplest machines.
- zozbot234 5y agoYou have to put the length encoding within the lowest-order 16 bits because of the little-endian arch and variable length structure. Might as well put everything related in the very lowest bits. Not sure what your objection to that is. Besides, common insn formats do have funct* bits that are essentially part of the opcode, and found elsewhere in the insn words. The whole arrangement is meant to conserve encoding space as far as possible.