 | Level: Introductory Peter Seebach (crankyuser@seebs.plethora.net), Author, Freelance
27 Sep 2004 Introducing a regular column on the specifications and standards affecting people involved in nearly every aspect of Power Architecture technology, Peter Seebach looks at the different kinds of standards in the industry today, as well as how to find out about and make the most effective use of standards in your own work.
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!
Why standards?
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.
Contracts and compromises
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.
Open standards
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.
Going beyond the standard
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.
Take part
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.
Charting the course
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.
Resources -
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.
About the author | 
| | Peter 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. You can contact Peter at crankyuser@seebs.plethora.net. |
Rate this page
| |
