Merge back of the MIPS sources
Hi,
I've started to merge the MIPS changes into David's CVS archive. The first and biggest bundle of patches to include/asm-mips/ and arch/mips/ should be released by Linus in 2.1.44.
Ralf
:
:Hi,
:
:I've started to merge the MIPS changes into David's CVS archive. The :first and biggest bundle of patches to include/asm-mips/ and arch/mips/ :should be released by Linus in 2.1.44.
:
: Ralf
:
When we have our SGI/MIPS/Linux code rolled into the mainstream Linux distribution it will definitely be a pretty important milestone. Way to go!
Signature · 1 line
Peace, Ariel
Quoted 9 lines
:Hi,
:
:I've started to merge the MIPS changes into David's CVS archive. The :first and biggest bundle of patches toinclude/asm-mips/andarch/mips/:should be released by Linus in 2.1.44.
:
: Ralf
:
Quoted 3 lines
When we have our SGI/MIPS/Linux code rolled into the mainstream Linux distribution it will definitely be a pretty important milestone. Way to go!
Yes, indeed. It was also important to at merge at least a major fraction of the sources back since the stuff in Linus distribution is already pretty dated and some people were therefore believing the MIPS project would be dead. While as you know exactly the opposite is true ...
Ralf
Ralf,
Have you verified that the newest code still works on the other MIPS
based systems? Also, is it possible to have (linux) binary compatability
between a mips Magnum or Millennium and an Indy?
There is a 50Mhz Millennium over here that we might be able to use as a
test system.
/Bob... mailto:[email protected]
http://reality.sgi.com/mende/ KF6EID
Quoted 3 lines
Have you verified that the newest code still works on the other MIPS
based systems? Also, is it possible to have (linux) binary compatability
between a mips Magnum or Millennium and an Indy?
By principle there is no problem to feed these machines even with IRIX binaries. Right now the port to these machines assumes that it is running on the machine configured to little endian mode but porting to big endian should be easy.
Quoted 2 lines
There is a 50Mhz Millennium over here that we might be able to use as a
test system.
The support for these machines is currently not complete yet. We don't yet have SCSI driver which should be easy to write because the machine also uses the same NCR53C94 / FAS213 SCSI chip as the Sparc port already does.
In fact I'd be very happy if someone would take care of these machines. By supporting the Millenium we'd also have most of the support for the Olivetti M700 (mostly an OEM Magnum), Acer PICA, certain machines based on a Toshiba chipset and at least partially the NEC RISCstation series.
Quoted 2 lines
/Bob... mailto:[email protected]
http://reality.sgi.com/mende/ KF6EID
73 de Ralf
Quoted 8 lines · Ralf Baechle
Quoted 3 lines
Have you verified that the newest code still works on the other MIPS
based systems? Also, is it possible to have (linux) binary compatability
between a mips Magnum or Millennium and an Indy?By principle there is no problem to feed these machines even with IRIX binaries. Right now the port to these machines assumes that it is running on the machine configured to little endian mode but porting to big endian should be easy.
Note, however, that running big-endian on the MIPS systems is a bit
of a hack. They were originally designed to be little-endian-only (a MIPS management aberration), so running big-endian means that, in general, I/O DMA has to be byte-swapped by software. RISCos would preferentially write file systems on disks in native-endian format, which, if read on a different system, would appear to be byte-swapped within each doubleword. That is, RISCos would skip the byte-swapping on non-removable media, unless the magic number in the superblock indicated that the disk was initialized in true big-endian format. For all other media, RISCos would byte-swap, but, since those were much lower data rate, the performance impact was small.
Quoted 7 lines · Bob Mende Pie
Ralf,
Have you verified that the newest code still works on the other MIPS
based systems? Also, is it possible to have (linux) binary compatability
between a mips Magnum or Millennium and an Indy?
There is a 50Mhz Millennium over here that we might be able to use as a
test system.
If the MIPS system is running big-endian (as under RISCos), it can
be binary-compatible with Indy linux, just as RISCos 5.01 -systype svr4 binaries are binary-compatible with Indy IRIX 5.1 and later systems. If the MIPS system is running little-endian (as under NT), it cannot be binary-compatible with Indy linux, without adding bi-endian support (for running opposite-endian binaries, which is feasible, but messy). We prototyped bi-endian support in RISCos when before the Magnum was built, and it worked, but the code was very ugly in the streams area. linux would likely be easier, but still a hassle.
Quoted 9 lines
If the MIPS system is running big-endian (as under RISCos), it can
be binary-compatible with Indy linux, just as RISCos 5.01 -systype svr4 binaries are binary-compatible with Indy IRIX 5.1 and later systems. If the MIPS system is running little-endian (as under NT), it cannot be binary-compatible with Indy linux, without adding bi-endian support (for running opposite-endian binaries, which is feasible, but messy). We prototyped bi-endian support in RISCos when before the Magnum was built, and it worked, but the code was very ugly in the streams area. linux would likely be easier, but still a hassle.
Now that the overhead of accessing the userspace from the kernel under Linux is very close to zero I fear that the additional overhead of the byteorder conversion will show up very clearly in benchmarks unless someone comes up with very clever ideas how do this. Do you have numbers how much the impact on RISC/os performance was?
Ralf
Quoted 10 lines · Ralf Baechle
Quoted 9 lines
If the MIPS system is running big-endian (as under RISCos), it can
be binary-compatible with Indy linux, just as RISCos 5.01 -systype svr4 binaries are binary-compatible with Indy IRIX 5.1 and later systems. If the MIPS system is running little-endian (as under NT), it cannot be binary-compatible with Indy linux, without adding bi-endian support (for running opposite-endian binaries, which is feasible, but messy). We prototyped bi-endian support in RISCos when before the Magnum was built, and it worked, but the code was very ugly in the streams area. linux would likely be easier, but still a hassle.
Quoted 5 lines
Now that the overhead of accessing the userspace from the kernel under Linux is very close to zero I fear that the additional overhead of the byteorder conversion will show up very clearly in benchmarks unless someone comes up with very clever ideas how do this. Do you have numbers how much the impact on RISC/os performance was?
I don't have the numbers ready to hand, but it was not huge for most
things, given the hack of running the disk wrong-endian. CPU overhead for non-disk DMA I/O was higher, of course, but there is no extra overhead for operations where all the arguments are in registers. (An integer in a register is the same, no matter which endian you are.) getpid(), for example, is unaffected. Similarly, read() and write() to disk are unaffected. On the other hand, stat() is a little slower.
Note that endian data conversion is not blind byte swapping for
structures such a stat. Instead, it is a field-by-field operation, since the MIPS reverse-endian mode affects only addressing, not the layout of the bytes of, say, an integer in memory. A 32-bit integer will be at a different offset from the base of the structure (4, say, instead of 0), but the byte order in memory will be the same. The byte numbering of memory is different, which is how it appears that the bytes have been swapped. The structure conversion routines can thus be compiled fairly efficiently, avoiding runtime structure offset calculations for the most part (except for arrays embedded in structures).
If this starts to look worth doing, I can supply more imformation,
such as examples of how to efficiently convert structures.
Quoted 20 lines
I don't have the numbers ready to hand, but it was not huge for most
things, given the hack of running the disk wrong-endian. CPU overhead for non-disk DMA I/O was higher, of course, but there is no extra overhead for operations where all the arguments are in registers. (An integer in a register is the same, no matter which endian you are.)getpid(), for example, is unaffected. Similarly,read()andwrite()to disk are unaffected. On the other hand,stat()is a little slower.Note that endian data conversion is not blind byte swapping for
structures such a stat. Instead, it is a field-by-field operation, since the MIPS reverse-endian mode affects only addressing, not the layout of the bytes of, say, an integer in memory. A 32-bit integer will be at a different offset from the base of the structure (4, say, instead of 0), but the byte order in memory will be the same. The byte numbering of memory is different, which is how it appears that the bytes have been swapped. The structure conversion routines can thus be compiled fairly efficiently, avoiding runtime structure offset calculations for the most part (except for arrays embedded in structures).
Quoted 2 lines
If this starts to look worth doing, I can supply more imformation,
such as examples of how to efficiently convert structures.
This definately is worth doing. We have a couple of machines where we can not configure byteorder of the kernel to big endian like DECstations or the Acer PICA, essentially a downscaled Magnum with an Indy style L2 cache intended for NT. If we ever want to give them a chance to run commercial software, then we need to go biendian. And we need to implement it very clean or Linus will never accept the patches.
Luckily the functions get_user() and put_user in <asm/uaccess.h> do already a large part of the work for us but nevertheless we need to go through all the code once again. So maybe this is not something for now but definately worth doing.
Ralf