-2

Below is Data transfer instruction format for 32-bit ARM and MIPS architecture. 32-bit ARM architecture have 4 bit opcode because there are 16 registers (2^4=16).32-bit MIPS architecture have 6 bit opcode. Should not it be 5 bits considering there are 32 registers in MIPS?

enter image description here

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Tom
  • 19
  • 2
  • 6
  • 1
    I'm not sure where you got that ARM instruction encoding from(?). Which exact ARM architecture is that for? In any case, the number of opcode bits has nothing to do with the number of registers. – Michael Sep 01 '20 at 15:27
  • I see 5 bits for both mips register operands. opcode size is irrelevant to register encoding in the instruction. – old_timer Sep 01 '20 at 17:25

2 Answers2

3

The number of registers has nothing to do with the number of opcode bits, it's related to the number of supported instructions (which still isn't a hard limiting factor, considering techniques like instruction prefixes exist).

On the other hand, the operand bit count (Rs and Rd in your picture) are related to the number of registers (they are 5 bit because MIPS has 32 registers, 2^5 = 32).

So having 6 bits for the opcode means only that you are able to encode up to 2^6=64 different instructions which can be interpreted in a single decode cycle.

adnan_e
  • 1,764
  • 2
  • 16
  • 25
  • To be fair, having fewer registers means fewer bits to encode operands, leaving more room for opcode and/or immediate bits. But yes, there's no reason to expect them to be *equal*. – Peter Cordes Sep 27 '20 at 17:31
1

Opcode encoding and register field encoding and immediate/const encoding are different, with different trade offs among them, as making one larger makes the others smaller, when they have to co-exist in the same instruction.

The size of each field determines the number of different items that can be represented in that field.

In comparison with MIPS, for example, RISC V, shortens the "const" immediate field in I-type instructions to 12 bits, which allows for larger opcode fields — 7 bits in the base instruction set opcode field, plus 3 extra bits in func (the fields are also generally reversed, going right to left):

+-------------------------------------------+
| imm:12 | rs1:5 | func:3 | rd:5 | opcode:7 |    I-Type
+-------------------------------------------+

These extra opcode bits are used to:

  • handle instructions of differing lengths, RISC V allows for sizes of:
    • 16-bit instructions called compressed, which can be intermixed
    • 32-bit, used for both 32-bit and 64-bit processors
    • 48-bit and larger (no extensions for these are standardized as yet)
  • for instruction set longevity and evolution
    • over time, instructions are added, yet seldom removed to keep backward compatibility
  • extend the instruction set for application and device specific needs
    • as might happen in embedded usage where extensions are made that are never intended for inclusion in the official specifications
Erik Eidt
  • 23,049
  • 2
  • 29
  • 53
  • Also worth pointing out, MIPS R-type instructions (like `add`, `sltu`, `and`, etc.) all use the same opcode value, and distinguish ALU function based on a separate `func` field. (Which apparently RISC-V has even for I-type, unlike MIPS). The OP's diagram is only for I-type instructions with a 16-bit immediate. But IDK if they realized that, based on the description of "data transfer instructions". – Peter Cordes Sep 01 '20 at 23:22