Skip to content
The methodOpen data
Back to the collection

Performance effects of architectural complexity in the Intel 432

Robert P. Colwell, Edward F. Gehringer, E. Douglas Jensen

1988 · ACM Transactions on Computer Systems

AlgorithmsProgramming languages
Read the paper
HN score
1.5
Mentions
3
Readers
3
Months
3
What’s in a score?

From the abstract

The Intel 432 is noteworthy as an architecture incorporating a large amount of functionality that most other systems perform by software. It has, in effect, “migrated” this functionality from the software into the microcode and hardware. The benefits of functional migration have recently been a subject of intense controversy, with critics claiming that a complex architecture is inherently less efficient than a simple architecture with good software support. This paper examines the performance impact of the incorporation of several kinds of functionality into the Intel 432. Among these are the addressing structure, the caches, instruction alignment, the buses, and the way that garbage collection is handled. A set of several benchmarks is used to quantify the performance effect of each of these decisions. The results indicate that the 432 could have been speeded up very significantly if a small number of implementation decisions had been made differently, and if incrementally better technology had been used in its construction. Even with these modifications, however, the 432 would still have only one-fourth to one times the speed of its contemporaries. These figures may represent the real cost of the 432's style of object-based programming environment.

Metadata: Crossref. Abstracts retain their original authors’ rights.

In the conversation

Original HN comments, with labels from simple text rules. A label describes the whole comment and may miss context or irony. Read the discussion to make up your own mind. About the labels

3 selected excerpts · 3 total mentions

klelatti
Strong recommendation · rule
Possibly the fact that the 432 was so slow and the momentum was with the 8086 and successors following the success of the IBM PC. RISC, which in some senses is the polar opposite of the approach taken with the 432, also started to generate a lot of interest at about the same time. There is an excellent paper by Robert Colwell exploring why the 432 was slow and how it could have been speeded up: https://dl.acm.org/doi/10.1145/45059.214411 Colwell was subsequently recruited by Intel and went on to play a major role in the design of the Pentium Pro.
Original comment A look at the die of the 8086 processor
yvdriess
Neutral mention · rule
> > Linear virtual addresses were made to be backwards-compatible with tiny computers with linear physical addresses but without virtual memory. > That is false. In the Intel World, we first had the iAPX 432, which was an object-capability design. To say it failed miserably is overselling its success by a good margin. That's not refuting the point he's making. The mainframe-on-chip iAPX family (and Itanium after) died and had no heirs. The current popular CPU families are all descendents of the stopgap 8086 evolved from the tiny computer CPUs or ARM's straight up embedded CPU designs. But I do agree with your point that a flat (global) virtual memory space is a lot nicer…
Read the full comment
to program. In practice we've been fast moving away from that again though, the kernel has to struggle to keep up the illusion: NUCA, NUMA, CXL.mem, various mapped accelerator memories, etc. Regarding the iAPX 432, I do want to set the record straight as I think you are insinuating that it failed because of its object memory design. The iAPX failed mostly because of it's abject performance characteristics, but that was in retrospect [1] not inherent to the object directory design. It lacked very simple look ahead mechanisms, no instruction or data caches, no registers and not even immediates. Performance did not seemed to be a top priority in the design, to paraphrase an architect. Additionally, the compiler team was not aligned and failed to deliver on time, which only compounded the performance problem. - [1] https://dl.acm.org/doi/10.1145/45059.214411
Original comment Linear Address Spaces: Unsafe at any speed

Keep following the thread.

More in Algorithms

More from the same topics.