eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Discuss this in the eWEEK forum.
If you were designing a human language from scratch, you probably wouldnt wind up with English, observed AMD CTO Fred Weber in his keynote speech this month at the Microprocessor Forum, in San Jose, Calif. Even so, Weber continued, that doesnt make it the wrong language to choose today for conversational convergence. Weber then advanced a parallel argument in favor of retaining and extending the x86 instruction set as the lexicon of enterprise IT. As much as I resist that conclusion, its illuminating to consider the reasons why “x86 everywhere”—as Weber labeled his argument—looks more plausible today than it did 10 years ago.
Both English and the x86 instruction set are irregular languages with many special cases. But both are also expressive languages, easily extended and broadly supported by a huge body of work and a trusted base of tools and skills.
Theres a clear historical path to x86-centric IT that begins in 1983, when Lotus 1-2-3 trounced VisiCalc and Context MBA to become the definitive tool of the corporate PC user. VisiCalc was hamstrung by its 8-bit Apple II/III platform; Context MBA, written in highly portable UCSD p-System Pascal, took literally minutes to do spreadsheet manipulations that 1-2-3 did in seconds. Lotus bet big on writing fast, low-level code that took full advantage of every resource of the x86 architecture. X86 machine code became the language of software success.
In the early 1990s, it was the conventional wisdom that the irregularities of x86 code—particularly its instruction codes of varying length—would prevent the continuing speedup of processor clock rates. Uniform length, consistent format and general access of any instruction to any on-chip data register were considered necessary aids. As a machine-level coder myself, it made sense to me.
Microsoft therefore introduced Windows NT as a multiplatform operating system, initially planning support for the more modern designs of the MIPS, PowerPC and Alpha processor families as well as x86. Work on NT/MIPS ended, though, in 1996, and on NT/PowerPC in 1997; Microsoft and Compaq jointly killed NT/Alpha at the end of 1999. Windows 2000 marked Microsofts return to x86-centric development, and Microsofts heart remains with that architecture. When shipments of AMDs Opteron and Athlon 64 processors overtake the installed base of Intels Itanium units around the end of this year, the 2-year-old Windows/Itanium will find its best days already behind it.
And Linux, let it be remembered, also has its roots and finds much of its continuing vigor in x86-specific code. Indeed, it was originally written as much to explore the facilities of the 386 chip as to create a new operating system.
Webers key argument is that a combination of technology, history and the cost structure of enterprise IT have brought us to a point where the arguments against the x86 are now academic, but the offsetting incentives for expanding its use are compelling. Decoding and optimizing those complex x86 instructions is looking increasingly affordable in silicon, while the Itaniums “explicitly parallel” design is unavoidably costly in terms of caching and fetching its verbose instructions.
Software testing, at the low level required to ensure security against ingenious attacks, has never been as strong a concern as it is now. Although “portability is good,” as Weber acknowledged, “porting isnt. Testing is incredibly expensive.”
Weber noted that “any new application that can be delivered at a higher level of abstraction, using a high-level technology like Java or .Net, should be. There are advantages.” Remember that; its important. But only the most widely used software suites can bear the multiplatform testing burden, he argued, and I have to concede that the market supports him. For specialized tasks, I often find the necessary tools in x86-only formats.
I prefer platform choice. I commend efficient architectures like those of ARM, of which AMD is a licensee. I respect the high-throughput power of IBMs Power4 and Power5, and Apples Power Mac G5. But the search for the True Right Way to do something is dangerously seductive to those who enjoy the technical exercise. The Good Enough Way of the x86 can be far more cost-effective, and that bodes very well for AMD.
Discuss this in the eWEEK forum.
Technology Editor Peter Coffees e-mail address is peter_coffee@ziffdavis.com.