Andy Grove blamed the i860's failure in the marketplace on Intel being stretched too thin:
The i860 combined a number of features that were unique at the time, most notably its VLIW (Very Long Instruction Word) architecture and powerful support for high-speed floating point operations. The design mounted a 32-bit ALU along with a 64-bit FPU that was itself built in three parts, an adder, a multiplier, and a graphics processor. The system had separate pipelines for the ALU, floating point adder and multiplier, and could hand off up to three operations per clock. (I.e., two instructions - one integer instruction and one floating point multiply-and-accumulate instruction per clock.)
All of the buses were 64-bits wide, or wider. The internal memory bus to the cache, for instance, was 128-bits wide. Both units had thirty-two 32-bit registers, but the FPU used its set as sixteen 64-bit registers. Instructions for the ALU were fetched two at a time to use the full external bus. Intel always referred to the design as the "i860 64-Bit Microprocessor".
The graphics unit was unique for the era. It was essentially a 64-bit integer unit using the FPU registers. It supported a number of commands for SIMD-like instructions in addition to basic 64-bit integer math. Experience with the i860 influenced the MMX functionality later added to Intel's Pentium processors.
One unusual feature of the i860 was that the pipelines into the functional units were program-accessible, requiring the compilers to carefully order instructions in the object code to keep the pipelines filled. In traditional architectures these duties were handled at runtime by a scheduler on the CPU itself, but the complexity of these systems limited their application in early RISC designs. The i860 was an attempt to avoid this entirely by moving this duty off-chip into the compiler. This allowed the i860 to devote more room to functional units, improving performance. As a result of its architecture, the i860 could run certain graphics and floating point algorithms with exceptionally high speed, but its performance in general-purpose applications suffered and it was difficult to program efficiently (see below).
Paper performance was impressive for a single-chip solution; however, real-world performance was anything but. One problem, perhaps unrecognized at the time, was that runtime code paths are difficult to predict, meaning that it becomes exceedingly difficult to properly order instructions at compile time. For instance, an instruction to add two numbers will take considerably longer if the data is not in the cache, yet there is no way for the programmer to know if it is or not. If you guess wrong the entire pipeline will stall, waiting for the data. The entire i860 design was based on the compiler efficiently handling this task, which proved almost impossible in practice. While theoretically capable of peaking at about 60-80 MFLOPS for both single precision and double precision for the XP versions, hand-coded assemblers managed to get only about up to 40 MFLOPS, and most compilers had difficulty getting even 10 MFLOPs.
Another serious problem was the lack of any solution to quickly handle context switching. The i860 had several pipelines (for the ALU and FPU parts) and an interrupt could spill them and require them all to be re-loaded. This took 62 cycles in the best case, and almost 2000 cycles in the worst. The latter is 1/20000th of a second, an eternity for a CPU. This largely eliminated the i860 as a general purpose CPU.
The chip was released in two versions, the basic XR (code named N10), and the XP (code named N11). The XP added larger on-chip caches, a second level cache, faster buses, and hardware support for bus snooping, for cache consistency in parallel computing systems. The XR ran at 25 or 40MHz, and a process shrink for the XP (from 1 micrometre to 0.8) bumped the XR to 40 and 50MHz. Both ran the same instruction set.
At first the i860 was only used in a small number of very large machines like the iPSC/860 at Los Alamos National Laboratory. As the compilers improved, the general performance of the i860 did likewise, but by then most other RISC designs had already passed the i860 in performance.
Intel for a time tested the viability of the i860 as a workstation CPU, competing with the MIPS Architecture chips and others. Microsoft initially developed what was to become Windows NT on internally-designed i860-based workstations (codenamed Dazzle), only porting NT to the MIPS (Microsoft Jazz), Intel 386 and other processors later. It is often rumoured that the original meanings of the 'N' and 'T' in Windows NT was for "N-Ten", after the working name for the i860 core.
The i860 did see some use in the workstation world as a graphics accelerator. It was used, for instance, in the NeXTdimension, where it ran a cut-down version of the Mach kernel running a complete PostScript stack. However, the PostScript part of the project was never finished so it ended up just moving color pixels around. In this role the i860 design worked considerably better, as the core program could be loaded into the cache and made entirely "predictable", allowing the compilers to get the ordering right. Another example was SGI Onyx Reality Engine 2, which used a number of i860XP processors in its geometry engine. This sort of use slowly disappeared as well, as more general-purpose CPUs started to match the i860's performance, and as Intel turned its focus to Pentium processors for general-purpose computing.
Mercury Computer Systems used the i860 in their multicomputer. From 2 to 360 compute nodes would reside in a circuit switched fat tree network, with each node having local memory that could be mapped by any other node. Each node in this heterogeneous system could be an i860, a PowerPC, or a group of three SHARC DSPs. Good performance was obtained from the i860 by supplying customers with a library of signal processing functions written in assembly language. The hardware packed up to 360 compute nodes in a 9U space, making it suitable for mobile applications such as airborne radar processing.
In the late 1990s Intel replaced their entire RISC line with ARM-based designs, known as the XScale. Confusingly, the 860 number has since been re-used for a motherboard control chipset for Intel Xeon (high-end Pentium) systems.
2. Margulis, Neal, i860 Microprocessor Architecture, 1990.
Multiprocessor bus links microprocessors with 160-Mbyte/ sec crossbars. (Mercury Computer Systems Inc.'s Race multiprocessing architecture) (Product Update) (Product Announcement)
May 13, 1993; Solving massive computational problems with microprocessor ([mu]P) arrays is an attractive design option for performance reasons,...
Superscalar SPARC executes as many as three instructions in parallel. (Scalable Processor Architecture) (EDN-Processor Update)
Jun 04, 1992; The Texas Instruments' third-generation RISC microprocessors ([mu]Ps) are the first superscalar implementation of the SPARC RISC...