On 01/26/2015 06:53 AM, Maciej W. Rozycki wrote:
On Mon, 26 Jan 2015, Ralf Baechle wrote:
Well, several MIPS processors can reverse the user-mode endianness via
the CP0.Status.RE bit; though as you may be aware it has never been
implemented for Linux. Otherwise it would obviously have to be a
per-process property (and execve(2) could flip it back).
As posted previously that was why I removed it from /proc/cpuinfo. And
yes, I had a simple prototype to use the RE feature. Even in the limited
form I had it was impressively ugly and it became clear it would never
be upstreamable.
Out of curiosity -- what was there that made it so ugly? The need for
case-by-case individual handling of byte-swapping the qualifying members
of syscall and signal data structures such as `struct stat'? Obviously
not alignment trap fixups, these are trivial to handle. And I think
pretty much everything else is endianness-agnostic.
I think *nothing* is endianness-agnostic. The instruction set reference
manual (MD00087 MIPS® Architecture For Programmers Volume II-A: The
MIPS64® Instruction Set, Revision 5.02) is a little cryptic, but I think
looking at the LB instruction shows how it works. OCTEON is known to
implement this and has been verified to work this way.
aligned 64-bit loads and stores are endianness invariant.
32-bit loads and stores have even and odd words swapped in the opposite
endianness (low order 3 address bits are XOR 4).
16-bit loads and stores half words scrambled in the opposite endianness
(low order 3 address bits are XOR 6).
8-bit loads and stores are scrambled such that the low order 3 address
bits are XOR 7 in the opposite endianness.
The result that all byte array data is scrambled when switching endianness.
This means that all read(), write() and similar calls could *not* access
the user data in-place in the kernel. The kernel would have to swap
around the bytes before using it. mmap() of the same file in processes
of opposite endianness would be impossible, as one of the processes
would see scrambled data.
For this reason, it really only makes sense to have the kernel and
user-space use the same endianness.
And because kernel and userspace must have the same endianness, the
endianness can be probed in userspace without consulting the kernel.
David Daney