- 65E4 Microprocessor Final Design Specification (May 10, 1982)
Physically:
- 40 pin chip with 24 bit address bus and 16 bit data bus (some multiplexed pins!)
- Direct support for DRAM with RAS and CAS and refresh
Programming model:
- Flat 24 bit address space, each process operates between base and limit
- Support for 6 bit relative addressing and 9 bits of 'zero page' short addressing
- Support for three levels of privilege: Kernel, System, User
- Many possible traps/exceptions: stack growth, overflow, divide by zero, protection, type error
- Stack relative, program relative, heap relative addressing modes
- Programs relocatable in flight (logical addresses written to memory but physical addresses used within the MPU)
- All addresses subject to base and limit controls, positive offsets only from base
- Support for operating on bytes, double, triple byte values...
- ... also binary and decimal real formats, longer integers, and strings
- ... all using a descriptor byte ahead of the data instead of opcode bits
- ... also supporting records and multidimensional arrays
- ... which can be nested
- ... all of which can be relocatable
- ... and arrays can be bounds-checked
- ... and the descriptor byte can defer the data definition by giving the address of a further descriptor byte
- ... which can again defer the data definition...
Lower level details
- Instructions are bytesized opcodes with a trailing byte for addressing modes and more bytes for up to three operands
- Clocked at 8MHz for a 2MHz memory cycle
- 8-bit ALU with BCD capability (can perform 32 bit operations in one memory cycle)
- Machine is microcoded and nanocoded, both in ROM
- Multiple sets of microcode selectable for each process, somehow microcode can be fetched from memory perhaps?
Opcodes then operate on one or two operands from memory and store back to possibly a third location. Operations include all the usual logical and arithmetic ones, as well as multiply, divide, modulus, square root, leading zeroes, leading ones, find string within string, find one of several characters within string, evaluate RPN expression...
The traps and exceptions machinery is quite involved: we can trap on instruction executions, on data accesses, and we can trap mid-way through instructions. A lot of chip state is pushed to stack (60 bytes!) which seems likely to make interrupt latency quite high. On the other hand, the bus interface supports DMA and coprocessors so perhaps other hardware is expected to be doing more work autonomously.
What are my thoughts on this... well, we have some very complex instructions, we have no visible register file, we have variable length instructions, we have instructions which take very many clocks. There are counterarguments to RISC, and this machine is perhaps embracing them, although that debate wasn't quite open at this time. With complex instructions, you need fewer instructions to do a task, and the instructions can match the operations needed by high level languages. With the base and limit checking, the exceptions, the type checking, perhaps programs are safer on this machine than on a C-like machine.
The implementation is in some ways modest: 16 bit wide memory path, 2MHz memory cycle, perhaps somewhat tied to DRAM sizes of the day, sticking to the 40pin DIP.
But the architecture is very ambitious - does it perhaps nail down too much by way of what a compiler must look like, and what an operating system must look like? Is it perhaps too complex to explain and so too complex to sell, too complex to debug, too complex to be convincing that the chip will ever appear in a working state?
