> On Mon, Mar 08, 1999 at 10:49:01PM -0800, David Miller wrote:
>
> > And guess what it even works for sysv ipc shared memory between big
> > endian and little endian processes.
>
> Does MIP have something similar? Something like that would be really cool
> on MIPSen where you want to be able to support processes of mixed
> endianness.
The R8000 is afaik only capable of running big endian but I might be wrong,
I never got real docs into my hands and reading marketing pamphlets about it
is a waste of time for a kernel hacker.
For most of the other CPUs the MIPS architecture provides the possibility to
select one endianess at cold reset time. This kernel mode endianess is them
fixed until the next cold reset. For processes running in user mode an
alternative endianess can be selected in the CPU's status register. New
CPUs like the R4300 also a bit which allows to change the kernel mode byte
order at run time.
MIPS doesn't offer any of the fancy features DaveM mentioned about the
Sparc, so SysV IPC won't work. Then again, any kind of shared memory is
usually only of interest between applications which have an idea with what
they're actually communicating, so I don't think this is a major loss.
Note that a system that a true bi-endian MIPS system needs more bi-endianess
hardware support than just the CPU. Many MIPS systems don't provide this
for example because they were built to run IRIX or NT which now has run us
into the unfortuate situation that we have to have two complete userlands
for MIPS.
Mips Computer Systems, Inc. was working on a bi-endian version of their UNIX
flavour RISC/os 6.0. The project was cancelled the day after SGI bought
MIPS and killed all their computer system and OS projects. But at the time
they had already proven that it can be done. One of their developers is
actually reading this list, I wonder if he can comment the performance
impact in real live.
As far as Linux/MIPS is affected - I once implemented bi-endianess support
into the kernel upto the point where I was able to run simple programs. I
don't want to say it was a good implementation, but it became very obvious
that there was no way around letting a significant uglyness creep into the
kernel. Linus is _really_ right if he wants to avoid a kernel that supports
bi-endianess like the plague - unless IA-64 has sexy features to solve this
problem.
Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/