Ch2.18: endian

Endianness

Endianness describes how multi-byte values are stored in memory:

• Little endian: least significant byte first.
• Big endian: most significant byte first.

Print checks directly with boolalpha:

#include <fast_io.h>
#include <bit>

int main() {
    print("my machine is little endian? ",
          boolalpha(::std::endian::native == ::std::endian::little), "\n");

    print("my machine is big endian? ",
          boolalpha(::std::endian::native == ::std::endian::big), "\n");
}

Use cases

Despite the fact that network protocols and encryption schemes often use big endian, most machines today are little endian. This means that when handling network packets or cryptographic data, systems often need to swap bytes back and forth. On architectures with efficient byte-swap instructions, this is trivial. However, RISC-V is criticized for lacking a default byteswap instruction, which leads to fragmentation and inefficiency.

::std::byteswap

::std::byteswap reverses the byte order of an integer. Just print the binary before and after:

#include <fast_io.h>
#include <bit>

int main() {
    ::std::uint32_t value{0xDEADBEEFu};

    print("Original value = ", ::fast_io::bin<true,true>(value), "\n");

    value = ::std::byteswap(value);

    print("Byteswapped value = ", ::fast_io::bin<true,true>(value), "\n");
}

Example: 0xDEADBEEF prints as 0b11011110101011011011111011101111. After byteswap, it prints as 0b11101111101110101010110111011110.

Discussion: RISC-V and Endianness

Linus Torvalds has raised strong arguments against adding big-endian support to RISC-V. From Phoronix coverage:

"Oh Christ. Is somebody seriously working on BE support in 2025?

WHY?

Seriously, that sounds like just *stupid*. Is there some actual real reason for this, or is it more of the 'RISC-V is used in academic design classes and so people just want to do endianness for academic reasons'?

Because I'd be more than happy to just draw a line in the sand and say 'New endianness problems are somebody ELSES problem', and tell people to stop being silly.

Let's not complicate things for no good reason. And there is *NO* reason to add new endianness.

RISC-V is enough of a mess with the millions of silly configuration issues already. Don't make it even worse.

Tell people to just talk to their therapists instead. That's *much* more productive."

He further added:

"Ok, I just googled this, and I am putting my foot down:

WE ARE NOT PREEMPTIVELY SUPPORTING BIG-ENDIAN ON RISC-V

The documented 'reasoning' for that craziness is too stupid for words, but since riscv.org did put it in words, I'll just quote those words here:

'There are still applications where the way data is stored matters, such as the protocols that move data across the Internet, which are defined as big-endian. So when a little-endian system needs to inspect or modify a network packet, it has to swap the big-endian values to little-endian and back, a process that can take as many as 10-20 instructions on a RISC-V target which doesn’t implement the Zbb extension'

In other words, it is suggesting that RISC-V add a big-endian mode due to
(a) internet protocols - where byte swapping is not an issue
(b) using 'some RISC-V implementations don't do the existing Zbb extension' as an excuse

This is plain insanity. First off, even if byte swapping was a real cost for networking - it's not, the real costs tend to be all in memory subsystems - just implement the damn Zbb extension.

Don't go 'we're too incompetent to implement Zbb, so we're now asking that EVERYBODY ELSE feel the pain of a much *worse* extension and fragmenting RISC-V further'.

I'm hoping this is some April fools joke, but that page is dated 'March 10, 2025'. Close, but not close enough.

This is the kind of silly stuff that just makes RISC-V look bad.

Ben - I'm afraid that that page has 'further reading' pointing to codethink.

I see some CONFIG_CPU_BIG_ENDIAN has already made it in, but this needs to stop.

The mainline kernel is for mainline development. Not for random experiments that make the world a worse place.

And yes, we're open source, and that very much means that anybody is more than welcome to try to prove me wrong.

If it turns out that BE RISC-V becomes a real thing that is relevant and actually finds a place in the RISC-V ecosystem, then _of_course_ we should support it at that point in the mainline kernel.

But I really do think that it actually makes RISC-V only worse, and that we should *not* actively help the fragmentation."

Key takeaways

• ::std::endian reports your system’s byte order.
• Most machines today are little endian, even though protocols often use big endian.
• ::std::byteswap reverses byte order for interoperability.
• RISC-V’s lack of a default byteswap instruction is a weakness that causes fragmentation.
• Linus Torvalds has argued strongly against adding big-endian support to RISC-V, calling it needless complexity.