Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Endian wars and anti-portability: this again?

dalmatian.life

Post reply on HN
Print view View original

11–20 of 73 posts

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

#11

Post by bastawhiz »

I think the tricky thing here is that I simply don't have the time, patience, or resources to maintain this stuff. Let's say I have a LE-only project. Someone ports it to work on BE. Now it needs ci for BE. I write a patch in the future and the BE tests fail. Now I need to fix them. Potential contributors need to get the tests to pass. Who's using BE, though? Is the original porter even still using it?

The author betrays their own point with the anecdote about 586 support: they had tests, the tests passed, but the emulator was buggy, masking the issue. Frankly, if you're the Linux kernel and nobody has the hardware to run the tests on an actual device, it says a lot. But it also shows that qemu is struggling to make it work if the emulation isn't working as it should. How is someone who runs a small project supposed to debug a BE issue when you might have to debug the emulator when a user report comes in?

For me, I'll always welcome folks engaging with my work. But I'll be hesitant to take on maintenance of anything that takes my attention away from delivering value to the overwhelming majority of my users, especially if the value of the effort disappears over time (e.g., because nobody is making those CPUs anymore).

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

#12

Post by userbinator »

zephen wrote: 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

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

#13

Post by jandrewrogers »

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. It sucked hard. I've also written a lot of code that was portable to some very weird silicon so I know what that entails. It goes far beyond endian-ness, that is just one aspect of silicon portability.

The expectation that people should volunteer their time for low ROI unpleasantness that has a high risk of being unmaintainable in the near future is unreasonable. There are many other facets of the code base where that time may be better invested. That's not "anti-portable", it is recognition of the potential cost to a large base of existing users when you take it on. The Pareto Principle applies here.

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. The computing world is far, far less fragmented than it used to be.

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

#14

Post by yjftsjthsd-h »

userbinator wrote: post #9

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.)

> Little endian is logical and won, big endian is backwards and lost for good reason.

No, BE is logical, but LE is efficient (for machines).

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

#15

Post by ronsor »

smj-edison wrote: post #10

> I happen to prefer big endian systems in my own development life because they are easier for me to work with, especially reading crash dumps. If hex editors were mirrored both left to right and right to left, would it be easier to read little endian dumps?

xxd has the `-e` option for exactly this use case:

    -e          little-endian dump (incompatible with -ps,-i,-r).

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

#16

Post by lowbloodsugar »

yjftsjthsd-h wrote: post #14
userbinator wrote: post #9

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.)

> Little endian is logical and won, big endian is backwards and lost for good reason. No, BE is logical, but LE is efficient (for machines).

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”.

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

#17

Post by nextaccountic »

jandrewrogers wrote: post #13

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…

Why not wasm?

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

#19

Post by cpeterso »

zamadatix wrote: post #5
josephg wrote: post #3

> If the community is offering you a port to an architecture, whether it is 4 days old or 40 years old, that means the community actively wants to use your software on it – otherwise, nobody would put in the effort. Ports like this are hard, and authors like me already know we are fighting an uphill battle just trying to make upstream projects care. I've had plenty of opensource contributions over the years for some…

> That said, is there an easy way to run software in "big endian" mode on any modern computer? QEMU userspace emulation is usually the easiest for most "normal" programs IMO. Once you set it up you just run the other architecture binaries like normal binaries on your test system (with no need to emulate a full system). Very much the same concept as Prism/Rosetta on Windows/macOS for running x86 apps on ARM systems ex…

A post about big-endian testing with QEMU was posted on HN just a few days ago:

https://news.ycombinator.com/item?id=47626462

https://www.hanshq.net/big-endian-qemu.html

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

#20

Post by Brian_K_White »

jandrewrogers wrote: post #13

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…

[flagged]
Post reply on HN