Big and Little Endian
Created | Updated Oct 29, 2003
In Johnathan Swift's Gulliver's Travels, the politicians of Lilliput made war over whether eggs
should be broken at the big end or the little end. The same kind of warfare still is waged amongst
the geeky over how to order the bytes in a computer's memory. The term reportedly originated in an
article by Cohen 1 in 1981, although the problem is much older.
It all comes down to which byte in a word of computer memory is
the "most significant" one - the left one or the right one?
Words of memory
Let's start with something that everyone agrees on, which are bits. A bit is the smallest
amount of memory that computers deal with. But a bit by itself isn't very useful. Computer
designers want to group bits together in larger units, each of which has a specific location in
the computer's memory, called an address. These groupings of bits are called words. A word that's 8 bits long is
also called a byte, and in every computer designed in the past two decades, the word size has
been an integer number of bytes in length. The physical design of nearly all computer memory is based on
this concept of sub-dividing words into bytes. More importantly, the numeric value of the address
of each word is not simply which word it is, but which word multiplied by the number of bytes per word.
This convention allows memories of different size to share data and computer programs to store bytes, integers,
and floating point numbers all in the same memory device.
Let the War Begin!
Suppose we have a 32 bit memory design for our computer. This is a memory design in which each memory
location, or address, holds four bytes of information as one contiguous word. So the first memory
entry will have 32 bits of information, and will be located at address 0 (it works out better to
start at 0 and not 1). Now, the next word in memory isn't at address 1, it's at address 4. So what is at
address 1? This is the whole crux of the problem. The contents of memory when read out in smaller pieces
than an entire word will depend on the order in which the bytes in each word are assigned to addresses
'within' each word. The two different orders in which the bytes in a word can be placed are referred
to as big endian and little endian.
For a more detailed look, let's consider a memory with a 32 bit word size with the word at address 0
containing the hexadecimal value $12345678. This can be divided into four bytes of eight bits each
as follows:
| Hex value | $12345678 | |||
| Hex Bytes | $12 | $34 | $56 | $78 |
| Binary | 00010010 | 00110100 | 01010110 | 01111000 |
Little Endian
To the little endians, address 0, when read as a byte, contains 01111000 ($78), address 1
read as a byte contains 01010110 ($56), and so forth. To little endians, address 0 read as a 16 bit value
contains $5678, address 2 read as a 16 bit half-word contains $1234, and address 0 read as a full 32 bit word is still $12345678.
In the little endian word, the least significant byte
in the word has the lowest address. The Intel x86 family and most Texas Instruments DSP computers are little endian.
Another way to show this is with the byte address diagram below:
| Word Address | Most Significant Byte ........ Least Significant Byte | |||
| 0 | 3 | 2 | 1 | 0 |
| 4 | 7 | 6 | 5 | 4 |
Big Endian
To the big endians, storing $12345678 into a 32 bit word at address 0 produces $12345678 when read
back as a 32 bit word, just like in the little endian case. But what's at address 0 when read
as a byte? It contains 00010010 ($12). Address 1 contains 00110100 ($34), and so forth.
A 16 bit read at address 0 contains $1234, and the 16 bit value at address 2 is $5678. Most Motorola
processors including the 68K and PowerPC families (used in Apple computers) are big endian. The big endian scheme is
also shown in the diagram below:
| Word Address | Most Significant Byte ........ Least Significant Byte | |||
| 0 | 0 | 1 | 2 | 3 |
| 4 | 4 | 5 | 6 | 7 |
More complications
Yet another complication is the convention of how to number the bits used to represent the address or
the data values. Nearly everyone has agreed to make bit 0 the Least Significant Bit (lsb) of a byte or
word, and bit 7 the most significant bit. The BIG exception is that IBM made bit 0
the msb (Most Significant Bit) of a byte or word. Since the PowerPC architecture is based on IBM's
POWER RS/6000 microcomputer design, this numbering scheme was adopted into the PowerPC nomenclature.
Bit 31 of a PowerPC word is the least significant bit, not bit 0. The thing to remember, however, is
that this is NOT the same issue as big endian vs. little endian. If both big and little endian
computers access the same memory, once they can figure out which byte to read, the
individual bits will be in the same order on both.
Making Peace
Little vs. big endian is one of those geeky issues which, while seemingly trivial,
turns out to be critical in a world which is trying to do a better job of communicating with itself.
Designers must correctly understand and the endian mode of the
equipment being used if different types of computers and communications systems are to reliably
exchange messages. A computer program may claim to be "platform independent", that is, work correctly
when compiled on different types of computers, but when the programmer is looking at the memory
with a debugger, she will see something quite different for big endian and small endian memory. A computer
program designed to work with a specific piece of hardware will have to accomodate the endian mode of
the host processor. Programming methods which are sensitive to the endian mode of the host are probably the
main reason preventing code (software) from being ported (shared) between different types of
computers, particularly PowerPC (Mac) and Intel x86 (PC).
References
1) Structured Computer Organization, by Andrew S. Tanenbaum. This is the classic undergraduate
text on computer architecture.
2) PowerPC System Architecture, by Tom Shanley. Generally not very well written, but there is an
entire chapter devoted to this issue.
1"On Holy Wars and a Plan for Peace,"IEEE Computer Magazine,vol. 14,
pp 63-68, 1981
pp 63-68, 1981
