Endianess

In almost all modern embedded systems, memory is organized into bytes. CPUs, however, process data as 8-, 16- or 32-bit words. As soon as this word size is larger than a byte, a decision needs to be made with regard to how the bytes in a word are stored in memory. There are two obvious options and a number of other variations. The property that describes this byte ordering is called “endianness” [or, sometimes, “endianity”].

Broadly speaking, the endianness in use is determined by the CPU. Because there are a number of options, it is unsurprising that different semiconductor vendors have chosen different endianness for their CPUs. The questions, from an embedded software engineers perspective are “Does endianness matter?” and “If so, how much?” …

First of all, we need to provide some boundaries for this discussion. I am going to just consider 32-bit CPUs – the same issues apply to 16- and 64-bit devices. Even 8-bit devices typically have instructions that deal with larger data units. I am also going to limit my consideration to the obvious endianness options: least significant byte stored at lowest address [“little-endian”] and most significant byte stored at lowest address [“big-endian”].

There are also other possibilities, like using little-endian within 16-bit words, but storing the 16-bit words inside 32-bit words using big-endian. This is commonly called “middle-endian” or “mixed-endian”, but rarely encountered nowadays. The order of bits within a byte is also potentially arbitrary, but I will ignore that too.

An example of little-endian CPUs is the Intel x86 family. Big-endian CPUs include Freescale 68K and Coldfire. Many modern architectures facilitate both modes and can be switched in software.

There are broadly two circumstances when a software developer needs to think about endianness:

• data transmitted over a communications link or network
• data handled in multiple representations in software

The former situation is quite straightforward – simply a matter of following or defining a protocol. The latter is trickier and requires some thought.

Consider this code:

unsigned int n = 0x0a0b0c0d;
unsigned char c, d, *p;

c = (unsigned char) n;
p = (unsigned char *) &n;
d = *p;

What values would c and d contain at the end? Whatever the endianness, c should contain the value 0x0d. However, the value of d will depend on the endianness. On a little-endian system d will contain 0x0d; on big-endian it will have the value 0x0a. The same kind of effect would be observed if a union were to be made between n and, say, unsigned char a[4].

So, does this matter? With care, most code may be written to be independent of endianness and I would contend that almost all well-written code would be like this. However, if you do build in an endianness dependency, as usual, good documentation/commenting is obviously essential.

This entry was posted on Thursday, August 16th, 2018 at 2:27 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.