[TUHS] Re: Clever code

[segaloco via TUHS <tuhs@tuhs.org>]

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@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