14 Dec
2022
14 Dec
'22
8:28 a.m.
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(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