The real chip standard

Referring to Intel's architecture as an industry standard sets an ugly precedent that undermines the spirit of the term "standard".
Written by David Berlind, Inactive

commentary I think that everyone in Intel's public relations department deserves a US$1 million bonus. That's because Intel has scored a PR coup of humongous proportions.

Not only does Intel have vendors like Dell describing its proprietary processors and chipsets as industry standards (as in, "our systems are built on industry standard parts"), but now the media is beginning to validate that undeserved characterization.

A recent Forbes article says, "Intel aimed not just to beat its chip rivals but to bury them. Its ambition was to craft a high-end processor architecture that the entire industry would be forced to use. Grove would devote his company's manufacturing strength to building vast volumes of the chip at a price other chipmakers couldn't meet. That same formula had made Intel's chips the standard in the PC industry." Later, the same article says "Michael Dell made his fortune by relying on industry standards, and the Intel standard has been very good to him."

In its coverage of Sun's latest barrage of announcements, the Boston Globe declares, "Sun Microsystems plans today to introduce a wide range of hardware and software, in an effort to fend off criticism that its computer systems are too expensive and proprietary to compete with the industry-standard systems made by IBM, Hewlett-Packard, and Dell Computer."

For technology buyers, the confusion of standards with proprietary technology has two unfortunate consequences. First, it creates the misperception that compliance, interoperability and compatibility with the so-called standard are guaranteed by an independent standards organization. Second, it creates an opportunity for the intellectual property holder of the proprietary technology to foreclose the competition. Any addiction to proprietary technology puts the vendor of that technology in control of the things that you should have control over--such as cost, security, and performance. Thanks to clones of Intel's 32-bit architecture (IA-32), that situation may not yet exist. But if Intel is ultimately anointed as the industry standard bearer, we may have a problem with IA-64.

Sun CEO Scott McNealy might as well pack up now and go home. After all, the SPARC architecture in Sun's systems is more entitled to be called an industry standard than is anything that comes from Intel's fabs.

Intel's microprocessors are more of an industry commodity than a standard. The term standard should be reserved for specifications that have received the imprimatur of an officially recognized standards body such as ANSI, the IEEE, the ISO, the IETF, or the W3C. When a technical specification for a protocol, programming language or other technology receives the endorsement of one of these organizations, that specification is considered to be ratified as a standard.

Implementing a technology that sticks to the letter of the technical specification should assure users that it will interoperate with other things that are supposedly compliant with the standard. For example, if you buy a hair dryer in the United States, you can be relatively certain that the plug at the end of the device's electrical cord will fit in the receptacles found in most U.S. bathrooms. Standards-folk refer to this concept as "complying with standards and competing on implementation."

Perhaps one reason Intel's microprocessor architecture is misconstrued as a standard is that, historically, devotees of Intel microprocessors (from the 8086 up to the latest Pentiums) have benefited from an ecosystem that behaves in a very standard-like fashion.

Over the years, a variety of software and operating systems have been developed to run on Intel microprocessors. Forgetting Microsoft's antitrust shenanigans for a moment, there have been numerous Intel-compatible alternatives to the desktop and server versions of Microsoft's operating systems and applications. Novell's NetWare, IBM's OS/2, anybody's Linux, and Digital Research's DR-DOS come to mind as substitutes that users have often considered and used with Intel microprocessors because there was an assurance of x86-compatibility from the software vendor.

However, being able to replace the "plug" does not a standard make. If the true test of a standard is being able to make substitutions on both sides (the plug and the receptacle, or the processor and the software) then Intel's x86 architectures have satisfied that test as well--but not because Intel wanted it that way. Competitors such as AMD, Cyrix, IDT, MemoryLogix and Transmeta have come forward with microprocessors that could be substituted for their Intel counterparts in such a way that the software side didn't detect the change. Intel didn't exactly go along with all of this cloning without attempting to enforce its intellectual property rights. Most clones that succeeded, endured, or escaped successful prosecution did so as a result of creative interpretations or renegotiations of long-standing cross-licensing agreements that various parties had with Intel.

This sort of enforcement of intellectual property rights is not the mark of an industry standard, but rather one of popularity. Ironically, competition from the clone makers ended up benefiting Intel in two ways. First, competition kept the trustbusters off Intel's back. It was harder to argue that Intel had a monopoly if substitutes for its chips were available from other manufacturers. Second, the competition made Intel-compatible platforms even more popular.

All this popularity has somehow morphed Intel's microprocessors into being billed as industry standards, which they are not--if you apply the strict definition.

If you're looking for a processor specification that's open for implementation and that has the imprimatur of a standards-setting body, look no further than the specification that Sun has used for the processors it puts in some of its systems. Not only does an IEEE standard exist for a 32-bit version of the SPARC specification (IEEE 1754-1994, but it's a specification that's free to implement provided those who implement it don't use the SPARC trademark.

In the event that you want to put the SPARC trademark on your IEEE 1754-1994-compliant processor, you'll have to pony-up some membership dues and compliance testing fees to SPARC International. Dues and fees help to assure buyers of systems with the SPARC trademark that the microprocessors are certified by an independent party to be compliant (as a result of the testing) with two versions of SPARC: V8 (32-bit) and V9 (64-bit).

According to SPARC International CEO Karen Anaya, the fee for the SPARC Version 8 (32-bit) test suite is US$25,000 and the fee for SPARC V9 (64-bit) is US$35,000 and none of those fees accrue to Sun's coffers. The money goes strictly to SPARC International, a non-profit organization.

Anybody looking to develop a chip based on the IEEE 1754-1994 standard or the SPARC V8 or V9 specifications without paying any fees can do so simply by avoiding the SPARC trademarks. Whereas the IEEE 1754-1994 specification is available for download from the IEEE at no charge, the SPARC V8 and V9 specifications are freely downloadable from SPARC International's Web site. Theoretically, you could download any of the specs, build a chip, put it in a box, and sell it as a system without paying anyone a dime.

Picture a system box with a clever swoosh around the text "IEEE 1754-1994 Inside" or "Cool 64-bit RISC chip inside." Not very catchy, but the restrictions on use of the SPARC brand also offer a measure of assurance to Sun, which turned its 32-bit and 64-bit SPARC intellectual property over to the non-profit SPARC International. Since Sun so closely associates the SPARC brand with its standards (that is, its own standards) for quality and performance, the restrictions on use of the brand prevent a third party from selling a non-SPARC International-compliant system under the SPARC brand, which in turn would tarnish the SPARC name and could affect the perception of Sun's systems.

From an organizational point of view, the Java Community Process (JCP) is very similar to SPARC International in that it upholds the quality of the Java brand through a testing process. But, unlike with SPARC, Sun did not turn over the intellectual property rights for Java to the JCP, and none of the Java specifications have received the imprimatur of a widely recognized standards setting body.

In other words, Java is no more a standard than Intel's processors or the Windows operating system or any other proprietary technology. The one element that makes Java very standard-like, and the reason it is often mistaken for an industry standard, is the way in which many other companies participate in its evolution through the JCP. Most standards bodies operate in much the same way. But, in the JCP's case and much to IBM's chagrin, Sun's intellectual property rights to Java give it veto power. (It's a power that Sun claims it has never used and, to date, no third parties have gone on record to counter that claim.)

The point is that whereas IEEE 1754-1994 is a standard, SPARC is a closely guarded brand. (Java is too, for that matter.) Still, whether I want to develop an IEEE 1754-1994-compliant processor, or the same with the SPARC-brand attached to it, the ground rules for doing so are published and don't discriminate when it comes to who can implement them or how much they must pay. The same cannot be said for any of Intel's architectures. Intel owns the IP to both the 32- and 64-bit version of its processors: IA-32 and IA-64, respectively. For those few with a license (usually a cross-license), Intel has pretty much called the shots. For those without a license, cloning the IA-32 architecture has required a costly clean room implementation.

There's no question that the IA-32 ecosystem appears strikingly similar to the ecosystem that surrounds many real industry standards. Perhaps the most important similarity is how developers flock to it because of the economics it has traditionally offered. Given those economics, it's safe to describe IA-32 as an "industry commodity." But referring to Intel's architecture as an industry standard in the same breath that Sun's offerings are referred to as proprietary sets an ugly precedent that will forever undermine the true spirit of the term "standard" unless we all take more care to protect its meaning.

Editorial standards