Merge back of the MIPS sources

Merge back of the MIPS sources

[Ralf Baechle]

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

Re: Merge back of the MIPS sources

[Ariel Faigon]

:
: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!

-- 
Peace, Ariel

Re: Merge back of the MIPS sources

[Ralf Baechle]

> :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!

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

Re: Merge back of the MIPS sources

[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.

                              /Bob...                    mailto:mende@sgi.com
                        http://reality.sgi.com/mende/          KF6EID

Re: Merge back of the MIPS sources

[Ralf Baechle]

>    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.

>    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.

>                             /Bob...                    mailto:mende@sgi.com
>                       http://reality.sgi.com/mende/          KF6EID

73 de Ralf

Re: Merge back of the MIPS sources

[Ralf Baechle]

>    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.

>    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.

>                             /Bob...                    mailto:mende@sgi.com
>                       http://reality.sgi.com/mende/          KF6EID

73 de Ralf

Re: Merge back of the MIPS sources

[William J. Earl]

Bob Mende Pie writes:
 > 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.

Re: Merge back of the MIPS sources

[William J. Earl]

Ralf Baechle writes:
 > >    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.

Re: Merge back of the MIPS sources

[William J. Earl]

Ralf Baechle writes:
 > >    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.

Re: Merge back of the MIPS sources

[Ralf Baechle]

>       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

Re: Merge back of the MIPS sources

[Ralf Baechle]

>       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

Re: Merge back of the MIPS sources

[William J. Earl]

Ralf Baechle writes:
 > >       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?

     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.  

Re: Merge back of the MIPS sources

[Ralf Baechle]

>      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.  

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

Re: Merge back of the MIPS sources

[Ralf Baechle]

>      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.  

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