3 ms·
I wrote up a blog post about the strengths of each endianness: https://technicalsourcery.net/posts/on-endianness/ https://technicalsourcery.net/posts/on-endian
by kstenerud 5y ago
I wrote up a blog post about the strengths of each endianness:
https://technicalsourcery.net/posts/on-endianness/ https://technicalsourcery.net/posts/on-endianness/
Short short version:
It's all about where your imaginary "margin" is. Little endian works best with "upward growing" data, where the data grows from the low bits into the empty high bits (for example integers). Big endian works best with "downward growing" data, where the data grows from the high bits to the empty low bits (for example fractional portions).
Little endian has the biggest advantages because we use integer types a LOT more than floating point types.
- bear8642 5y agoThanks for blog, very useful analogy. With the odd/even detection section, do you know why the bytes aren't also small to big in Little Endian? That is why isn't the one's bit the leftmost bit?
- kstenerud 5y agoIt's just the convention we've adopted for bit positioning. To the programmer, it doesn't matter since you never actually see sub-byte data, so we just conventionally use the same meaning of shift "left" and shift "right" opcodes regardless of byte-endianness or how the CPU itself arranges the bits. So if we had followed the original Indian endianness, then a shift "left" would divide by 2 and a shift "right" would multiply by 2. All of our troubles stem from not swapping the digits around when we adopted the Indian/Arabic number system in the 10th century - we had to keep up the convention at first because it was compatible, and later because it's "natural".