The CPU I have designed and (implemented, it's running in a Lattice FPGA 
right now)  has three general purpose registers, a frame pointer, and a 
stack pointer. But the encoding problem you mention is real. So instead 
of designing a scheme where the instruction word is split up into 
fields, I have the first byte as the instruction type, and then however 
many immediate data bytes (in this instruction set, 1, or 3) are 
necessary following. The first byte, after it is fetched, is simply fed 
to a lookup table, which then results in a 12 bit value, 6 bits for 
operation, and two 3 bit fields for the a and b registers - these 12 
bits go to the execution stage. This is a two register address, 24 bit 
machine - I designed it as a replacement for the Zilog eZ80, which has 
become hard to get. Anyhow, I get good code density and I've got lots of 
spare codes left. I've attached the ISA description.

I did go through lots of design alternatives to reach the parameters of 
this ISA - they key one was if I wanted to have the operations I needed, 
available across all the general purpose registers, that limited how 
many general purpose registers I could have and keep all the 
enumerations in less than 256 codes, with some to spare. Another set of 
of choices relates to how I wanted to implement C on this machine, and 
that I did not intend for it to support all possible styles of assembly 
language programming - it is meant to support code generated by the C 
compiler, with a minimum of assembly required.

This machine is called "COR24". I can describe the machine in further 
detail, or show you some sample code,  if you're interested.

Luther

On 12/13/2022 01:14 PM, segaloco via TUHS wrote:
> 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