The Future of x86 and the Concept
of the Instruction Set Architecture
It turns out that the code reusability that the ISA enables is
both a blessing and a curse. As a result of the System/360's pioneering achievement, the
software market is now in a situation where it has huge investments in
a handful of widely used ISAs. Ditching these ISAs would incur such huge economic
costs that for many in the industry it's simply not an option. It was the ISA
that caused the problem of legacy software; before the ISA there was no legacy
software. Thus the ISA (as a concept) has gone from being simply a solution for a
particular set of design problems that early architects faced when designing a
new machine, to being itself an integral part of a new and growing design problem.
Let me explain.
Remember how I said that the ISA was
invented to tackle the problems associated with developing software for a range
of hardware with a range of price/performance points? Well, the operant word in
that sentence is "range." In the same way that a key implies, via its
very design and shape, certain features of the lock for which it was made, an ISA has
inscribed in it some of the features of the hardware that it was
designed to fit. So while an ISA doesn't dictate its own hardware implementation,
certainly implies a range of features and functionality that are necessary for
an optimal implementation
(absence or presence of pipelined execution, microcode or direct execution,
etc.). Furthermore, not only do both CISC and RISC ISAs presume by their very
design certain general features of their own implementations, but that
"presumed features list" itself presumes certain technological
For instance, as I outlined in my
RISC vs. CISC article, CISC
ISAs presume one set of technological conditions (poor compilers, slow/expensive
memory, etc.), while RISC ISAs presume another (good compilers, cheaper/faster
memory, etc). I'll call these technological conditions an ISA's inscribed
technological context, and I'll call these generalized, presumed implementation
features an ISA's inscribed implementation.
So it goes
Technological conditions =>
Important implementation features
If an ISA's designers did their job right, then they identified
and accounted for contemporary computing trends so that many years up the road
the ISA's inscribed technological conditions won't be too different from the
actual technological conditions and thus its inscribed implementation won't be
too different from its actual implementation. I mean,
this makes sense because the list of presumed implementation features is
intended to harness and expose the computing power available with current
technology, and the ISA is supposed to harness and expose the computing power
available with its particular implementation. Therefore, when the actual
technological context suggests functionality and design constraints that
are far afield of what the ISA's designers had originally intended, it's
time to move on to a new ISA.
and Patterson put it another way:
You can design a flawless architecture.
design involves trade-offs made in the context of a set of hardware an
software technologies. Over time those technologies are likely to change,
and decisions that may have been correct at the time they were made look
like mistakes. For example, in 1957 the VAX designers overemphasized the
importance of code-size efficiency, underestimating how important the ease
of decoding and pipelining would be 10 years later. Almost all
architectures eventually succumb to the lack of sufficient address space.
However, avoiding this problem in the long run would probably mean compromising
the efficiency of the architecture in the short run. (John L. Hennessy and
David A. Patterson. Computer Architecture: A Quantitative Approach.
2nd ed. Morgan Kaufmann Publishers, Inc. San Francisco, CA. 1996. p. 111)
As you can probably guess,
this is the case with the x86 ISA. The P6 core is a completely different implementation
that lives in a completely different world from anything that the x86's
original designers had in mind. This fact, coupled with huge installed
base of x86 applications, has resulted in a new design problem that's
almost the same as the old one, but with a corollary:
a. How do you expose the functionality of a range of related
b. ...in a way
that allows software to be easily developed for and ported between those
still maintaining support for legacy ISAs?
As you can
see from the above description, the ISA has gone from being part of the
solution to the portability/functionality problem, to being part of the
I hope it's clear
that at this point that any question as to whether or not x86 is
"obsolete" is now moot. Solutions become "obsolete" when the problems change
around them, and thus "obsolescence" is a term that's associated with
solutions and not problems. Problems become "irrelevant;" solutions
become "obsolete." The x86 ISA was "obsolete" as a solution to the
simple portability/performance problem (the non-corollary version) well before the introduction of the i486, but once we take the x86 ISA out of the
category and place it squarely in the design problem category, we can see
that the language of "obsolescence" is no longer sufficiently descriptive and that a better term is
Until technological conditions change in a way that makes
the problem of x86 legacy code support irrelevant, support for the world's most
popular ISA will be included as a necessary feature in many upcoming designs. Like transistor counts and storage capacities, legacy ISAs are an
entrenched feature of the technological landscape, and computer design decisions
must take them into account. Transistor counts will continue to increase at a
predicable rate, memory will steadily get faster and cheaper, compilers will get
better, and legacy code will continue to be with us in some form.
So once you
take the presence of the x86 architecture (and legacy ISAs in general) as a
given and begin to appreciate such ISAs for the valid and important class of
problems that they represent, you can see how questions about when and where x86
will "hit its limit" are moot. In fact, they don't even make sense.
Instead they become almost like weird koans
What is the sound of one hand clapping?
If a tree falls in the forest and there's no one there to
hear it, does it make a sound?
When will the x86 architecture hit its performance limits?
Once we look at the direction that current and future
architectures are heading, it'll be even more apparent that the question of the
"limits of x86 performance" is an un-question. It no longer exists
as a meaningful way to think about the advancement of computing. The only
question you can ask anymore that even remotely resembles the old obsolescence
question is, "how long will x86 software be around." That's the only
question that makes sense, and the answer is "probably a long, long
Of course, you
can choose to ignore legacy code in your particular project, but there
will always be huge money in legacy code support and it will always be essential
to the industry; these two factors are causing more and more new designs to take
legacy code support into account.