Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[David Daney <ddaney.cavm@gmail.com>]

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