We will still have to deal with the legacy network protocols that have big endian encoding.
By the way, if you are designing a new network binary protocol, please do not pick big endian, it just makes stuff more complicated on the majority of current cpus.
The only reason that big/mixed endian is even an issue is because some monks fucked up back when the Moors were driven from Spain ... in the wonderful libraries that were left behind they discovered Arabic numbers and realised how useful they were, far better than the clunky Roman ones - for a start a small businessman could do addition just right there on the page, writing the digits from smallest to largest as they went - sadly as I said the monks screwed up and copied the digit order from the right to left written Arabic into western languages without doing the sane thing and reversing the digits so that they continued to be written smallest to largest (so that you could do addition without knowing how much space you needed for digits until you were done).
And so we're stuck with this silly artifact of history that has caused decades of arguing as we slowly rediscover the utility of putting the smaller digits first, as they were always meant to be
In the Unicode characters should be ordered logically (in the order they are interpreted) not visually. Then you use RLM or ALM to indicate right-to-left.
Some IBM systems do number the MSB bits of bytes as bit 0 - to confuse things they are nominally big/mixed endian
The long term good news is that the endian wars are drawing to a close. Little Endian won. I believe all the most recent CPU's support little endian at least as an option.
From what I know from talking to IBM engineers, there are no plans to switch AIX on POWER or Linux on s390x to little-endian.
And both are important platforms in the enterprise world.
They’re not going anywhere.
I know they're not going anywhere, but they're also largely irrelevant to majority of us.
Little endian also allows you to truncate integers more easily.
It's the same kind of thing as computers and calculators switching from decimal hardware to binary hardware 100 years ago.
Not quite. ENIAC, for example, did calculations in decimal, and it was finished in 1945. There may be more recent examples.
If you include binary-coded decimal, that still includes machines made in 1970 or later, like the IBM 1401.
In the days of 8-bit microprocessors, the endianness became visible in software from 16-bit numbers up.
Now it might be visible only for numbers above 64-bit on many CPUs, but there is always a number size above which you must take endianness into account, even for the simplest operations, like comparing and adding.
In theory, you could choose the layout of a large number to have mixed endianness, e.g. to have a large number as a little-endian sequence of 64-bit chunks, where the 64-bit chunks are big-endian, because the CPU used is BE.
However that might make the algorithms even more complex than when you use a consistent endianness.
The endianness of a CPU is not visible in software only when the addressing unit of the memory is the same as the data register size of the CPU.
All modern CPUs have register sizes of either 32-bit or 64-bit, while the memory is addressed in bytes, so the endianness will continue to matter in the foreseeable future.
Some operations start at the least significant end, some start at the most significant end, and it's equally easy to loop over the words in either direction, so i don't buy this.
> Little endian also allows you to truncate integers more easily.
What do you mean by truncate an integer? If you mean go from 32 bit to 16 bit, that's still trivial with big-endian, you just shift.
Surely you would agree that moves are easier than shifts?
Moves can be handled by the renamer and be effectively free (even for memory operands, on CISC, with the advent of memory renamers; but this is even more important for RISC, where what would otherwise have been a load followed by a shift can just be a load), whereas shifts cannot and must take up some fraction of a cycle.
Most mainstream protocols don't really take advantage of this because it is error prone, but it is used sometimes.
We've seen POWER largely migrate to little-endian, as IBM was struggling with sales due to the difficulty in porting software to it, partly due to the endianness difference. (Note that POWER and PowerPC were technically always bi-endian architectures, but the majority of historic hardware had its endianness set by the motherboard in use, and almost everything shipped with big-endian. Systems running Windows NT on PowerPC were some of the very few that ran in little-endian mode.)
We've also seen a similar shift in embedded hardware; bi-endian architectures like ARM and MIPS are now more commonly used in little-endian mode, despite historically being used in big-endian mode.
If you could tell cryptographers this I would be very grateful.