On Apr 25, 2016, at 11:05 AM, Swift Griggs
<swiftgriggs at gmail.com> 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