Discussion

Big-Endian Testing with QEMU

pragmaticviber: It's all fun and games until you have to figure out if the endianness bug is in your code or in QEMU's s390x emulation.

electroly: > When programming, it is still important to write code that runs correctly on systems with either byte orderI contend it's almost never important and almost nobody writing user software should bother with this. Certainly, people who didn't already know they needed big-endian should not start caring now because they read an article online. There are countless rare machines that your code doesn't run on--what's so special about big endian? The world is little endian now. Big endian chips aren't coming back. You are spending your own time on an effort that will never pay off. If big endian is really needed, IBM will pay you to write the s390x port and they will provide the machine.

Retr0id: > There are countless rare machines that your code doesn't run on--what's so special about big endian?One difference is that when your endian-oblivious code runs on a BE system, it can be subtly wrong in a way that's hard to diagnose, which is a whole lot worse than not working at all.

eisbaw: I did that many years back, but with MIPS and MIPSel: https://youtu.be/BGzJp1ybpHo?si=eY_Br8BalYzKPJMG&t=1130presented at Embedded Linux Conf

electroly: That sounds like a problem to deal with as part of your paid IBM s390x porting contract. I guess my point is: why deal with this before IBM is paying you? No other big endian platform matters, and s390x users are 100% large commercial customers. If IBM or one of their customers isn't paying you, there's nobody else who would need it. If IBM is paying you, you can test on a real z/VM that they provide. I see big endian as entirely their burden now; nobody else needs it. If they want it, they can pay for the work.

Retr0id: I value correct code for purely selfish reasons. The most likely person to try to run my code on a BE system is me.

AKSF_Ackermann: > When programming, it is still important to write code that runs correctly on systems with either byte orderWhat you should do instead is write all your code so it is little-endian only, as the only relevant big-endian architecture is s390x, and if someone wants to run your code on s390x, they can afford a support contract.

bear8642: [delayed]

j16sdiz: If you comes to low level network protocol (e.g. writing a TCP stack), the "network byte order" is always big-endian.

skrtskrt: Prometheus index format is also a big-endian binary file - haven’t found any reference to why it was chosen.

nyrikki: The linked to blog post in the OP explains this better IMHO [0]: If the data stream encodes values with byte order B, then the algorithm to decode the value on computer with byte order C should be about B, not about the relationship between B and C. One cannot just ignore the big/little data interchange problem MacOS[1], Java, TCP/IP, Jpeg etc...The point (for me) is not that your code runs on a s390, it is that you abstract your personal local implementation details from the data interchange formats. And unfortunately almost all of the processors are little, and many of the popular and unavoidable externalization are big...[0] https://commandcenter.blogspot.com/2012/04/byte-order-fallac... [1] https://github.com/apple/darwin-xnu/blob/main/EXTERNAL_HEADE...

addaon: There's still at least one relevant big-endian-only ARM chip out there, the TI Hercules. While in the past five or ten years we've gone from having very few options for lockstep microcontrollers (with the Hercules being a very compelling option) to being spoiled for choice, the Hercules is still a good fit for some applications, and is a pretty solid chip.