> On Apr 25, 2016, at 11:05 AM, Swift Griggs <[email protected]> wrote:
>
> On Fri, 22 Apr 2016, Sean Conner wrote:
>
>> 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.
>
> Oh and you are so totally correct.
Huh?
I know some very ancient MIPS processors had oddball required delays ("load
delay"?) that went away after. And there's the misbegotten "branch delay slot"
-- but that is part of the architecture and applies to all MIPS even long after
the reason for it was ancient history.
Of course you can generate code for new MIPS that will break on old MIPS, just
like for any other processor family that has evolved over time. But old code
that would break on new MIPS? That's news to me. Sub-optimal, yes of course,
that too is true for every processor family. I've worked for years on MIPS
family systems, and always wrote or compiled for the oldest CPU used in the
product line. Upward compatibility would take care of the rest.
Swapping chips in a system is a different issue: what you need there is not
just instruction set compatibility but also pin compatibility, and that is far
less common (again, not just in MIPS but across many CPU families. Try
plugging in a Pentium in place of a 486 and see how far you get, or an Alpha
EV4 in place of an EV2, or a J-11 in place of an F-11.
paul
