Some people don't like to worry too much about standards. As long as the code runs, that's good enough. But tomorrow, you may need to run your code on a different platform, with a different compiler, a different operating system, or just about anything else.
Most people are basically aware that standards are useful in that any two things you buy which comply with a given standard ought to be compatible. Standards, however, are not just a set of buzz words to let you buy something with all the right boxes checked!
If you're a developer building a product, standards give you some idea of which features you can rely on an implementor to offer you. If you're an implementor trying to sell a development system, standards give you a baseline for what people expect. In short, standards let you streamline the process of arguing which features need to be in a system, and they give you a framework for discussing which features are necessary or important to you.
Power Architecture™ technology gives you an environment which presumes some amount of standardization. You can buy a PowerPC® chip from any of several vendors and have reasonable expectations about what the chip will do. You can get a toolkit for designing CPUs which build on the Power Architecture platform and add specific functionality needed for a given task. The standardization of the architecture gives you a head start on development for such a CPU; if you're trying to sell a new CPU, the standard architecture makes your CPU a lot easier (and cheaper!) to target than an entirely new design would be.
The same issues are involved with a programming language. As a vendor selling a development board and host software to target it, you need potential developers to feel that your system won't take too long to learn. Almost no one would expect developers to learn an entirely new language to target a single platform. On the other hand, as a developer reviewing possible development platforms, you want to get as much mileage as you can out of your existing skills and experience.
Hardware standards let everyone share commodity parts. The cost of adapting a system to use an ATX power supply, instead of a custom one, is probably offset by the substantially lower cost of mass-produced, commodity power supplies. Market forces love standardization.
A standard is a lot like a contract between parties. If you sell me a C compiler, you're promising to support the standard language called C, and I'm promising not to whine too much if you don't support a feature that isn't part of the C language, unless you specifically advertised it. A programmer developing in a standardized language is expected to produce valid code in that language; if my code isn't valid, then it's not the vendor's problem that it doesn't do what I want.
Of course, any contract will tend to have some points of compromise. Developers often ask for more rigid specifications of the exact behavior of a language; they also often ask for more and better optimizations. Vendors want more latitude to do things in simpler or more cost-effective ways. A standard offers some kind of compromise.
Often, when people complain about a "bad" standard, it's because they're solidly on one side of the relationship and don't fully appreciate the reasons for the compromise. Vendors may complain loudly and verbosely about the expensive additional requirements; developers may complain just as loudly and just as verbosely about the things that aren't required.
Trying to balance the needs of the various parties to a standard is a lot of work, and it takes a willingness on every part to consider the other people involved. If you don't feel your positions are being considered, you should consider getting involved with the process yourself, as discussed below.
How to get the most use out of standards
The first thing to do is to try to be aware of standards. A standard you don't know about isn't totally useless to you; it still provides you with a more stable marketplace. But that only goes so far; while today, most users benefit from the near-universal compatibility of wireless networks, it wasn't always like that. In the early days of wireless networking, some companies had 11Mbps wireless protocols which were not 802.11b. Some users bought these devices hoping to communicate with other devices and were sadly disappointed. The marketplace eventually killed most of the incompatible competition, but all of the involved parties would have been better off had they taken the trouble to look into whether a standard existed.
Even if your topic ("software interfaces to serial ports") doesn't have a standard, a related standard might exist (perhaps the termios.h part of The Open Group's standard). Larger standards might have parts related to what you're doing,
or smaller standards may cover key components of it.
If you're a developer, try to keep track of which standards affect your development platform. If you're writing in C, familiarity with the state of the C standard helps you make informed decisions about possible compilers and development environments.
If you're an implementor, be aware of what standards do and don't require of you. Some standards have the potential for compliance with a subset, or have optional components. In an ideal world, you'd provide optional support for all such components, but in practice, you want to pick carefully based on customer demand. What you shouldn't do is implement something partially or incompatibly. C has some moderately famous quirks which are directly attributable to vendors who implemented something similar to, but incompatible with, some portion of the standard.
Don't forget that a specification need not be endorsed by a formal standards body to function as a standard. Even a de facto standard, widely enough documented and adopted, can save you a lot of time and money. A standard informally adopted by a half-dozen entities may serve you better than a much more visible standard controlled by only one. What's important is that you have a reasonable idea of what the standard is and how stable it is.
Finding them is half the battle
Finding standards can be a bit of an adventure. Standards organizations include ANSI, ISO, IEEE, and IETF (among the more famous ones). There are plenty of informal standards. Start by browsing Web pages and Usenet posts about the topic you're interested in. If you see people referring to compliance or compatibility, you may have found a standard. It's worth looking around and possibly talking to people working in that industry to see whether any relevant standards exist.
Word of mouth helps, too. I was confronted with the fairly common problem of finding the half-dozen different types of serial cables I needed to have to connect all my computers, and I complained to a coworker, who told me about the Yost serial "standard." This simple mechanism solved my problem. Is it a "standard?" A standards body doesn't endorse it, but it's a workable solution. Note that it doesn't matter whether other offices than mine use this standard; it's enough that I use it consistently internally, and it saves me a lot of time and trouble building cables.
What exactly is meant by calling a standard open is a little vague sometimes. A standard that is not published is certainly not an open standard in any meaningful sense. Ideally, a standard should be open to participation by interested parties and not controlled by any one entity. A standard which is controlled by a single entity can easily be used as a competitive tool against that entity's competition. When this happens, everyone loses -- developers, consumers, and the competition. In many cases, even the entity abusing the concept of standardization ends up worse off for the experience, because open standards are generally more successful than closed standards.
An open standard will generally provide better compromises than a standard controlled by one party, or run entirely in secret. The more people whose inputs and needs are taken into account, the better. The IETF's policies and practices have exemplified this; for instance, the RFC process has consistently produced workable, well-considered standards.
With rare exceptions, standards which require financial outlay by would-be users are not a good bet. Given that a major purpose of standardization is reducing the cost of participation, adding costs is a bad idea. In some cases, patents or other restrictions might control access to a standard; this is often -- though not always -- a bad thing. In some cases, intellectual property rights can be used to protect standards. For example, Philips has refused to allow discs which violate the Compact Disc specification to use the Compact Disc trademark, because they were not compatible with all devices capable of playing compact discs. On the other hand, some companies have tried to use "sleeper patents" to demand royalties from people who, unaware that the patent existed, started using a proposed standard (a famous example of this is the handling of the LZW patent by Unisys, who began demanding licensing fees for the use of GIF files, after they had been in widespread use for a number of years without any licensing fees).
In general, any indication that a standard has a patent should be a bit of a red flag, unless you have clear permission to use them without fees or additional legal hassle.
It's good to talk up the features you offer which are not yet mandated by a standard, as long as you're clear about them being extensions, so people depending on standardization and compatibility don't get bitten. Even though you're offering an "extra" feature, they might be offended by the lack of warning. If you're a developer or customer, it's often good to seek out products with extra features beyond those promised by a standard. However, be wary; if you commit to development depending on an extension a single vendor offers, not only could you be committing to spend a great deal of time and money reworking your development if you have problems with that vendor, but you might face subtle incompatibilities. Sometimes, the reason an extension isn't in the official standard is that it breaks something else that's important. Look for involvement with standardization, published or open specifications, and other signs that a feature is on its way towards being widely available.
If only one entity supports a given extension, be wary of relying on it. Such extensions can be subject to substantial changes without warning and can also lock you into a single vendor for that product; it generally makes better sense to minimize your dependency on a given vendor so you can take advantage of the wonders of competition.
In some cases, a widespread extension is effectively an additional standard. It can be a formal standard, as in the case of IEEE 754 floating point support in C compilers. On the other hand, some extensions and standards are much less formal; for instance, there's a de-facto standard for serial port headers (not DE9 connectors, just ten-pin ports), which is not mandated by any particular body, but everyone seems to have settled on it.
In some cases, standards aren't all-or-nothing. For instance, the C language standard supports both "freestanding" and "hosted" implementations; many of the C standard library features are required only in hosted implementations, and a vendor who is for some reason unable to provide them all can still produce a conforming compiler; it merely has to be called a freestanding one.
As another example, the C standard calls many things "implementation
defined," meaning that, while the language does not specify a design
decision, any particular implementation must specify and document the
decision made. An example is the size of a char object in bits.
One option many people don't consider is getting involved with the standardization process. Many standards groups are fairly open; for instance, people in the U. S. who wish to start attending standards meetings can generally pay dues and start showing up. However, some limitations exist. For instance, if you are an employee of a company already represented on a committee, you may not be able to fully participate. But if your company's business is closely tied to a given standard, it could be worth a lot to have someone actively involved in the process. It would be a little odd for a vendor of compilers for a given language not to participate in its standardization.
Developers, too, can benefit from involvement in the standards process; not only is it a great way to develop a much more detailed understanding of a language or environment, but participation gives you a voice in the future evolution of the standard. I got curious about C standardization a few years ago and started going to meetings of the ISO C standards committee. Not many training programs in the world will teach you as much about C in a couple of weeks a year as attending those meetings. Furthermore, I like to imagine that I have, on a couple of occasions, helped the standards process work as designed.
ISO allows observing members -- members who participate in discussions and read the mailings, but don't actually vote. If you have limited resources for participating in meetings, but would like your voice heard in the standards process, this is a great way to be involved.
If standards relate to anything you do (and they probably do), it pays to be aware of them, and possibly be involved with them. For instance, if you're programming, it's a good bet to have someone on staff, or at least a good contact, who can serve as a language lawyer (see Resources). Try to find open standards when possible and comply as much as possible. Don't be afraid to admit that a standard doesn't quite match your project, but be sure to document such decisions carefully. If you're a vendor, make it as easy as possible for people to tell when they're stepping outside the scope of standard behavior and into your extensions.
And don't worry: we're here to help. Every month in this space we will meet the specs and standards which affect developers involved with Power Architecture. Whether you're developing new Power Architecture chips, embedded prototype boards based on them, or a product using one of those boards, we will navigate them all -- and you can influence that, too, if you drop me a line.
-
See the Jargon file for the definition
of "language lawyer".
-
Governmental standards organizations in the United States include
the National Institute of Standards and
Technology (or NIST) and
The American National Standards
Institute (ANSI). ANSI represents the United States in the
ISO, whose
name derives from the Greek isos rather than any acronym.
-
The
World Wide Web Consortium (W3C) and the
Internet Engineering Task Force
(IETF) are NGOs. You will recognize the IETF as the home of many
(though of course not all) of the RFCs you may have
met.
-
There are many other standards bodies in the US, including the IEEE Standards Association
and The Open Group (the latter is
the keeper of the Single UNIX Specification,
which is not to be confused with POSIX except
when it is because they have
merged.
-
Standards bodies in the US include all of these and more.
We will likely meet them all in coming months; meanwhile, you can
find many of these and a few others listed in
the left-hand nav bar of the
OpenStandards.net page.
Other open standards advocacy groups include
The Open Standards
Alliance,
and the
Open Source Software
Institute.
-
In a ZDNet commentary, Rupert Goodwins criticizes Microsoft for proposing
patent-pending
Sender ID technology as an IETF open standard without making it
royalty-free; IBM and Intel are criticized in the same article for opening
their blade server specs to royalty-free components, but not opening the
chassis design.
-
When record companies started introducing copy protection technologies
that impaired the quality and playability of CDs,
Philips used its Compact Disc trademark to protect a standard format for
media. See also Philips joins
copy protected CD fracas (vnunet.com, 2002).
-
The tried and tested
Yost serial device wiring
standard was invented ages before anything like FireWire had ever
been proposed.
-
Power Architecture technology has an open specification and is considered a de facto standard. IBM is
considering
opening Power Architecture technology to community collaboration.
AltiVec (or VMX, or Velocity Engine) is an SIMD extension to the PowerPC
instruction set, and is an example of a well
documented extension (see also the Freescale
AltiVec manual and the IBM
AltiVec Technology Programming Environments Manual.
-
C started out life as a de facto standard, became an ANSI standard in
1983, and was adopted as an ISO standard in 1990. The latest version of
the C standard is C99. Read more about C at
Wikipedia, the free encyclopedia.
-
The Free Software Foundation's documentation for
GNU Compiler Collection (GCC) includes
Language
Standards Supported by GCC, which
discusses freestanding, hosted, and implementation-specific aspects
of GCC's implementation of C; the self-explanatory Extensions
to the C Language Family, Implementation-defined
behavior, which explains how GCC implements the ISO C specification --
and much
more. And you can even watch how the committee members track the
changes that will go
into the next iteration of the C standard.
- Have experience you'd be willing to share with Power Architecture zone
readers? Article submissions on all aspects of Power Architecture technology from authors inside and outside
IBM are welcomed. Check out the Power Architecture author
FAQ to learn more.
- Have a question or comment on this story, or
on Power Architecture technology in general?
Post it in the Power Architecture technical forum
or send in a letter to the editors.
-
Get a subscription to the Power Architecture Community Newsletter when
you Join the Power Architecture community.
- All things Power are chronicled in the developerWorks Power
Architecture editors' blog, which is just one of many developerWorks
blogs.
- Find more articles and resources on Power Architecture
technology and all things
related in the developerWorks Power
Architecture technology content area.
- Download a IBM PowerPC 405 Evaluation Kit to demo a SoC in a simulated
environment, or just to explore the fully licensed version of
Power Architecture technology. This and other fine Power Architecture-related downloads are listed in
the developerWorks Power Architecture technology content area's downloads section.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
