D1FRCMV0%EB0UB011.BITNET@cunyvm.cuny.edu (Jordi A Reiss) (06/12/91)
Hello Minixers,
I have got a pretty good article on the future of cpu's and Intel's
position. I know it has nothing to do with Minix, but in some way it has
with the future development of it.
I hope you like it.
_____________________________________________________
Mail-From: GHICKS created at 2-Jun-91 23:29:34
Return-Path: <INFO-IBMPC-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
Date: Sun, 2 Jun 91 08:41:20 +0200
From: "Info-IBMPC Digest" <Info-IBMPC@WSMR-Simtel20.Army.mil>
Subject: Info-IBMPC Digest V91 #135
To: "Info-IBMPC Distribution": ;
Info-IBMPC Digest Sun, 2 Jun 91 Volume 91 : Issue 135
Today's Editor:
Gregory Hicks - Rota Spain <GHICKS@WSMR-Simtel20.Army.Mil>
Today's Topics:
Intel's CPU Wars
Send Replies or notes for publication to:
<INFO-IBMPC@WSMR-SIMTEL20.ARMY.MIL>
Send requests of an administrative nature (addition to, deletion from
the distribution list, et al) to:
<INFO-IBMPC-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
Archives of past issues of the Info-IBMPC Digest are available by FTP
only from WSMR-SIMTEL20.ARMY.MIL in directory PD2:<ARCHIVES.IBMPC>.
----------------------------------------------------------------------
Date: Thu, 23 May 91 02:57:53 PDT
From: Gregory Hicks <ghicks@wsmr-simtel20.army.mil>
Subject: Intel's CPU Wars
Intel's CPU wars The 32-bit struggle for succession
By RON WILSON
Copyright ELECTRONIC ENGINEERING TIMES via NewsNet May 13, 1991
[reposted with permission, edited by Gregory Hicks]
Intel has never faced such severe challenges to its dominance in
the personal computing market. Sun draws an increasing percentage of
its sales from the business sector. The ACE consortium conspires an
alternative platform standard for desktop software. Longtime business
computing power Hewlett-Packard gathers its resources for a full line
of Precision Architecture RISC machines. Yet, Intel is preparing an
answer.
In Hillsboro, Ore., far away from the traditional Santa Clara,
California home of the X86 family, a new CPU is taking shape. It will
draw heavily on RISC technology, including an advanced bus
architecture, a superscalar layout and RISC-like execution units. The
chip will be virtually a company-wide effort, bringing together design
teams that were once bitter competitors within Intel. The tale of the
586 is not just about technical development, but also about management:
how a decentralized company with three competing 32-bit CPU
architectures could evolve into a company able to shift resources among
design teams to target specific markets. Intel will not comment
officially on the evolution of its architectures. But off-the-record
interviews with present and former Intel employees help to shape a
picture of what happened.
The story begins with the 386 firmly in control of the PC market.
However, the 386 is a CISC machine, which means it takes enormous
effort to make it run faster. Each generation of the X86 has taken
more work than its predecessor. Competitors confidently predicted that
the "archaic" X86 architecture was on its last legs. These weaknesses
in the X86 had been recognized long before within Intel itself. That
was in 1980, when a team of architects in the Hillsboro facility set
out to solve the problem by coming up with a design so advanced that it
would be ready to take over when the X86 finally faltered. Using the
latest thinking in modular design techniques and fault-tolerant,
object-oriented architectures - thinking that would still be ahead of
its time today - the designers produced the ill-fated iAPX432.
Although the 432 went nowhere in the market, the concepts survived.
The result was the comprehensive definition of the 960 system
architecture. This was not a design for a 32-bit embedded controller,
but was a master plan for an object-oriented, fault-tolerant, message
passing multiprocessor system. The heart of this architecture was the
streamlined 960 instruction set, that had incorporated many of the
notions of RISC processing. From the beginning, according to sources
close to the project, the 960 was intended to be the central processor
of Intel's future. However, while the 960 team grew around the kernel
of 432 concepts in Hillsboro, a new architecture group was gathering in
Santa Clara. Chartered with solving the numeric-processing bottleneck,
this team sought to combine concepts from the RISC movement and from
Seymour Cray's vector-processing machines into a single revolutionary
piece of silicon.
The result would be the N10, later known as the 860 architecture.
If the charter envisioned the N10 as a numeric coprocessor, the
architects came to see the chip differently. In order to do its job,
the N10 had to be able to execute ordinary, unvectorized code, so it
had to be at base a general-purpose CPU. It soon became clear the N10
was going to be much faster than the 386, then being developed. So, why
shouldn't the N10 step in as a general-purpose, Unix-based CPU to
gradually lift the mantle from the shoulders of the X86 family? To
remain dominant in the PC world, since Intel had to make the
transitions to RISC and Unix sometime, why not make it with a knockout
product? In fact, the N10 team took this story to workstation
developers outside the company, describing the general outline of the
part, the massive numeric performance, and the opportunity to produce a
cost-effective Unix workstation with a single chip in the roles of Unix
engine, FPU and vector processor. There was, to say the least,
interest.
Now Intel had an embarrassment of riches: not one, but three
32-bit architectures. And it faced the very real threat of having
three enormously expensive design efforts and support programs
competing for the uproven desktop Unix market. Even worse, any one of
these efforts might accidentally shatter the X86's DOS-based hegemony
in personal computing, destroying perhaps the most profitable market
dominance in the history of the semiconductor industry. For Intel
management, it apparently was too great a risk.
The three architecture teams saw themselves as competing for the
right to lead Intel into the next generation of computing. And the
competition was none too friendly, according to some company insiders.
But while competition raged at the technical level, a very different
attitude was forming in corporate management. As one observer put it,
there was a growing concern that the X86 family would be eclipsed by
the new RISC efforts. At some point in this process, corporate thinking
underwent a revolution.
Historically, Intel had been a hardware-driven organization-the
correct solution to a given problem was the solution with the fastest
hardware. But now, the company faced the possibility that better
hardware solutions (in the form of the 860 and 960) could kill the
goose that kept on laying golden eggs. So, the corporate emphasis
shifted to software. As one Intel manager put it, "Software is in the
driver's seat-it is the soul of the product." In less philosophical
terms, software support, and not the virtues of the hardware itself,
determine how customers perceive an architecture. So, by controlling
the software support of an architecture, Intel could control customers'
perceptions. And that seemed to be exactly what the company set out to
do with the 860 and 960. One source close to the 860 team said that
there was a time in the project when the designers envisioned the 860
as the main processor in the system, with an X86 serving as a DOS
coprocessor. But to achieve that, the 860 had to have Unix. Intel
stalled on the Unix port-intentionally, in the view of this source.
The lack of Unix permanently relegated the 860 to its original
role of numeric-intensive coprocessing. The move was effective, and it
gave the 860 a clear focus and a niche to dominate. But it was clearly
hard on the 860 design team. Many of them left Intel, because of the
Unix issue, this source said. The corporate hand shaped the 960
strategy as well. This design team also had visions of being the
central CPU in Intel's future, and the team players had embedded many
features in the instruction set architecture specifically for
operating-system support. But, under the new thinking, the 960 would
not get an Intel operating system. Instead, the company nudged the
design team into repositioning the part as a 32-bit embedded processor.
The silicon shed many of the 432-like big-system features and took
on hardware more suited to telecommunications and printer-controller
applications. The two RISC architectures had been successfully
positioned away from the X86. But Intel still had one more problem.
What if the X86 program really did fail to compete with RISC? Each step
in upgrading the architecture was growing more ambitious than the
previous one, until the 586, the development of which took on huge
proportions.
One solution was to borrow concepts from the RISC programs. "The
X86 people view RISC as a capability, not an architecture," said an
Intel insider. In other words, why not build a RISC processor that
happens to execute 486 code? In fact, the 960 team had already done
something similar, devising a RISC-like execution unit for the 960
instruction set. In theory, at least, the instruction set could be
kept static, tying customers to a particular family. Then the
designers could use whatever architectural techniques they chose for
the CPU. And that is apparently what is happening. The center of
design effort for the 586 has shifted from Santa Clara, where the
previous X86s were done, to Hillsboro, where the superscalar 960CA was
designed.
Sources say the 586 will in fact be a CPU with multiple execution
units arranged in a sort of superscalar architecture. The approach
does carry substantial risks. Superscalar architectures need the
load/store instruction streams, single-cycle execution and low
inter-instruction dependencies present in typical RISC instruction
sets. The 486 instruction set, with none of these features, could
require an enormously complex scheduling and dispatch unit. It might
be practical to dispatch whole sections of code to the execution units,
rather than single instructions.
The danger persists that the 586 will turn out to be too slow, or
too complex to finish. Probably no one outside Intel knows the odds.
"The 586 is a big program, but it's Intel's responsibility to do it,"
one insider said. "People won't raise the question of alternatives
until someone stubs their toe." And there are still alternatives.
Throughout the redirection of effort, the 960 project stayed
customer-driven enough to keep satisfying one big customer: the
military. That led to a continuing implementation of the
systems-oriented pieces of the 960 architecture-CPUs with integrated
floating-point, coprocessors to support inter-object communication over
a secure bus, and the like.
Quietly, the 960 team has done a great deal of general-purpose CPU
work for the military. That leaves one advanced architecture - perhaps
the most advanced architecture yet committed to silicon - ready to step
in if the X86 family runs out of gas. So the architecture wars, in a
way, accomplished the purposes of both the architects and the
executives. At least one of the company's advanced architectures was
allowed to develop as a follow-on to the X86, and the X86 was given a
road map into the indefinite future, built on the work of the other
teams.