23 Apr
2016
23 Apr
'16
3:54 a.m.
On 23/04/2016 06:16, Eric Smith wrote:
On Fri, Apr 22, 2016 at 9:29 PM, Sean Conner <spc
at conman.org> wrote:
Nope, you're right. I've got R3000 and R4000 Indigos, R4000, R4400 ,
R4600 and R5000 Indys, R5K O2s and an R10K Origin 2000 running Irix 5.3
and 6.5, and the code written for the R3000 Indigos works fine on all
the others - with one exception (COFF vs ELF).
The same isn't necessarily true the other way around, of course, as the
later processors and later IRIX versions had things that didn't
translate back. For example, cc under IRIX 5.3, even with an R5000SC
CPU, compiles 32-bit "-mips1" by default and the resulting code will run
on any of the above and also on R2000 machines. However, in later
versions of IRIX the default became "-mips2" or higher, and of course on
some machines/IRIX versions the default became "-n32" or "-64" and in
some cases "-mips3" or "-mips4". Nevertheless there was still a
"-o32"
option and I've often compiled software on my O2K running 6.5.22 using
"-o32 -mips1" and run the resulting binary on an R3K Indigo as well as
the Origin (only somewhat slower :-)). About half of my /usr/local/bin
is compiled that way.
Another change was that IRIX 5.3 was the last version to support COFF
binaries, and the compiler itself would only produce ELF; later versions
of IRIX couldn't load COFF and would only run ELF binaries (with the
possible exception 6.0.1, but I don't remember). Under 5.3, you had to
use as(1) directly to generate COFF output.
--
Pete
One major problem with adding a faster CPU to
an SGI is the MIPS chip
itself---code compiled for one MIPS CPU (say, the R3000) won't run on
another MIPS CPU (say, the R4400) due to the differences in the pipeline.
MIPS compilers were specific for a chip because such details were not hidden
in the CPU itself, but left to the compiler to deal with.
Having written a bunch of R3000 and R4000/4200/4300/4400/4600 assembly
code in the 1990s, my (possibly faulty) recollection disagrees with
you. There are differences in supervisor-mode programming, but I don't
recall any issues with running 32-bit user-mode R3000 code on any
R4xxx. The programmer-visible pipelline behavior (e.g., branch delay
slots) were the same.
That's only considering the CPU itself, which I used as an embedded
processor; I never used IRIX so I don't know whether IRIX on R4xxx
might have somehow prevented use of IRIX R3xxx binaries (e.g., by
different system call conventions or the like).