| |||||||||
Intel's iAXP-432 MicroMainframe (often known as a "mainframe on a chip") was a four-core, 32-bit microprocessor released in 1981. It had on-chip support for handling the data structures common to object-oriented programming and multitasking, allowing modern operating systems to be implemented on it with far less code -- the CPU would instead do much of the work internally. However the design was deathly slow and very expensive, and Intel's plans to replace the x86 architecture with the 432 ended miserably.
The 432 project started in 1975 as the 8800, so named as a follow-on to the existing 8008 and 8080 CPUs. The design was to consist of several separate chips working in parallel, notably the 2-chip GDP which was the main processor, and the IP (the 43203) which operated as a channel controller for I/O. It was a 32-bit design from the start. The three-chip system used about 250,000 logic gates, making it one of the largest designs of its era; the contemporary Motorola 68000 contained about 68,000 for instance, about 1/3rd of that for its microcode.
The GDP was split in two, one chip (the 43201) handling the fetching and decoding of the instructions, the other (the 43202) executing them. Like most Intel CPU designs, the 432 used a segmented memory system, with 2^24 segments of 64k each within the overall 2^32 byte address space. All memory handling was private, with user programs not able to handle memory directly. The chip supported data hiding directly, checking all memory accesses for type and permissions, thereby slowing memory access considerably. Most of this complexity was handled in microcode.
In 1983 Intel also released the MCU memory controller, as well as the BIU bus controller. The BIU was intended to allow for multi-processor systems with up to 63 nodes.
Several design features of the i432 conspired to make it much slower than it could have been. The two-chip implementation of the GDP limited it to the speed of the motherboard's electical wiring, although this is a minor issue. The lack of reasonable caches and registers was considerably more serious. The instruction set also hindered performance by using bit-aligned variable-length instructions, making instruction decoding complex. In addition the BIU was designed to support fault-tolerant systems, and in doing so added considerable overhead to the bus, with up to 40% of the bus time in wait states.
Post-project research suggested that the biggest problem was in the compiler however, which used high-cost "general" instructions in every case, instead of high-performance simpler ones where it would have made sense. For instance the i432 included a very expensive inter-module procedure call instruction, which the compiler used for all calls. However this call was also very expensive, and the much faster branch and link instructions were ignored. Another very slow call was enter_environment, which set up the memory protection. The compiler ran this for every single variable in the system, even though the vast majority were running inside an existing environment and didn't have to be checked. To make matters worse it always passed data to and from procedures by value rather than by reference, requiring huge memory copies in many cases.
Sadly the market appears to have taken away the wrong lesson from the i432 failure. Generally the market has concluded that object support in the chip leads to a complex design that will invariably run slowly. However it appears that the OO support was not the problem at all, the problems were much more general and would have made any chip design slow. Since the i432 no one has attempted a similar design, although the INMOS Transputer's process support was similar -- and very fast.
A new implementation based on a RISC core was built in an Intel/Siemens project, resulting in the 960 MC used in the BiiN project. The 960 MC's core was used by Intel to create the i960 RISC CPU, by dropping much of the i432 support from the design. Although the 960 MC design predates it, the i960 was released first due to the considerably lower complexity.