Gregory's ServerThis complicated block diagram from a 432 patent shows what's inside the decoder chip. To summarize: instructions enter at the left (ACD) and micro-instructions exit at the right (µI bus). Microprogram ROM is in the center. The Composer Matrix extracts chunks of instructions.
|
26 comments
 This closeup of the microcode ROM shows the vertical select and output data lines and the zig-zag polysilicon select lines. Bits are stored by putting a transistor at each zig-zag, or not. Changing the focus shows the underlying transistor pattern and thus the microcode bits. Why so much microcode? The basic operations and addressing modes took 250 micro-instructions; the other 3.7K implemented floating point and the "sophisticated object-oriented functions" of the system. The 432 was one of the first to use IEEE-754 floating point, still used today. Binary decoders select rows and columns in the ROM. Each column matches a binary number: 0000, 0001, 0010, etc. The boxes indicate transistors, attached to a 0 or 1 line. The low-bit transistors (red) alternate every column, orange alternate every two columns, etc. Since instructions aren't aligned with bytes, a 32-bit shifter called the "Composer Matrix" shifts the word to extract each instruction field. Diagonal control lines energize transistors to select an arbitrary shift. A PLA-based state machine steps through the chunks of the instruction, running microcode routines as needed. The bit instruction pointer keeps track of the location in a byte. (A jump instruction can end up in the middle of a byte.) An interesting circuit is the charge pump, an analog circuit on this digital chip. It has an oscillator and capacitor to generate a negative voltage. This negative bias on the silicon improves performance. The charge pumps are almost identical to the ones in the 8086 processor. As the 432 project fell behind schedule, Intel realized they urgently needed something to sell. Intel quickly threw together a short-lived stopgap processor to sell until the 432 was ready: the 8086 (1978) was a huge success and is still around in the x86 architecture. The iAPX 432 was finally released in 1981 to great fanfare. But its performance was dismal, 1/4 the speed of the 8086, making the 432 a flop. The paper that killed the 432 was "A Performance Evaluation of the Intel iAPX 432". I recently realized that one of the paper's co-authors was my former officemate https://twitter.com/Bob_Mayo. The big computer architecture debate of the 1980s was RISC vs CISC, pitting Reduced Instruction Set Computers against Complex Instruction Set Computers. RISC processors were simple but fast with lots of registers, moving complexity to software. Instructions were easy to decode. Built just before RISC, the 432 took CISC to the extreme, putting everything possible into hardware rather than software: objects, garbage collection, etc. Intel called it the Silicon Operating System. With no user-visible registers, instructions were stack and memory-based. Minimizing the "semantic gap" between high-level languages and assembly language was a big thing back then. The 432 was designed for the Ada language with instructions to perform high-level operations. The Ada compiler was $30,000; we're spoiled now by open-source compilers. What if the 432 had won? Computing would be very different. Many security problems wouldn't exist. You can't have a buffer overflow because every data structure is a separate object with memory segment size enforced in hardware. You can't smash the stack or make bad pointers. There aren't many die photos of the 432 chipset, but I made this summary from various sources. The 43201 and 43202 form the "General Data Processor". The 40203 was an attached I/O co-processor. The Bus Interface and Memory Control were for fault-tolerant multiprocessor systems.  @kenshirriff wow. I didn't know iNTEL made this and it fits neatly into my fantasy world where one could increase processing power by adding hardware to the existing hardware. You could upgrade without having to throw out the old stuff immediately. I know the nuance would kill such a thing but a person can dream. I'm wondering if this was inspired by LISP? Thanks for sharing @0xF21D I don't think there was any Lisp influence on the iAPX 432. It was inspired by object-oriented languages, specifically Ada. @kenshirriff @0xF21D my 432 had the Ada compiler. it took hours to compile “hello.adb”. had access to it at Purdue. it was 1983 i think. my summer job was learning Green Ada, at Honeywell SRC. Taking the Instruction Decoding Unit die photos was a bit tricky because the die is encased in a paperweight. Thanks to moylecroft for loaning me the paperweight.  @kenshirriff Knowing the ebb and flow of generic vs specific computing hardware, I'm pretty sure the model would have been dropped into a more generic, largely software driven system eventually and we'd have all the security problems in any case.. =)  @kenshirriff In 1985 the ARM1 was revolutionary in having a barrel-shifter "for free" in the instruction set, which cost a huge amount of die area but was impressively flexible compared to the 1-bit-per-clock shifts of 68k and x86. Here they have the same structure and area cost, but its utility is almost completely invisible to the programmer! The 432 was wild...  @kenshirriff The 43201 microcode can be dumped electrically without decap, and I've done that for a release 1 C43201. Unfortunately the 43201 and 43202 contain many PLAs which (AFAIK) can't be dumped other than by decap and photomicrograph. @kenshirriff Only a tiny amount. I'll try to find time to put what I've got into a GitHub repo. |
I partially reverse-engineered the die photo to label it with approximate functional blocks. The top half is the microcode ROM and the state-machine PLAs (programmable logic arrays). The bottom half disassembles the instruction stream and shuffles pieces around.