thumb|Intel SBC 432/100 board

thumb|General Data Processor 43201

thumb|General Data Processor 43202

The iAPX 432 (Intel Advanced Performance Architecture) is a discontinued computer architecture introduced in 1981. It was Intel's first 32-bit processor design.

Design began in 1975 as the 8800 (after the 8008 and the 8080), a clean-sheet design that did not have to follow previous machine code conventions. Intel intended that the 432 would be the basis of their future offerings in the microcomputer market, replacing the older designs that had been more ad hoc solutions. The first implementation was too advanced for the semiconductor fabrication techniques of the era, and had to be implemented on two separate integrated circuits. This made it expensive to use. Combined with high prices and very low performance, the 432 ended up seeing little use. It is considered a commercial failure for Intel, and was discontinued in 1986.

The loss of sales of existing designs due to the introduction of the compatible Zilog Z80 led to a 1977 effort to introduce a stop-gap solution while the 432 matured. This emerged as the 8086, which went on to form the basis of Intel processors to this day. Although some early 8086, 80186 and 80286-based systems and manuals also used the iAPX prefix for marketing reasons, the iAPX 432 and the 8086 processor lines are completely separate designs with completely different instruction sets.

Description

The iAPX 432 was referred to as a "micromainframe", designed to be programmed entirely in high-level languages. The instruction set architecture was also entirely new and a significant departure from Intel's previous 8008 and 8080 processors as the iAPX 432 programming model is a stack machine with no visible general-purpose registers. It supports object-oriented programming, written entirely in Ada, and Ada was also the intended primary language for application programming. In some aspects, it may be seen as a high-level language computer architecture.

These properties and features resulted in a hardware and microcode design that was more complex than most processors of the era, especially microprocessors. However, internal and external buses are (mostly) not wider than 16-bit, and, as in some other 32-bit microprocessors of the era such as the 68000, 32-bit arithmetic instructions are implemented by a 16-bit ALU, via random logic and microcode or other kinds of sequential logic. The iAPX 432 enlarged address space over the 8080 was also limited by the fact that linear addressing of data could still only use 16-bit offsets, somewhat akin to Intel's first 8086-based designs, including the contemporary 80286 (the new 32-bit segment offsets of the 80386 architecture was described publicly in detail in 1984).

Using the semiconductor technology of its day, Intel's engineers weren't able to translate the design into a very efficient first implementation. Along with the lack of optimization in a premature Ada compiler, this contributed to rather slow but expensive computer systems, performing typical benchmarks at roughly 1/4 the speed of the new 80286 chip at the same clock frequency (in early 1982).

Originally designed for clock frequencies of up to 10 MHz, actual devices sold were specified for maximum clock speeds of 4 MHz, 5 MHz, 7 MHz and 8 MHz with a peak performance of 2 million instructions per second at 8 MHz.

History

Development

Intel's 432 project started in 1976, a year after the 8-bit Intel 8080 was completed and a year before their 16-bit 8086 project began. The 432 project was initially named the 8800,

The iAPX 432 development team was managed by Bill Lattin, with Justin Rattner (who would later become CTO of Intel) as the lead engineer (although one source Pollack later specialized in superscalarity and became the lead architect of the Intel Pentium Pro.

According to the New York Times, "the i432 ran 5 to 10 times more slowly than its competitor, the Motorola 68000".

Impact and similar designs

The iAPX 432 was one of the first systems to implement the new IEEE-754 Standard for Floating-Point Arithmetic.

An outcome of the failure of the 432 was that microprocessor designers concluded that object support in the chip leads to a complex design that will invariably run slowly, and the 432 was often cited as a counter-example by proponents of RISC designs. However, some hold that the OO support was not the primary problem with the 432, and that the implementation shortcomings (especially in the compiler) mentioned above would have made any CPU design slow. Since the iAPX 432 there has been only one other attempt at a similar design, the Rekursiv processor, although the INMOS Transputer's process support was similar — and very fast.

Intel had spent considerable time, money, and mindshare on the 432, had a skilled team devoted to it, and was unwilling to abandon it entirely after its failure in the marketplace. A new architect—Glenford Myers—was brought in to produce an entirely new architecture and implementation for the core processor, which would be built in a joint Intel/Siemens project (later BiiN), resulting in the i960-series processors. The i960 RISC subset became popular for a time in the embedded processor market, but the high-end 960MC and the tagged-memory 960MX were marketed only for military applications.

According to the New York Times, Intel's collaboration with HP on the Merced processor (later known as Itanium) was the company's comeback attempt for the very high-end market. Unusually, they are not byte-aligned, that is, they may contain odd numbers of bits and directly follow each other without regard to byte boundaries. The system uses segmented memory, with up to 2<sup>24</sup> segments of up to 64&nbsp;KB each, providing a total virtual address space of 2<sup>40</sup> bytes. The physical address space is 2<sup>24</sup> bytes (16&nbsp;MB).

Programs are not able to reference data or instructions by address; instead they must specify a segment and an offset within the segment. Segments are referenced by access descriptors (ADs), which provide an index into the system object table and a set of rights (capabilities) governing accesses to that segment. Segments may be "access segments", which can only contain Access Descriptors, or "data segments" which cannot contain ADs. The hardware and microcode rigidly enforce the distinction between data and access segments, and will not allow software to treat data as access descriptors, or vice versa.

System-defined objects consist of either a single access segment, or an access segment and a data segment. System-defined segments contain data or access descriptors for system-defined data at designated offsets, though the operating system or user software may extend these with additional data. Each system object has a type field which is checked by microcode, such that a Port Object cannot be used where a Carrier Object is needed. User programs can define new object types which will get the full benefit of the hardware type checking, through the use of type control objects (TCOs).

In Release 1 of the iAPX 432 architecture, a system-defined object typically consisted of an access segment, and optionally (depending on the object type) a data segment specified by an access descriptor at a fixed offset within the access segment.

By Release 3 of the architecture, in order to improve performance, access segments and data segments were combined into single segments of up to 128&nbsp;kB, split into an access part and a data part of 0&ndash;64&nbsp;KB each. This reduced the number of object table lookups dramatically, and doubled the maximum virtual address space.

The iAPX432 recognizes fourteen types of predefined system objects:

  • instruction object contains executable instructions
  • domain object represents a program module and contains references to subroutines and data
  • context object represents the context of a process in execution
  • type-definition object represents a software-defined object type
  • type-control object represents type-specific privilege
  • object table identifies the system's collection of active object descriptors
  • storage resource object represents a free storage pool
  • physical storage object identifies free storage blocks in memory
  • storage claim object limits storage that may be allocated by all associated storage resource objects
  • process object identifies a running process
  • port object represents a port and message queue for interprocess communication
  • carrier Carriers carry messages to and from ports
  • processor contains state information for one processor in the system
  • processor communication object is used for interprocessor communication

Garbage collection

Software running on the 432 does not need to explicitly deallocate objects that are no longer needed. Instead, the microcode implements part of the marking portion of Edsger Dijkstra's on-the-fly parallel garbage collection algorithm (a mark-and-sweep style collector). The entries in the system object table contain the bits used to mark each object as being white, black, or grey as needed by the collector. The iMAX 432 operating system includes the software portion of the garbage collector.

Instruction format

Executable instructions are contained within a system "instruction object".