Endianness - Little and Big Endian

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 Merced architecture. But first, a little background....

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.

Endian-dependencies

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 Merced, almost all UNIX vendors are consolidating around little endian versions of their respective UNIX on Intel operating systems. Only one UNIX vendor, Hewlett-Packard , has decided not to comply with what is fast becoming the industry standard for UNIX on IA-64. HP has chosen to remain big endian for IA-64. Dr. Joseph Reger, Director of Technology Marketing at Siemens Nixdorf, explains, "it is true that HP will not have to do an endian transition, but it is also true that HP's Unix, HP-UX, is probably going to be the only operating system on IA-64 that runs in big endian mode. To my knowledge all flavors of UNIX on IA-64: Solaris, Linux, Santa Cruz Operation's UNIX, Digital's UNIX... and you name it--all UNIX will run on IA-64 in little endian mode and NT certainly will run in little endian mode. Now, there are lots of advantages to that for the enterprise, where you *integrate UNIX and NT*, when you run in the same endian mode as NT." It is important to note that big endian HP-UX for IA-64 functioning in a mostly little endian networked environment will likely hinder application interoperability.

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.

# # #