Accelerator boards - no future? Bad business?
paulkoning at comcast.net
Mon Apr 25 10:11:23 CDT 2016
> 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.
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.
More information about the cctalk