Why little endian!

[thewrongchristian]

The one place endianness really makes a visual difference is in bitmap displays, and there, big endian matches what's on the screen.

These days, with 32-bpp displays, even that is not significant any more.

It's all just a pain in the arse. I'm putting together my USB stack, which is predominantly little-endian, but at some point I'll be using it to push across SCSI command blocks, which are big-endian.

[SpaceAcoustics]

I dont know why the choice was made, but as someone who prefers little edian in cpu design, its mainly due to the fact that you can take the same address and load it at different byte witdths without having to think about adding 1 to 4 to the address due to the edianess.

[bloodline]

It just the bytes which are stored in reverse order of what you would expect when reading and writing binary numbers.

That's not entirely true.

The bits are probably also in little endian (though there is no guarantee of this).

But this is a CPU implementation detail. Since the byte is the smallest addressable unit, so there's no way for us programmers to tell the difference.

Actually, when doing bitwise operations, bits being ordered in little endian can be quite confusing. (i.e, when masking off the top four bits of a number, you must do "num & 0x0fff")

Only if you loaded the bytes into memory sequentially... if you read a little endian word from storage, then you can treat it as a normal binary.

[Sik]

Gotta love how the consensus these days seems to be "because it allows you to resize integers" (though on big endian you can achieve the same by apply an offset to the address as needed)…

There's another argument for little-endian, but it doesn't apply to many OSs: In arbitrary-precision calculations, adding or subtracting numbers needs to start with the low digits for the carry to propagate correctly. (Yes, even though you borrow in the other direction when doing subtraction longhand. 2s complement is awesome like that.) I don't know about multiplication and division.

…but I believe this is the correct answer, at least originally. Don't forget that the difference between little and big endian dates back to the earliest CPUs, and especially was critical with the 8-bit ones (e.g. on 6502 anything larger than 8-bit was in the realm of arbitrary precision), and even for CPUs that could work on larger data it gave the possibility to start performing the calculation before the whole number was fetched (though I'm not sure how common that actually was).

Not so important nowadays, but it stuck and x86 was originally designed back when this kind of stuff was still relevant too. There really isn't much of a difference other than big endian being seemingly easier to read (and only because of how we lay out bytes in writing, shouldn't they be really right to left and bottom to top? we do say that higher memory addresses are at the "top" of memory after all…)

[linguofreak]

I'll note that whether big or little endian seems more "natural" depends greatly on how it is presented visually. When reading left-to-right with arabic numerals with the LSB on the right, Big Endian seems most natural:

Code: Select all

Increasing addresses ------------>
Big Endian: DE AD BE EF
Little Endian: EF BE AD DE

But sometimes a vertical presentation of addresses with high addresses being higher on the page and lower addresses being lower is helpful (because high addresses being located higher than lower addresses is a useful mnemonic device). In this case, Little Endian seems most natural:

Code: Select all

^    Big Endian:            Little Endian
|     EF                         DE
|     BE                         AD
|     AD                        BE
|     DE                        EF
|
|
|
| Increasing addresses

But then again, sometimes a vertical presentation with higher addresses being lower on the page is used (because in the usual reading order for western languages, a lower position on the page is later than a higher position). In this case, Big Endian becomes more intuitive again.

But keep in mind that the document in which "Big Endian" and "Little Endian" were first applied to byte order was titled "On Holy Wars and a Plea for Peace", and that it was written in 1980. Enough people have held the opinion that either byte order is "superior" or "more natural" strongly enough for the debate to be labeled as a "holy war" for at least 40 years now. It will continue to be hotly debated for the foreseeable future.