Compaq: FreePort Express Big-endian Versus Little-endian Byte Order

United States

| About AMT

Migration Tools
FX!32
FreePort Express
Download
Quick Start
User's Guide
White Papers
DECmigrate

| Performance Tools
| Documentation & White Papers

Big-endian versus little-endian byte order

A computer is said to be big-endian or little-endian depending on whether the least significant bit is in the lowest or highest addressed byte. With its left-to-right byte ordering and least significant bit in the highest byte, the SPARC series of computers is big-endian. In contrast, the Alpha has a little-endian architecture - it orders bytes from right to left. The following figure illustrates the different byte ordering used by the SPARC and Alpha architectures.

The different byte ordering means that SPARC and Alpha systems store multibyte quantities differently. For example, consider the 32-bit (four byte) quantity represented by the hex constant 0x11AABBCC. On either big-endian or little-endian machines, 0x11AABBCC is equivalent to the number 296,401,868, and it is represented in C source the same way. However, the following figure shows the different ways big-endian and little-endian systems store the value 0x11AABBCC. Note that the most significant (big) byte, 0x11, is stored first on the big-endian system and last on the little-endian system.

Figure 1 Byte Order

The different byte ordering means that SPARC and Alpha systems store multibyte quantities differently. For example, consider the 32-bit (four byte) quantity represented by the hex constant 0x11AABBCC. On either big-endian or little-endian machines, 0x11AABBCC is equivalent to the number 296,401,868, and it is represented in C source the same way. However, the following figure shows the different ways big-endian and little-endian systems store the value 0x11AABBCC. Note that the most significant (big) byte, 0x11, is stored first on the big-endian system and last on the little-endian system.

Figure 2 0x11AABBCC on Big-endian and Little-endian Systems

How byte ordering affects translated SPARC applications

How does different byte ordering affect translated SPARC applications? It affects the way the data is loaded into registers, the way native and translated programs can share data, and it affects an application's overall performance.

Byte-swapping to and from registers

Even though a translated program runs on an Alpha system, it still preserves data in big-endian, left-to-right byte order, whether the data resides on disk or in memory. However, whenever the program loads data into a register, the translated program must swap bytes to convert the data to the Alpha's little-endian format. When the register operation is complete, the bytes must be swapped back to the original big-endian format. This conversion happens automatically.

Shared data in mixed native/translated applications

Native and translated programs cannot share binary data without taking into account the big-endian vs. little-endian architectural differences. Otherwise the same binary data residing on disk or in memory looks different to each type of program. The Alpha orders bytes right to left, so the native program looks to the last byte for the most significant bit. Because the SPARC architecture orders bytes in the reverse direction, the translated program looks to the first byte for the most significant bit.

Conversion is not required for ASCII data, a common UNIX format, because of its byte granularity. Conversion may also not be necessary for large database applications. Database systems such as Oracle are written to handle different architectures.So how can mixed applications share binary data? One method is to format data in a way that's architecture-independent by including data conversion routines within the application itself.

Architecture-independent data

When an application includes both translated and native programs and its data is specifically big- or little-endian, the application itself must convert the data. For porting to Digital UNIX, let the Alpha programs perform the byte swapping when reading or writing data. Embed the conversion routines in a macro. Then when you complete the port, you can turn those macros into no-ops since endian data conversion will no longer be required. UNIX includes a variety of subroutines for converting data, including:

- ntoh* - network-to-hosting ordering
- hton* - host-to-network ordering

If you have questions about FreePort Express, send email to fpx-info@scrugs.lkg.dec.com.

| Click to send feedback

privacy and legal statement