Big-Endian Testing with QEMU

Re:Big-Endian Testing with QEMU by drob518 on Friday April 03, 2026 @04:21PM (#47631744)

What do you mean by “networking protocols,” exactly? Most packet level Internet protocols (TCP, UDP, etc.) are big endian. Ethernet is big endian at the octet level and little endian on the wire at the bit level. Network order is big endian because it has to be something and it’s easier to draw pictures as a matrix of bytes that are transmitted from left to right and top to bottom. There is no right answer to endianness. It’s like which side of the road cars should drive on. You just need to pick one and stick with it. Mostly people bitch about endianness when their processor is the opposite of whatever someone else picked. But processors are all over the map. IBM mainframes are big endian. Motorola 68k is big. HP PA-RISC is big. IBM Power started big and then went bi. MIPS is bi. RISC-V is little. ARM is bi but dominantly little (AArch64). And of course x86 is little. So, take your pick. That said, little endianness is the right answer as is driving on the right side of the road.

[ Parent | on HN ]

Re:Big-Endian Testing with QEMU by hmry on Friday April 03, 2026 @04:40PM (#47631961)

> RISC-V is little

These days it's bi, actually :) Although I don't see any CPU designer actually implementing that feature, except maybe MIPS (who have stopped working on their own ISA, and now want all their locked-in customers to switch to RISC-V without worrying about endianness bugs)

[ Parent | on HN ]

Re:Big-Endian Testing with QEMU by drob518 on Friday April 03, 2026 @04:53PM (#47632123)

Well, sort of. Instruction fetch is always little-endian but data load/store can be flipped into big. But IIRC the standard profiles specify little, so it's pretty much always going to be little. But yea, technically speaking data load/store could be big. Maybe that's important for some embedded environments.

[ Parent | on HN ]

Re:Big-Endian Testing with QEMU by hmry on Friday April 03, 2026 @05:28PM (#47632526)

> Well, sort of. Instruction fetch is always little-endian but data load/store can be flipped into big

ARM works the same way. And SPARC is the opposite, instructions are always big-endian, but data can be switched to little-endian.

[ Parent | on HN ]

Re:Big-Endian Testing with QEMU by pwdisswordfishy on Saturday April 04, 2026 @05:58AM (#47637614)

> it’s easier to draw pictures as a matrix of bytes that are transmitted from left to right and top to bottom

This argument is pretty silly: visualizations can always be changed. For some time I have been thinking that hexdumps on little-endian systems ought to be written right-to-left: in fact, when I once decided to include such a right-to-left dumper in my own software, it took me very little time for me to get used to, and I immediately started regretting I don't have it available everywhere.

[ Parent | on HN ]

Re:Big-Endian Testing with QEMU by jcalvinowens on Saturday April 04, 2026 @11:15AM (#47639739)

I read your reply as mostly agreeing with me: endianness is arbitrary, using big endian for a novel protocol just because some widely used protocols decided to decades ago is silly.

> it’s easier to draw pictures as a matrix of bytes that are transmitted from left to right and top to bottom.

There are many reasons for big endian... but that is not one of them :)

> But processors are all over the map

That's not true anymore, big endian is dead. Upstream Linux is refusing to support big endian riscv at all, and is making serious noises about ripping out the existing big endian arm/aarch64 support because the companies that ship the hardware that needs it don't work upstream.

[ Parent | on HN ]