3 ms·
Yes, 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 instr
by GeorgeTirebiter 5y ago
Yes, 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.