At first glance it seems that there's no real advantage for either little endian or big endian except for compatibility with existing systems. It seems that the choice is essentially arbitrary.
Actually there are real advantages for both endiannesses, though. When designing a system, the advantages and disadvantages should actually weighted against each other instead of choosing by gut feeling. Of course not all of the differences listed below are significant for all systems.
The sub-word scaled by b^i is stored at offset i
(e.g. b = 256 for numbers composed of bytes,
b = 2 when single bits can be accessed).
This simplifies the formula for the number's value,
making it aesthetically more pleasing and easier to remember,
and reduces the risk of bugs in "big integer" arithmetic somewhat.
This property also allows access to a sub-word with a given scale without knowing the length of the number. It is sufficient to know that the sub-word is contained in the number, i.e. the length is not exceeded.
A little-endian number can be incremented or decremented by modifying one bit at a time in ascending order of bit positions. This property is useful for stream procotols.
Big-endian numbers can be compared one bit at a time
in ascending order of bit positions;
the comparison can stop (with the correct result) when the first different
bit is encountered.
Little-endian numbers can also be compared one bit at a time, but the final result is only known when the end of the number is reached.
Big endian is the conventional endianness for strings in western languages,
i.e. words are sorted starting at the first letter,
making the first letter they most significant one.
Most processors therefore have hardware instructions that support big-endian comparison. These instructions can be used for comparison of "big integer" numbers.
The sign of a (2's complement) big-endian number can be determined by checking the first sub-word, without knowing the length of the number.
Back to the main page.
Page created: Apr 09, 2008 -
last update: Apr 10, 2008 -
Jörg Czeranski (Impressum)