Live data from Hacker News

Endian wars and anti-portability: this again?

dalmatian.life

31–40 of 73 posts

Re: Endian wars and anti-portability: this again?

#31
The whole thing rests on these assertions:

> It is usually easy to write code that is endian-safe. Any code that is not endian-safe is poorly written and harder to maintain at best, and possibly obscuring security bugs at worst. Any project maintainer should be jumping for joy when they receive a patch adding a big-endian port of their project, especially if it includes reports that tests pass and the software works. That is the sign of a codebase that has a level of sanity that should not be noteworthy, yet is.

And every single sentence is false.

The tower collapses once you remove any of the bases, let alone all of them.

Re: Endian wars and anti-portability: this again?

#32

The glaring omission from that long post is the term "opportunity cost". Ensuring a code base indefinitely supports arbitrary architectures carries a substantial code architecture cost. Furthermore, it is difficult to guarantee testing going forward or that the toolchains available for those architectures will continue to evolve with your code base. I'm old enough to have lived this reality back when it was common. I…

> Today, I explicitly only support two architectures: 64-bit x86 and ARM (little-endian). It is wonderful that we have arrived at the point where this is a completely viable proposition. In most cases the cost of supporting marginal users on rare architectures in the year 2026 is not worth it.

This - and efforts to reintroduce BE should be resisted in the same way as people who want to drive on the other side of the road for pure whimsy.

I note that we've mostly converged on one set of floating point semantics as well, although across a range of bit widths.

Re: Endian wars and anti-portability: this again?

#33

The glaring omission from that long post is the term "opportunity cost". Ensuring a code base indefinitely supports arbitrary architectures carries a substantial code architecture cost. Furthermore, it is difficult to guarantee testing going forward or that the toolchains available for those architectures will continue to evolve with your code base. I'm old enough to have lived this reality back when it was common. I…

> Ensuring a code base indefinitely supports arbitrary architectures carries a substantial code architecture cost.

I'd say just the opposite; it nudges you towards well-factored approaches and ultimately carries a code architecture benefit, just like having automated tests or using structured programming.

Re: Endian wars and anti-portability: this again?

#34
I'm glad I did my undergrad at UC Davis in the mid '00s that valued portability and well-defined behavior rather than proprietary or implementation-specific, non-portable assumptions. The lazy, rationalizing throwing out the baby with the bathwater folks are disappointments to engineering excellence.

Re: Endian wars and anti-portability: this again?

#35

Earlier quoted context omitted.

No, BE is logical because it puts bits and bytes in the same order. That humans use BE is also nice but secondary to that. I don't have strong feelings about whether fifty-one thousand nine hundred sixty-six is written as 0xcafe or 0xefac, but I feel quite comfortable suggesting that 0xfeca is absurd. (FWIW, this is a weak argument for what computers should do; if LE is more efficient for machines then let them use i…

> No, BE is logical because it puts bits and bytes in the same order. This sounds confused. The "order" of bits is only an artifact of our human notation, not some inherent order. If you look at how an integer is implemented in hardware (say in a register or in combinational logic), you're not going to find the bits being reversed every byte.

Okay, if you get everyone to write bits the other way I'll endorse LE as intuitive/logical. Until then, I want my bits and bytes notated uniformly.

Re: Endian wars and anti-portability: this again?

#36

Earlier quoted context omitted.

No, BE is intuitive for humans who write digits with the highest power on the left. LE is logical which is also why it is more efficient and more intuitive for humans once they get past “how we write numbers with a pencil”.

No, BE is logical because it puts bits and bytes in the same order. That humans use BE is also nice but secondary to that. I don't have strong feelings about whether fifty-one thousand nine hundred sixty-six is written as 0xcafe or 0xefac, but I feel quite comfortable suggesting that 0xfeca is absurd. (FWIW, this is a weak argument for what computers should do; if LE is more efficient for machines then let them use i…

My contribution: largest-order-first (big endian) makes sense in real life because people tend to make quick judgements in unreliable situations. For example, take the announcement that you're receiving $132551 dollars. You wouldn't want to hear something like "Hello! You have been awarded one and fifty and five hundred and... and one hundred thousand dollars!", you want to hear "You have been awarded One hundred and thirty two thousand and ... dollars!" The largest sums change decisions dramatically so it makes sense they come first.

On computers however, we basically always use exact arithmetic and exact, fixed logic where learning the higher order doesn't help (we're not doing approximations and decisions based on incomplete information), in fact for mathematical reasons in the exact cases it's usually better to compute and utilize the lowest bits first (e.g. in the case of sums and multiplication algos I am familiar with). [note1]

Overall I'm slightly surprised some automatic/universal translation methods for the most common languages haven't been made, although I guess there may be some significant difficulties or impossibilities (for example, if you send a bunch of bits/bytes outside, there's no general way to predict the endianess it should be in). I suspect LLMs will make this task much easier (without a more traditional universal translation algorithm).

[note1] Also, the time required to receive all bits from say a 64b number as opposed to the first k bits tends to be a negligible or even 0 difference, in both human terms (receiving data over a network) and machine terms (receiving data over a bus; optimizing an algorithm that uses numbers in complicated ways; etc.), again different from human communication and thought.

Re: Endian wars and anti-portability: this again?

#37

If you want to keep software working on systems with a 9-bit byte or other weirdness, that's entirely on you. No one else needs or wants the extra complexity. Little endian is logical and won, big endian is backwards and lost for good reason. (Look at how arbitrary precision arithmetic is implemented on a BE system; chances are it's effectively LE anyway.)

LE is not "logical", it won because the IBM PC compatible won, simple as that.

Re: Endian wars and anti-portability: this again?

#38

> Big endian systems store numbers the way us humans do: the largest number is written first. Obviously the author was trying to just give a quick example to aid visualization, but here's some nitpicking: I can probably come up with at least IV writing systems used by humans that don't use "big endian" for numbers. Or either, really. Examples: Tally marks, Ancient Egyptian numerals, Hebrew and Attic numerals, and obv…

Roman numerals are big endian though. The current year is written as MMXXVI, not IVXXMM.

Re: Endian wars and anti-portability: this again?

#39
post #28

Earlier quoted context omitted.

No, BE is logical because it puts bits and bytes in the same order. That humans use BE is also nice but secondary to that. I don't have strong feelings about whether fifty-one thousand nine hundred sixty-six is written as 0xcafe or 0xefac, but I feel quite comfortable suggesting that 0xfeca is absurd. (FWIW, this is a weak argument for what computers should do; if LE is more efficient for machines then let them use i…

Your example is only for dumping memory. > this is a weak argument for what computers should do; if LE is more efficient for machines then let them use it Computers really don't care. Literally. Same number of gates either way. But for everything besides dumping it makes sense that the least significant byte and the least significant bit are numbered starting from zero. It makes intuitive mathematical sense.

Not only dumping, but yes I agree it only matters when humans are in the loop. My most annoying encounters with endianness was when writing and debugging assembly, and I assure you dumping memory was not the only pain point.

Re: Endian wars and anti-portability: this again?

#40
post #6

> In closing, let me reiterate this point so it is crystal clear. If you are a maintainer of a libre software project and you refuse a community port to another architecture, you are doing a huge disservice to your community and to your software’s overall quality. Linus Torvalds disagrees. Vehemently. https://www.phoronix.com/news/Torvalds-No-RISC-V-BE > For those who don’t know, endianness is simply how the computer…

BE was a huge mistake. Arabic numerals originated in a right-to-left language too. depending on what size integer it is That's the worst part about BE: values that have a size-dependent term in them, in addition to a subtraction. 2^n vs. 2^(l-n) and 256^N vs 256^(L-N). According to Linus, BE has been "effectively dead" for at least a decade: https://news.ycombinator.com/item?id=9451284

Arabic numerals originated in India, were languages are written left to right.
Post reply on HN