Filter
Top Products
Intel
®
IXP400 Software
Endianness in Intel
®
IXP400 Software
Programmer’s Guide IXP400 Software Version 2.0 April 2005
Document Number: 252539, Revision: 007 343
Unfortunately, the answer is NO even with help from the most sophisticated hardware.
27.3 Software Considerations and Implications
Much literature is available explaining the software dependency on underlying hardware
endianness.
In summary, software dependency on hardware endianness is manifested in these areas:
• Whenever a piece of software accesses a piece of memory which is treated as different sizes by
manipulation of pointers in different parts of code, that code is endian-dependent. For
example, IP address 0x01020304 can be treated as unsigned long. But if code needs to access
byte 0x04 by manipulating pointers, the code becomes endian-dependent.
• If a piece of memory is accessed by other hardware or processors whose endian modes are
independent of the processor on which the current software is running, then the current code
becomes endian-dependent. For example, network data is always assumed to be Big-Endian. If
network data is directly moved (DMA’ed) into memory as it is, then that particular piece of
memory is always Big-Endian. As a result, the current code accessing that piece of memory
becomes endian-dependent. If pointers are passed between processors, endian issues show
immediately because of the fundamental difficulty, as explained in “The Nature of Endianness:
Hardware or Software?” on page 342.
• The above issues can occur in many places of an operating system, a hardware driver, or even
a piece of application code. Some operating systems (for example, VxWorks*) support both
endians by different compilation switches.
• Compiler, debugger, and other tools are generally endian-dependent because the translation
between a high-level language (for example, C) and assembly language is endian-dependent.
Under certain application assumptions, and when programming carefully, it is possible to have a
piece of code that is endian-independent.
27.3.1 Coding Pitfalls — Little-Endian/Big-Endian
The risks associated with programming in mixed endian system generally revolve around possible
incompatibilities in the interpretation of data between Little-Endian and Big-Endian components
within the system. The following examples illustrate some instances where pitfalls in coding can be
interpreted differently on LE versus BE machines (and thus should be avoided). There are also
examples of how to code a module in a way that permits a consistent interpretation of data
structures and data accesses in general, regardless of the endianness of the processor the code may
be running on. Performance can also enter into the equation, especially if byte order needs to be
frequently shuffled by the processor.
27.3.1.1 Casting a Pointer Between Types of Different Sizes
The situation that this example illustrates needs to be avoided completely. Do not mix pointer sizes.
Endianness causes different interpretation from one machine to the next, making porting
problematic.
int J=8;
char c = *(char *) J;
Depending on the endianness of the processor the code is executing on, the result is: