IBM 5110 PALM (Put All Logic in Microcode) CPU from 1978

A CPU's registers is where all of the "bit transformation" (adding, subtracting, multiplying, dividing, branching) work that Computers do, is done. Registers are like very small scratchpads, typically 32 or 64 bits (or 4 bytes/8 bytes) wide. Computers with as little as one main register for calculation, and another register for which instruction in memory is executing (instruction pointer) are possible. CPU's as low as 4 bits have existed (Intel 4004), although there's no reason electronically a CPU could use less bits than that (well, in order to execute a program, you need an address in memory, and for that you need more bits for larger addresses, i.e., more memory). Every electronic calculator from the 1970's is a computer IF it had memory, conditional instructions (if results of last calculation were greater than zero, go to (change instruction pointer) to this new address, otherwise, continue with next instruction. MOV AX, BX is an abstraction for programmer consumption only, a CPU's basic instructions are something like: 1) Move value into accumulator (AX, R1 or EAX or RAX or R1 or Reg1) from somewhere in memory. 2) Perform some sort of calulation on it (Add, Subtract, Multiply, Divide, Bit Shift, And, Or, etc.) 3) Store it back to memory 4) Execute a conditional branch instruction which says, as a result of the last mathematical computation, either a) jump to a new address (bypass a section of code), or b) continue with the next instruction.

The Zuse Z3 is probably the simplest Turing-Complete computer that was ever invented (in 1941 no less!); I'd start there:

https://en.wikipedia.org/wiki/Z3_(computer)

The basic elements of a CPU:

An ALU (Arithmetic Logic Unit) that does simple addition and subtraction, binary negation, and integer comparisons.[1]

A collection of registers that store binary bit patterns.

A set of data path switches that connect the elements together in various ways - e.g. so you can connect a register to an ALU and do some math on it, or copy the output of one register to another.

There's also an instruction decoder which converts MOV AX, BX into a set of control signals for all the other parts. For example it sets up the data path switches, connects AX and BX, and then triggers a write on BX.

The first instruction decoders were made from hardwired logic. They shipped with the computer, and they were impossible to change. [2]

Then it was realised that the logic could be replaced by a kind of nano-program for each machine instruction which set up all the elements dynamically.

This could be baked into ROM, or it could be loaded on boot. The latter meant instruction sets could be updated to add new features to the CPU. This also meant the same hardware could run two different instruction sets. (A nice trick, but often less useful in practice than it sounds.)

The real advantage was a cut in development time. Instead of having to iterate on board designs with baked-in instruction decoding, the hardware could be (more or less...) finished and the instruction set could evolve after completion. Bugs could be fixed at much lower cost.

It also meant the instruction set could be extended almost indefinitely with no extra hardware cost. (DEC's VAX was the poster child for this, with linked list manipulation and polynomial math available as CPU instructions.)

And it meant that cheaper CPUs in a range could emulate some instructions in compiled software, while more expensive CPUs could run it at full speed in microcoded hardware - all while keeping code compatibility across a CPU family.

The modern situation is complicated. Modern CPUs are fully modelled in software before being taped out and manufactured, so boot-loadable microcode isn't as useful as it once was.

ARM is fully hardwired (so far as I know) but x86 has a complex hybrid architecture with some microcoded elements - although I believe they're fixed on the die, and can't be updated.

[1] More complex CPUs have floating point support, but the principle is the same.

[2] In fact the earliest decoders were diode arrays, which could be swapped out and replaced. So the idea of microsequencing has been around almost since the first CPUs were built.

Yeah, code-morphing/hardware JIT is extra weird (and probably why Nvidia's Project Denver kinda tanked—turns out, that doesn't work too great for smartphone apps).

One thing I've thought about is having a code-morphing CPU as a sort of accelerator that a single process could be offloaded to (of course, this would require an OS that can marshal processes). Think a database server, a JVM, NodeJS—long-running processes that would benefit from JIT.

Might even be viable with upcoming cache-coherent interconnects like CCIX and GenZ. A more ambitious implementation could offload groups of functions.

Leading to some "interesting" outcomes.

Anyone remember Moblin? Apparently Intel started work on that Linux distro because Microsoft balked regarding an x86 platform without PCI device lookup. And Intel removed the PCI stuff in an effort to cut power drain.

As an aside, running windows on ARM to this day require special SoCs.

The Transmeta Crusoe also included most of the features of the "chipset", it had PCI and memory controller built in at a time when other manufacturers' CPUs didn't.

You still needed to add a display controller but that was true of all the competing CPUs too.