Pond’ring CPUs
Pond’ring Aloud 2025-08-31
we need large addresses (64-bit?) for handling rich data (media, etc.)
virtual memory is a nice-to-have for handling rich data
but,,, do we need 64-bit opcodes?
do we need virtual memory for code? Virtual Memory handling requires extra hardware and lots of extra software (== CPU cycles)
how many opcodes do we need? 256 (28)? 65,535 (216)? 4,294,967,296 (232)? 18,446,744,073,709,551,616 (264)?
how many addressing modes do we need?
why are opcodes single, contiguous units? Maybe we need more than one IP (PC), e.g. one IP for opcodes and another IP for operands. OpcodeIP points to bytes, OperandIP points to nibbles (???). OpcodeIP and OperandIP run in lock-step? Do we need more than one OperandIP (operand 1 and operand 2)?
an aspect of bloat is the need for alignment
RAM is currently homogenous, but if we if used different RAM chips and address buses, tuned for each low-level type data, opcodes, operands would we be able to remove significant amounts of bloat?
CPUs are currently bolted to RAM via address and data buses, should we use separate buses for each low-level type?
when writing compilers, my favourite CPU architecture was the NS16032 (later, rebranded as NS32016). I, also liked VAX, PDP-11, MC6809. Uniformity and normalization within architecture design led to fewer edge-cases, hence, less work writing compilers.
I measured that the same code (code written in the Concurrent Euclid language) compiled for MC6809 (8-bit CPU) was 40% the size of the same code compiled for MC68000 (16-bit CPU)
I was intrigued by Transputers (and OCCAM) but never got to touch a Transputer.
See Also
Email: ptcomputingsimplicity@gmail.com
References: https://guitarvydas.github.io/2024/01/06/References.html
Blog: guitarvydas.github.io
Videos: https://www.youtube.com/@programmingsimplicity2980
Discord: https://discord.gg/65YZUh6Jpq
Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas
Twitter: @paul_tarvydas
Bluesky: @paultarvydas.bsky.social
Mastodon: @paultarvydas
Substack: paultarvydas.substack.com