Where RISC-V is very intentional on this, my reading has lead me to understand that many
previous CPU architectures simply passed pieces of the opcode to further hardware in the
microarchitecture, so it wasn't so much of a design a register system to fit in a
specific bit width but rather a matter of bits 3-5 and 7-9 are connected directly to the
two inputs of the ALU internally or something to that effect. Hearsay of course, I
wasn't there, but that's the explanation I've heard in the past.
Now how much settling on a bit width for the register field of opcodes influences the
number of registers or vice versa, hard to say. Did Motorola want a 3 bit register field
in opcodes or a resolution of 8 registers per addressing mode in the 68k first for
instance, and which decision then followed? I don't know, maybe someone does? In
fact, that makes me now wonder if there are CPUs with non-power-of-two register counts
outside of the early days. Anything else would waste values in a bitfield.
- Matt G.
------- Original Message -------
On Tuesday, December 13th, 2022 at 10:51 AM, G. Branden Robinson
<g.branden.robinson(a)gmail.com> wrote:
At 2022-12-13T12:58:11-0500, Noel Chiappa wrote:
... registers used to have two aspects - one now
gone (and maybe
the second too). The first was that the technology used to implement
them (latches built out of tubes, then transistors) was faster than
main memory - a distinction now mostly gone, especially since caches
blur the speed distinction between today's main memory and registers.
The second was that registers, being smaller in numbers, could be
named with a few bits, allowing them to be named with a small share of
the bits in an instruction. (This one still remains, although
instructions are now so long it's probably less important.)
Maybe less important on x86, but the amount of space in the instruction
for encoding registers seems to me to have played a major role in the
design of the RV32I/E and C (compressed) extension instruction formats
of RISC-V.
https://riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf
Regards,
Branden