Let's Clear the Air on Endianness
Endianness has become the latest hot topic of high-tech debate. Some would have you believe that one endianness is superior to another. The reality is quite different. The true debate over endianness revolves around a growing industry consolidation around little endianness for Intel's
The Origin of Endianness
The term "endian" can be traced to Jonathan Swift's novel "Gulliver's Travels." In one of Gulliver's adventures, he encounters an island whose inhabitants bitterly argue over the correct way to open soft-boiled eggs - the little end or the big end. Little endians and big endians are each convinced that their method is the only correct method for opening an egg. In computing, the debate over endianness is only slightly less frivolous. With computers, as with eggs, big endian systems and little endian systems perform equally well and neither system is inherently better than the other. The difficulty arises from issues of interoperability.
To explain what endianness means to computing, one must look at how computers store data. Data is a series of bits of 0s and 1s. Eight bits comprise a byte, and it is these eight-bit byte structures that the computer stores. Big endian systems store the most significant byte in the lowest numeric byte address. Little endian systems store the least significant byte in this address. A variety of UNIX® variants exist today, each running in either big endian or little endian mode. Sun's Solaris on SPARC and HP's HP-UX are both big endian, while SCO and DEC's UNIX variants are little endian. NT, though not a UNIX operating system, is also little endian.
The difficulties surrounding interoperability of different endian systems is apparent when a big endian system attempts to read data stored by a little endian system (or vice versa). A little endian system may translate a set of stored bytes as the decimal value 1. A big endian system would translate the same information as 256. Assumptions made by programmers as to the endianness of the processor can result in applications written with endian-dependencies. One can imagine the complexities faced in a networked environment comprised of different endian systems and endian dependent applications. Fortunately, companies like Sun have developed solutions for this dilemma.
NT's Little Endianness
Since 1994, Sun has eliminated any endian compatibility issues by advocating portable, non-endian dependent code for both Solaris on SPARC and Intel. Endian-dependent, non-portable code that cannot be recompiled for a different endianness will create headaches for IT departments planning on big endian and little endian interoperability. With Intel's new family of 64-bit (IA-64) microprocessors code-named
Good For Industry and Consumers
As a result of little endian consolidation around IA-64, Dr. Reger also points out that the best ISV (independent software vendors) support is going to be available for little endian systems. As the industry is well aware, applications development for an operating system can ultimately determine product success. Software vendors have found it easy to deliver applications for Solaris on both SPARC and Intel. Sun's software architecture allows big-endian applications for Solaris on SPARC to run on little endian Solaris on Intel simply by recompiling. In addition, Solaris IA-64 native applications will interoperate with existing IA-32 applications without change or recompilation. For Sun's ISVs and end users this is good news. It means that the Solaris on IA-64 interfaces will be identical to the Solaris interfaces on all other platforms. Sun customers who choose to run Solaris on the IA-64 microprocessor will leverage the 3,167 Intel applications that currently run on Solaris on Intel, without change.
As the industry-leading supporter of platform independence, Sun continues to look for ways to promote standardization like little endianness on IA-64, to make life easier for developers and end users.
# # #