13 Dec
2022
13 Dec
'22
11:58 p.m.
From: Stuff Received
I had always thought of a delay line as a precursor to
a register (or
stack) for storing intermediate results. Is this not an accurate way of
thinking about it?
No, not at all.
First: delay lines were a memory _technology_ (one that was inherently
serial, not random-access). They preceded all others.
Second: 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.)
Some delay-line machines had two different delay line sizes (since size is
equivalent to average access time) - what one might consider 'registers' were
kept in the small ones, for fast access at all times, whereas main memory
used the longer ones.
Noel
14 Dec
14 Dec
12:51 a.m.
New subject: Clever code
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
2:14 a.m.
New subject: Clever code
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 
2:58 a.m.
New subject: Clever code
I think we might move the discussion on memory technologies, CPU
architectures etc. to COFF 😁
Thanks, Warren
8:28 a.m.
New subject: Clever code
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
520
days inactive
521
days old
4 comments
5 participants
participants (5)
-
G. Branden Robinson -
jnc＠mercury.lcs.mit.edu -
Luther Johnson -
segaloco -
Warren Toomey