> Variable length encoding with a prepended length field<p>The OP's method only works under the following assumptions: (1) length in bytes is power of 2 so the re-interpret trick works, and (2) the complete source data is in memory.<p>In many popular formats (MKV, WebM, etc) the header is variable-length as well e.g. 1-8 bits, the complete integer is therefore [ 1 .. 8 ] bytes, and because these files can be very large they don't fit in memory, need to stream from disk.<p>Under these conditions, the big-endian format (a) eliminates need for any bit shifts, only need to mask away the header in higher bits, slightly faster on most CPUs (b) preserves original bytes in the number except the MSB which contain the header, helps with debugging.<p>I think that's the only use case where big endian has a substantial advantage. Fortunately, all modern CPUs have fast instructions to flip the endianness, e.g. on Intel/AMD they are bswap for 4 or 8 bytes, ror/rol for 2 bytes, available as intrinsic or standard library functions in most programming languages.<p>For all other cases, including binary formats I design, I only use little-endian convention. Little-endian CPUs have won, and I don't like doing unnecessary work flipping these bytes. I'm lazy, also a boilerplate like that is a common source of bugs.
In the old days of satellite development (40 years ago at Hughes Space & Communications), I observed that the bit order in digital subsystems was always Big Endian, but all the other subsystems were usually Little Endian. Sometimes this caused issues, which fortunately were discovered during the integration & test phase. Usually problems like this were "corrected" by altering the documentation instead of the hardware so for a while, the majority of satellites in Earth orbit had a strange mix of endianness throughout the subsystems. The digital culture eventually won at Hughes/Boeing, but the standards committee punted and allows the endianness to be arbitrary (as long as it's documented) in the CCSDS standards.<p><a href="https://public.ccsds.org/default.aspx" rel="nofollow">https://public.ccsds.org/default.aspx</a>
TFA's claims about advantages are nonsense. E.g., for "detecting odd/even" it gives the advantage to little-endian but without considering at all how that might be implemented in hardware, or even without explaining at all why there's an advantage to be had.<p>Or when talking about bignums:<p>> Although this scheme can be realized with either byte order, there is an extra advantage to little endian byte ordering: If the CPU is little endian, you wouldn’t even need to care about the element size in the array because the bytes would naturally arrange themselves smoothly in little endian order across the entire array.<p>But the same is true for big-endian! The array indices will run the opposite way, but so what?<p>This seems aimed at forcing the conclusion that little-endian is better. There's no real advantage to one or the other. The world just has both, and we have to deal with it.
Little-endian makes more sense for computers where calculation is most important. Big-endian makes more sense for humans where, I would argue, <i>comparison</i> is most important. If I want to know e.g. if I can afford something, I'd prefer hearing the price as "four hundred and ..." to instantly get a ballpark rather than "five and ninety and four hundred".
The article has some bugs. Alphabets in India (for as far back as we have written records, e.g. Pali) were all LTR until Muslim rule was established at which point some people began to write Hindi using the Persian/Arab script (giving rise to Urdu, a very close sister language to Hindi).<p>Also network order is big endian because most of the machines back then were big endian, most notably the PDP-10 which was the common research machine in that era. Big endian offered simplicity in implementation (remember the earlier models of these machines were mostly hand made, even if made in a factory, with only a few semiconductors; the ALUs and instruction decoding was all done with wires, not traces). Bytes weren't necessarily 8 bits wide and while it was trivial (easier than in C actually) to do pointer arithmetic, a "pointer cast" is a weird way to think of it.<p>So the article is full of the assumption that the world is basically a PDP-11. I think the obsession with such machines has held computing back as much as it has sped it up.
OK, temporarily-victorious little-endians: Explain how you find it perfectly natural that the bits in a byte are big-endian?<p>[Various replies (and votes) indicate I had better edit to clarify:] How come the single byte value written as 0x12 means "eighteen" and not "thirty-three"? Shouldn't the two four-bit nibbles also be considered as little-endian? Or it could even mean "seventy-two", if the bits are little-endian as a whole?
A few weeks ago I read the original paper where the names big endian and little endian came from and was really surprised that it was published in 1980!<p>So, before then we didn't have a common way of describing this I guess. It's crazy to me if true.<p>Good paper BTW. Worth reading.
Some of these advantages are pretty dubious. Detecting whether a number is odd or even or getting the sign bit aren't impacted by endianness, as the CPU isn't working with single bytes at a time.
1. Network Byte Order is Big Endian.<p>2. x86, ARMv8 and RISC-V are Little Endian.<p>3. IBM 360 through s390x are Big Endian.<p>4. MIPS, PowerPC and ARM can be bysexual.
Was Hindu (I assume that’s the original language for which Indo-Arabic numerals were made for) written right to left ? I know Arabic was but I don’t think Indian languages ever have been.
This is a decent attempt. I like that they actually at least try to find pros/cons.<p>But it does seem odd that they give "convention" to big endian despite the fact that basically all modern processors are little endian and there's absolutely no advantage to following "network byte order" if you don't have to.
What do you think about the fact that the linked rfc from<p>[-] <a href="https://www.rfc-editor.org/ien/ien137.txt" rel="nofollow">https://www.rfc-editor.org/ien/ien137.txt</a> dates from <i>APRIL the FIRST 42</i> years ago?<p>Could/would/should it matter?