If the system can change the endianess at any time, does that mean that we should only be using palindromic data? Or is it that we should aim to make everything polyglotic such that both directions have valid but distinct interpretations?

;)

you joke but I learned at a talk comparing genetics to TCP networking (at HOPE, maybe 2014 or 2016, cant find it on the website atm) that DNA is encoded such that it expresses different proteins depending on which direction it is read, might be something to learn from

armv8 defines the registers for changing endianness too :) https://developer.arm.com/documentation/den0024/a/ARMv8-Regi... Cortex cores at least do support switching endianness for data in userspace (SCTLR_EL1.E0E)

> Cortex cores at least do support switching endianness for data in userspace (SCTLR_EL1.E0E)

Yeah, Cortex and NVIDIA cores do (and probably quite some others).

However, Apple-designed recent cores don’t implement big endian support at all.

Sounds like an architecture full of features you'd like to avoid when you want to run on battery, run as many of them in a datacenter of a given heat dissipation capacity or simply when you're big enough to tailor a CPU design to your needs because you can buy from a chip manufacturing as a service company. Truly an architecture for a different century.

Most company can't afford to make custom chip at 7 nm.

The IBM Power is one implementation of the Power ISA.

The chips used on the mars rovers and nintendo Wii as ppc as well.

Interesting. What would the benefit be of changing endianess at runtime?

From an efficiency perspective does that mean the chip has to do both so worst of both worlds?

[I dont know much about the world of cpu design, these might be stupid questions]

It's more something you'd do at boot, if you had to select between an OS built for one or another.

The POWER ISA was used in PowerPC which was used for the successors of a few 68k machines (most famously the Macintosh) and in that case the OS was built for big-endian. So having big-endian support was key there.

IBM i and AIX still run big, in fact. Important for IBM's institutional customers.

As for endian shifts, technically every OpenPOWER chip goes big for every OPAL call into the low-level HAL, even if the OS is little. The overhead is minimal. I can't think of much application use for that, though (per-page endianness which some PowerPCs supported is much more useful).

Network application.

The CPU probably works on just one endianess and convert the data format when reading from memory. The overhead is on kepping track when to do it. But Im speculating, havent looked into this.