From: Neil Russell <hidden> Date: 2000-10-29 00:24:51
Some PPC CPUs don't implement all load/store instructions for little
endian; for instance, the 603 CPUs don't do lmw, stmw, lswi, lswx,
stswi, stswx for little endian. I seem to remember that there are other
problems aside from the ones that I mentioned. Later CPUs don't seem
to have a problem.
It would in theory be possible to have the kernel run big-endian as it is
and have certain user programs run little endian by setting the LE bit in
the MSR register for the process in question. The real problem here is
that you have to add a *lot* of code to system calls to make this work.
There are a few system calls that this would be real difficult, such
as ioctl(). I once looked into doing this for the MIPS with SVR4 UNIX.
Neil.
On Sat, Oct 28, 2000 at 04:50:38PM -0400, David Riley wrote:
Before I get dirty looks, I know the PowerPC's default byte ordering is
big-endian (the way things *should* be :-). What I'm asking is slightly
irrelevant to most development discussion here, but...
I know that the PowerPC does allow both endian modes. My big question
is how well it works in little endian mode. I know we'll never switch
Linux to this, since that would be too much unnecessary work, but just
for reference: Is it broken? I have heard reports to this effect.
Thanks,
David
From: Heiko Jakob <hidden> Date: 2000-07-19 13:59:43
At 5:24 PM -0700 10/28/00, Neil Russell wrote:
quoted
It would in theory be possible to have the kernel run big-endian as it is
and have certain user programs run little endian by setting the LE bit in
the MSR register for the process in question. The real problem here is
that you have to add a *lot* of code to system calls to make this work.
There are a few system calls that this would be real difficult, such
as ioctl(). I once looked into doing this for the MIPS with SVR4 UNIX.
The other real problem is that Linus Torvalds has already said that
he will never ever in a million years accept a patch which attempts
to do such a thing, so you'd have to fork the kernel to do it.
According to Linus, architectures are either big or little-endian,
not both. A sane position considering the syscall ugliness you
mention
How do the linux-mips people handle with big- and little-endian code ?
Maybe they know a good solution, which allows both big- and little-endian
code to execute.
The PPC is big-endian by nature, and what for we do need little-endian code
to be executed on a PPC ?
MfG
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Timothy A. Seufert <hidden> Date: 2000-10-30 09:12:14
At 5:24 PM -0700 10/28/00, Neil Russell wrote:
It would in theory be possible to have the kernel run big-endian as it is
and have certain user programs run little endian by setting the LE bit in
the MSR register for the process in question. The real problem here is
that you have to add a *lot* of code to system calls to make this work.
There are a few system calls that this would be real difficult, such
as ioctl(). I once looked into doing this for the MIPS with SVR4 UNIX.
The other real problem is that Linus Torvalds has already said that
he will never ever in a million years accept a patch which attempts
to do such a thing, so you'd have to fork the kernel to do it.
According to Linus, architectures are either big or little-endian,
not both. A sane position considering the syscall ugliness you
mention...
Tim Seufert
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
It would in theory be possible to have the kernel run big-endian as it is
and have certain user programs run little endian by setting the LE bit in
the MSR register for the process in question. The real problem here is
that you have to add a *lot* of code to system calls to make this work.
There are a few system calls that this would be real difficult, such
as ioctl(). I once looked into doing this for the MIPS with SVR4 UNIX.
The other real problem is that Linus Torvalds has already said that
he will never ever in a million years accept a patch which attempts
to do such a thing, so you'd have to fork the kernel to do it.
According to Linus, architectures are either big or little-endian,
not both. A sane position considering the syscall ugliness you
^^^^^^^^^
mention...
Really? Or did he mean: big-endian kernels must not run little-endian binaries
and vice versa.
Note that there exist 3 flavors of MIPS: 32-bit big-endian, 32-bit
little-endian and 64-bit. Linux supports them all. Expect to upgrade the hard
drives on your local Debian mirror soon :-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2000-10-30 12:50:17
On Wed, 19 Jul 2000, Heiko Jakob wrote:
How do the linux-mips people handle with big- and little-endian code ?
Maybe they know a good solution, which allows both big- and little-endian
code to execute.
They compiler the kernel and the apps for different endianness AFAICT.
The PPC is big-endian by nature, and what for we do need little-endian code
to be executed on a PPC ?
We don't need, especially since PPC endian switching is painful enough
that you don't want to switch endianness on the fly:
- the 601 uses a completely different, and much more complex method
- switching the processor is not sufficient if you want to access I/O due
to the "address munging" system used to give the impression of
little-endianness. The bridge also has to be reprogrammed, which is slow
and causes some problems with SMP when the two processors are runninng
with different byte orderings. Even a simple memory copy between two areas
use by different endianness process would have to mung/unmung the data,
even for simple text (or processes communicating through pipes...).
I have written an x86 emulator for ROM BIOSes, it is much easier to run it
in big endian and do byte swaps on every memory access (even the registers
are byte swapped in a memory image actually). Older processors will trap
on a 16 bit access at an odd address in LE mode, but lhbrx/sthbrx on an
odd address will work perfectly in BE mode. The BIOS does a lot of 16 bit
unaligned accesses due to its 8-bit 8088 origins, the emulator just does
not care, to the point that there is not a single alignment check in the
code (download it from ftp://vlab1.iram.es/pub/ if you are curious).
In short, the mixed endian capability of PPC is not good enough to be
effectively used. It would be a nightmare to try to use it. Make your life
simpler: forget about it.
If you absolutely want to do it, add minimal support to the kernel (wont't
be easy to support 601 though) and handle the rest as a userspace problem.
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Timothy A. Seufert <hidden> Date: 2000-10-31 11:23:01
At 1:18 PM +0100 10/30/00, Geert Uytterhoeven wrote:
On Mon, 30 Oct 2000, Timothy A. Seufert wrote:
quoted
At 5:24 PM -0700 10/28/00, Neil Russell wrote:
>It would in theory be possible to have the kernel run big-endian as it is
>and have certain user programs run little endian by setting the LE bit in
>the MSR register for the process in question. The real problem here is
>that you have to add a *lot* of code to system calls to make this work.
>There are a few system calls that this would be real difficult, such
>as ioctl(). I once looked into doing this for the MIPS with SVR4 UNIX.
The other real problem is that Linus Torvalds has already said that
he will never ever in a million years accept a patch which attempts
to do such a thing, so you'd have to fork the kernel to do it.
According to Linus, architectures are either big or little-endian,
not both. A sane position considering the syscall ugliness you
^^^^^^^^^
quoted
mention...
Really? Or did he mean: big-endian kernels must not run little-endian binaries
and vice versa.
Note that there exist 3 flavors of MIPS: 32-bit big-endian, 32-bit
little-endian and 64-bit. Linux supports them all. Expect to upgrade the hard
drives on your local Debian mirror soon :-)
You're absolutely correct -- what he doesn't want (at least as I
interpreted the email I'm remembering from a linux-kernel discussion)
is mixing modes. In other words, the official Linus kernel will
never support mixed LE and BE processes at runtime; you must choose
one or the other at kernel compile time.
Tim Seufert
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/