Intel IXP400 Software Considerations and Implications, Coding Pitfalls Little-Endian/Big-Endian

Intel® IXP400 Software

Endianness in Intel® IXP400 Software

Unfortunately, the answer is NO even with help from the most sophisticated hardware.

27.3Software 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.1Coding 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.1Casting 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:

Programmer’s Guide	IXP400 Software Version 2.0	April 2005
	Document Number: 252539, Revision: 007	343