3 ms·

so essentially a B5500 and subsequent systems - it had 2 top of stack registers, a hardware stack and mostly 8-bit opcodes (longer ones for constants and addres

so essentially a B5500 and subsequent systems - it had 2 top of stack registers, a hardware stack and mostly 8-bit opcodes (longer ones for constants and addressing) - super CISCy - that made sense in a time where memory access was very expensive - modern CPUS with on-chip caches and super fast memory don't benefit as much from such extreme opcode compression

kragen 4y ago
No, it's mostly the opposite extreme from the B5500, though both are "stack machines": 1. What I'm proposing for operands is to have a limited-depth hardware operand stack on the chip (3-10 items) instead of an accumulator register. Maybe a bidirectional shift register with two taps to draw off the top two stack items every N bits, for example. The B5500 kept its "hardware" stack in RAM. 2. Separate operand stack and call stack, not unified like the B5500. The call stack in memory doesn't support pushing and popping values, just indexing off it for local variables; in essence you have a call stack frame base pointer register but no call stack pointer register. 3. It's a load-store architecture, which is the opposite of super-CISCy and in particular the opposite of the B5500. No type tags! Hopefully no microcode! Like the PDP-8, you can put your large constants in a constant pool. (Maybe allocate a couple of ALU instructions for pushing 0, 1, and -1.) 4. Fixed-size instructions, like the -8. Probably more than 8 bits per instruction (weren't B5500 syllables 12 bits though?) so that you have room for an offset field of at least 6 bits. Finally, a quibble: as I understand it, it's not so much that dense code is important when memory access is very expensive as that dense code is important when memory is expensive. RV32C has better code density than the B5500* and typically gets a significant speed boost out of it because that significantly boosts I$ hit rates for any given cache size, and I$ is always expensive. But think about small CPUs in general: if your entire CPU is 4000 transistors, an extra 1024 bits of 6T SRAM would cost 6144 more transistors, which drops the number of CPUs you can get onto a die by more than half. ______ * Even though 16-bit RV32C instructions are bigger than 12-bit syllables, they have source and destination fields, so you need less of them.
- Taniwha 4y ago
  most of the Burroughs machines had 2 real top of stack registers (and DP extensions) they were wired to actual lights on the console. Transputers did the fixed small number of top of stack registers thing
  - kragen 4y ago
    Yeah, what I have in mind is more similar to the Transputer or an HP calculator from the 01970s; the Burroughs TOS/NOS registers were conceptually just an optimization, not an architectural feature. Both the Transputer and HP calculators were heavily microcoded, though.

kragen 4y ago

No, it's mostly the opposite extreme from the B5500, though both are "stack machines": 1. What I'm proposing for operands is to have a limited-depth hardware operand stack on the chip (3-10 items) instead of an accumulator register. Maybe a bidirectional shift register with two taps to draw off the top two stack items every N bits, for example. The B5500 kept its "hardware" stack in RAM. 2. Separate operand stack and call stack, not unified like the B5500. The call stack in memory doesn't support pushing and popping values, just indexing off it for local variables; in essence you have a call stack frame base pointer register but no call stack pointer register. 3. It's a load-store architecture, which is the opposite of super-CISCy and in particular the opposite of the B5500. No type tags! Hopefully no microcode! Like the PDP-8, you can put your large constants in a constant pool. (Maybe allocate a couple of ALU instructions for pushing 0, 1, and -1.) 4. Fixed-size instructions, like the -8. Probably more than 8 bits per instruction (weren't B5500 syllables 12 bits though?) so that you have room for an offset field of at least 6 bits. Finally, a quibble: as I understand it, it's not so much that dense code is important when memory access is very expensive as that dense code is important when memory is expensive. RV32C has better code density than the B5500* and typically gets a significant speed boost out of it because that significantly boosts I$ hit rates for any given cache size, and I$ is always expensive. But think about small CPUs in general: if your entire CPU is 4000 transistors, an extra 1024 bits of 6T SRAM would cost 6144 more transistors, which drops the number of CPUs you can get onto a die by more than half. ______ * Even though 16-bit RV32C instructions are bigger than 12-bit syllables, they have source and destination fields, so you need less of them.

Taniwha 4y ago
most of the Burroughs machines had 2 real top of stack registers (and DP extensions) they were wired to actual lights on the console. Transputers did the fixed small number of top of stack registers thing
- kragen 4y ago
  Yeah, what I have in mind is more similar to the Transputer or an HP calculator from the 01970s; the Burroughs TOS/NOS registers were conceptually just an optimization, not an architectural feature. Both the Transputer and HP calculators were heavily microcoded, though.