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.
|