56

Why are both little- and big-endian still in use today, after ~40 years of binary computer-science? Are there algorithms or storage formats that work better with one and much worse with the other? Wouldn't it be better if we all switched to one and stick with it?

orlp
  • 112,504
  • 36
  • 218
  • 315

3 Answers3

39

When adding two numbers (on paper or in a machine), you start with the least significant digits and work towards the most significant digits. (Same goes for many other operations).

On the Intel 8088, which had 16-bit registers but an 8-bit data bus, being little-endian allowed such instructions to start operation after the first memory cycle. (Of course it should be possible for the memory fetches of a word to be done in decreasing order rather than increasing but I suspect this would have complicated the design a little.)

On most processors the bus width matches the register width so this no longer confers an advantage.

Big-endian numbers, on the other hand, can be compared starting with the MSB (although many compare instructions actually do a subtract which needs to start with the LSB anyway). The sign bit is also very easy to get.

Are there algorithms or storage formats that work better with one and much worse with the other?

No. There are small advantages here and there but nothing major.

I actually think litte-endian is more natural and consistent: the significance of a bit is 2 ^ (bit_pos + 8 * byte_pos). Whereas with with big endian the significance of a bit is 2 ^ (bit_pos + 8 * (word_size - byte_pos - 1)).

Wouldn't it be better if we all switched to one and stick with it?

Due to the dominance of x86, we've definitely gravitated towards little-endian. The ARM chips in many mobile devices have configurable endianness but are often set to LE to be more compatible with the x86 world. Which is fine by me.

Artelius
  • 48,337
  • 13
  • 89
  • 105
  • 1
    Whoa, I never knew the bits of each byte are also stored least-to-most significant. So 10=0x0A is really stored as `01010000` and not binary 00001010? Is this true on BE systems as well? – krubo Dec 23 '15 at 12:29
  • 1
    @krubo The smallest addressable unit is the byte, so it is actually completely arbitrary how you consider the bits to be arranged. How the bits are "stored" within a byte depends entirely on which convention you want to follow. If you carry your convention of choice onto paper, you would indeed write the value 10 as 01010000 in Little Endian and as 00001010 in Big Endian. – Alexander Bolinsky Nov 11 '16 at 23:04
  • @krubo there are all 4 combinations in octet-byte based systems. (Not to mention other options with true word based machines where a whole word is the smallest addressable unit.) So (shortened to 4 bit bytes for readability) if zero is the least significant bit 0123 4567 ; 7654 3210 ; 4567 0123 ; and 3210 7654 are all possible depending on the hardware or network protocol. – Max Power Jan 12 '23 at 21:24
18

Little Endian makes typecasts easier. For example, if you have a 16-bit number you can simply treat the same memory address as a pointer to an 8-bit number, as it contains the lowest 8 bits. So you do not need to know the exact data type you are dealing with (although in most cases you do know anyway).

Big Endian is a bit more human-readable. Bits are stored in memory as they appear in logical order (most-significant values first), just like for any human-used number system.

In times of many, many abstraction layers these arguments don't really count anymore though. I think the main reason we still have both is that nobody wants to switch. There is no obvious reason for either system, so why change anything if your old system works perfectly well?

Daniel Stelter
  • 466
  • 3
  • 6
  • 3
    I don't really follow your typecasts comment. – Artelius Jan 20 '11 at 22:31
  • 1
    On a little-endian system the least significant bits come first in memory. Hence, you could treat this memory pointer as an 8-bit value (you'll get the 8 least significant bits), 16-bit value, etc. You'll always get the correct number of bits in the expected order. On big endian systems you would get the most significant bits, which is not what you expect when typecasting a bigger datatype to a smaller one. – Daniel Stelter Jan 20 '11 at 22:42
  • 1
    Typecasting is usually done in registers, though - otherwise you can't sign-extend and such -- with the exception of a reinterpret cast, in which case you're right, however on some big endian machines, a pointer points to the last byte of a word, not the first, which just furthers all the confusion. – Artelius Jan 20 '11 at 22:48
  • The little endian typecasting trick only really works when you are *narrowing* the data type, e.g. casting a short to a char. For widening you obviously need additional storage and sign extension if casting to a signed type. – Paul R Jan 21 '11 at 12:09
  • 1
    I think he means the retrieval of the memory. The CPU wouldn't have to move where it's looking in memory no matter how big or small the number is. If it's on the CPU in register or cached, the CPU will have to retrieve it, at which point it can reuse the memory address it used last time. However, if it were big endian, it would have to adjust the memory address it used last time. In either system, data on the CPU would have to be retrieved again. (shortening would have the same advantage on the CPU as the data is there regardless). – Lee Louviere May 03 '11 at 17:11
  • This should be the accepted answer. Little Endian makes me super-happy whenever I do reinterpret_cast since I know that this operation will have no overhead whatsoever. In Big Endian systems, every cast across sizes costs you, no matter how simple. – hoodaticus May 15 '17 at 20:56
3

Both big and little endian have their advantages and disadvantages. Even if one were clearly superior (which is not the case), there is no way that any legacy architecture would ever be able to switch endianness, so I'm afraid you're just going to have to learn to live with it.

Paul R
  • 208,748
  • 37
  • 389
  • 560
  • 1
    I'm looking for examples, either generic or specific. – orlp Jan 20 '11 at 21:33
  • 1
    little-endian is (frequently, but not always) useful for home-rolled bignum implementations (that is, use integers larger than the machine word-size). – Vatine Jan 21 '11 at 10:21