Shrinking the kernel with a hammer

It's a full 32-bit CPU with 32-bit registers, 32-bit address space, and 32-bit data bus; just the program counter is 26 bits. So executable code needs to be in the lower 64 mebibytes of the address space. Data doesn't have that restriction (in the instruction set architecture; I don't think any machine was built using a CPU with this instruction set and more than 16 megs of RAM).

(The same register contained the 26-bit program counter and six flag bits. I believe this was to reduce the amount of saving and restoring needed for responding to interrupts: you could save the whole CPU state apart from the registers in a single 32-bit operation. With 64-bit CPUs I wonder whether the same technique could make a a comeback: I can see the need for a huge address space for data, but surely it wouldn't be much of a hardship if executable code had to be located in the bottom 281 terabytes...)