Hacker News Reader

Comment by TD-Linux | Hacker News Reader

Yeah, my first thought was "this board looks great for testing big-endian". Would be nice to see comparisons to e.g. the G5.

View on HN

At what point will all big-endian usage be just developers testing big-endian with no users to use the results, and at what point shall we stop even testing?

(Yesterday, I finally got around to making encoding_rs work on 64-bit big-endian systems by testing PPC64 in qemu. Then I timed out trying to get a 32-bit big-endian system with recent enough glibc to run Rust up and running in qemu, so I still haven't tested the 32-bit case... Unclear if anyone even cares.)

With IBM's huge investment in better support for little-endian PPC (in hardware, in software development toolchains, and in software itself) it seems likely that many PPC users are going to slowly move away from little-endian. I can imagine some embedded uses, e.g. in network hardware, may well stick with big-endian because it fundamentally makes sense there, but I imagine it's going to become increasingly obscure.

My above comment is of course wrong, they're going to move away from big-endian to little-endian. Pretty sure I changed what I was saying half-way through. :)

MIPS is the other large big-endian case that's still in wide use (especially in home routers), however the machines are even more painfully slow to test on.

Most MIPS CPUs can run both BE and LE (MIPS-LE), although is usually tied to the kind of applications (e.g. most MIPS routers run in big endian mode)

Sure. I bought back in the day a G4 Mac Mini just for that purpose (running both Linux and OSX) :-)

In which case do you need to test big endian? Compiler or low-level library development?

TD-linux develops codec libraries.

I develop crypto code. Testing on BE is nice, not just because of endian neutral code but testing on something 'weird' can turn rare faults into common ones.

Beyond endianness I've found interesting bugs by running code on HP-PA (stack grows in the reverse direction) and on Itanium (misalignment causes a trap to the kernel)...

I wish there were a qemu supported fake architecture that made every optional decision differently (or at least every one that works with most code...).

Mainly for networking or disk storage, and in general for anything involving storing integer data into raw packets that will reach different CPU architectures (e.g. load or store an integer from/to a memory buffer into/from a CPU register).

Reply on news.ycombinator.com