Standards and specs, Special Edition: Introducing

A developer's-eye view of the future and implications for Power Architecture standardization

Major electronics companies have come together to form a new standards body focused on Power Architecture technology. This organization will create and promote a family of standards, reference designs, and more. This month's Standards and specs looks at how the new standards body will work, and what it will do.


Peter Seebach (, Author, Freelance

Peter SeebachPeter Seebach has been using computers for years and is gradually becoming acclimated. He still doesn't know why mice need to be cleaned so often, though.

15 December 2004

The Power Architecture™ specification is something of a standard already. After all, you can run PowerPC® code on Motorola® and IBM® chips, and the instruction set has always been governed by the Power Architecture "Books" (see Resources). However, there is more to an architecture than its instruction set, and many fields related to Power Architecture development haven't received as much public scrutiny or standardization.

IBM and other leaders from the electronics industry are launching a new organization, called, which will serve to greatly increase support for developers working with Power Architecture technologies. The creation and promotion of standards is a key element in making this happen. So, this month, instead of looking at a single standard, we'll look at the kinds of planning that go into building a standards organization, and what the implications of this particular standards organization might be.

Note that isn't just a standards organization. This column space, though, is devoted to standards work, so it will focus on that aspect. For more on, see also the companion piece to this article, About:

Thanks must be extended to Bill Dykas and Mark Ireland, of IBM, who gave the interviews used as a primary source for this column.


The history of Power Architecture technology shows an early interest in cooperation and comparative openness. Formed in the late 1980s, the Apple, IBM, and Motorola (AIM) partnership set the stage by establishing the idea that vendors could cooperate on large projects, giving up some of their control in exchange for a broader and more capable product base. The conflict between AMD™'s 64-bit architecture, and Intel™'s 64-bit architecture shows how important it can be to get the right people involved; the fragmentation of the x86 64-bit market highlights the importance of cooperation in maintaining a microprocessor architecture.

IBM and several other companies (see Resources for a link to the full announcement) are coming together to form an organization to expand the collaboration model pioneered by AIM, and to prevent similar fragmentation of the architecture. So far so good: the 64-bit PowerPC implementations are of course compatible, thanks to the Power Architecture "Books," which thoughtfully discussed the 64-bit architecture even before anyone needed to build one (64-bit is not an "extension" to the architecture -- it is the architecture.)

On the other hand, there is a clear potential risk down the road that other vendors or developers could start diverging from the central architecture in ways that hurt the overall market. More generally, there has been some tumult in architecture licensing in the marketplace of late. With, IBM looks to be betting that a more open philosophy will both mitigate potential risks and move the architecture forward.


The scope of standards organizations can be a little hard to predict: I don't think the people who started IEEE in 1963 anticipated the need for floating point math standards (IEEE 754), let alone operating systems (IEEE 1003). In the case of, the overall scope is fairly well-defined, and narrower than, say, the mandate of an ANSI or an IEEE.

On the other hand, that mandate could be pretty broad. It's not just the architecture itself, but just about anything related to it (again, see also the companion piece to this article, especially to see how the mandate of extends even beyond standardization).

But even the standardization part of has a broader scope than a single standard or specification. Should some future generation of Power Architecture chips use a standardized pinout so they can get economies of scale on chip sockets? Should the developers of single-board computers (SBCs) based on PowerPC standardize the address layout they'll use for access to hardware registers or the system's boot ROMs?

The goal, here, is to develop an organization to support and host any and all standards efforts relevant to the growth and development of the Power Architecture market. In particular, the idea is that if everyone plays well with others, the whole Power Architecture market will grow larger, benefiting everyone. If PowerPC chip developers are cooperating and sharing resources, they will produce better chips and better designs, and do so more cheaply.

An ISO standard windmill

Most standards organizations are obliged to cover, well, standards. For everything. ISO, for instance, has standards for fire extinguishers and windmills. It's not that this is a bad thing; it's an excellent thing. But it does mean that ISO can't take as much advantage of domain expertise as a more specialized organization could. can stay focused on standards related to Power Architecture technology, which means you can reasonably assume that its standards will all be in a comparatively narrow segment, dealing with electronics, computer architecture, and software. That's a broad enough range to give room for some interesting standardization work, but it's narrow enough to allow some room for expertise.


Any standards organization needs members. In general, these are often anything from independent experts to large corporations. In the standards organization, membership levels are still being defined. At this phase in its history, they include Participant, Founder, and Sponsor levels (see the developerWorks article, About: The issue of dues also will be refined and tweaked over time; currently they range from about US$25,000-US$100,000 annually. This is a bit steep for end-users -- but quite affordable for vendors. It is also a practical way to try to keep membership focused towards people who have a real economic interest in the platform.

Membership in individual committees or subcommittees might be different from membership in the organization as a whole. For instance, while membership in ISO requires you to be in possession of an actual country, participation on a specific technical committee might be quite a bit more attainable. Many people attend the joint ISO/ANSI® C committee meetings based on US$800/year of dues (regular attendance at meetings is also required).

There is a strong interest in broader involvement from more companies. A lot of people, when they hear the term "Power Architecture," think only of PowerPC processors; and for many, these are very strongly associated with the AIM alliance. The truth is that many other companies are involved in the Power Architecture ecosystem to varying degrees, and the announcement of is one way of formalizing that -- and also of getting those other companies to know one another, and creating a framework for collaboration and communication. It's a community for companies that might want to get involved in building systems, or even chips, using Power Architecture technology -- a place where compiler vendors can talk to embedded developers, and so on.


Standardization is hard work, and specialized work at that. One of the things that can make or break a standard is access to expertise in running standards. A good standards organization can help provide this expertise, organizing committees, helping the members arrange meetings, and providing the infrastructure needed. IBM's involvement with technical standards probably indicates that, in its role as a standards body, will be experienced and effective.

The exact set of technical committees hasn't yet been nailed down. Part of this is the realization that there could be a need for committees to look into things that no one has thought of yet. The basic plan is for a general technical committee that would form subcommittees to look into specific things. The exact structure will probably evolve some over time, but the basic idea is probably reasonable. I have not previously seen such a broad mandate for a committee, and it will be interesting to see how this compares with the "multiple committees" model that other standards organizations have.

Only a few things will stay under IBM's control. Specifically, IBM will continue to own the instruction set architecture -- taking guidance from a special Advisory Council made up of members -- to ensure stability of the core and the instruction set for everyone. Outside of the instruction set, will have free reign.

On the other hand, a committee might, for instance, look into questions related to the needs of developers who want a low-power (no pun intended!) Power Architecture chip. Or, for instance, there might be a committee for PowerPC compiler developers to work on standardizing things like the syntax for vector instructions.

Alignment and liaison work

One of the functions of a standards body is to arrange communications between different groups. Most of the time, liaison work involves different technical standards. For instance, the C standard tries to avoid conflicts with the C++ and POSIX standards.

When Marketing Goes Awry

The concept of nasal fire, from The Hitchhiker's Guide to the Galaxy, is an old favorite for poking fun at the times When Marketing Goes Awry.

The salient portion of the story goes like this:
Marketing girl: When you've been in Marketing as long as I have, you'll know that before any new product can be developed it has to be properly researched. We've got to find out what people want from fire, how they relate to it, the image...
Ford Prefect: Oh, stick it up your nose!
Marketing girl: Which is precisely the sort of thing we need to know! Do people want fire that can be fitted nasally?

This exchange was offered as The Daily .WAV on August 24, 2001. See also Yule Heibel's Post Studio blog for even more of the context surrounding the quote (you'll be glad you did) - as well as a rant on some more times that marketing goes awry.

In the case of, an additional avenue of alignment work becomes possible: alignment with marketers. Now I know what you're thinking. Some marketing departments in the world of tech have very bad reputations (see Resources). And nobody would want a technical standard constrained by the beliefs and goals of entirely non-technical marketers. On the other hand, keep in mind that the converse is also possible: this alignment work could stop people from making promises they can't keep. And think of what a wonderful outcome that could be! If it works, it might even send a message to other large vendors whose marketing and engineering efforts have gotten out of sync.

That isn't to say that supposedly technical meetings will be swamped with marketers asking for fire which can be inserted nasally (see Resources for a link of you are not familiar with that reference). Rather, it means that if the marketing folks want to be sure they're not selling something they can't deliver, they have a good channel to talk to the right people.

Intellectual property rights

When a standard is controlled by a body such as ANSI or ISO, generally the standards body asserts some ownership over the resulting materials, which are sold to help fund the standards body. There has been a lot of talk as of late about the importance of considering intellectual property rights in standardization. What happens if, after everyone's committed to a new standard, someone reveals a patent, and demands licensing fees from anyone trying to comply with that standard? is taking this question into account, in advance, which is a very sensible thing to do. Bill Dykas, manager of Power Ecosystem Development at IBM explains (see the companion piece for more from Bill):

... part of the prerequisite for joining that sort of technical subcommittee is that subcommittees will be formed either on a royalty-free basis or on a RAND basis, a RAND meaning reasonable and nondiscriminatory terms ...

In short, if you want to be involved with a standardization subcommittee, everyone has to agree up front on what the terms will be of any IP used in the standard, and if you don't want to agree to that, you can't push for the use of your patented technology.

This policy is an attempt to preserve some rights for people, while serving the interests of the organization as a whole. The technology industry has seen specs and standards become commercially unusable due to patent issues in the past; this is a good start at preventing that kind of problem up front, and it illustrates the kind of refereeing role that can play for its members.

One weakness in the IP strategy is that this doesn't cover the case where the patent is held by a third party. But then, it's hard to see how the standards organization could do anything about the possibility that someone, somewhere, already has a patent on something that a committee is about to invent independently. What they can do is require people to play fair if they want to be involved with standardization, and right now, it looks like they plan to do just that. Yet another view of the matter is that, when faced with a patent dispute, having a company like IBM on your side can come in quite handy.

Finally, an organization like this can provide a jumping-off point for collaborative work. Members can streamline negotiations, possibly forming a working group rather than trying to hash out every detail of an IP agreement from scratch. A lot of the overhead of collaborative efforts comes down to negotiating IP rights; simplifying those negotiations makes everybody happy and more productive.

Looking forward

The real key, I think, will be the question of what committees or subcommittees get formed, and how their work is received.

I'm hoping to see a lot of interest in developing a variety of standards. Unfortunately, standardization isn't a lightning-fast field, so it may take a while to find out how the first few come out. The danger of forming a new organization is that it's hard for people to be sure how much they're willing to commit to it until they've seen how well it works.

In this case, there's no track record yet for; we don't know how they'll work out. What we do know is that there is a history of comparative openness to Power Architecture technology, and this looks like it has the potential to open it up even more. It is certainly too great an investment on the part of IBM and the other founders to be put down to a public relations stunt, and so I think it will be taken seriously -- I hope also by other chip vendors out there.

The good news is, IBM and the other founders are demonstrating a real commitment to making this standards organization work. If they pull it off, there will be a lot of new standards work in this area in years to come, and that's probably good for everybody.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into developerWorks

Zone=Multicore acceleration
ArticleTitle=Standards and specs, Special Edition: Introducing