> > The whole mips ordeal is the one thing which upset me greatly
> > about the MIPS processor line, this is the single one thing which
> > makes a true "all in one" MIPS/Linux kernel damn near impossible.
> It's worse than that; MIPS only prescribes the user-level
> behaviour of the CPU. The bits of the CPU which only the kernel deals
> with (what MIPS calls "co-processor 0") are implementation dependent.
> The R5000 is rather different from the R10000 at this level, although
> they both implement MIPS-4.
> It's also better than that, in that:
> o All Linux-capable MIPS-1 CPUs are pretty much compatible.
> o There are no MIPS-2 CPUs (it was only invented for the ECL R6000,
> which didn't have a very big sale)
Wrong :-) IDT offers a R3000 derived CPU plus the MIPS II extensions ...
And I think the MIPS II extensions are interesting.
> o All Linux-capable MIPS-3 CPUs are readily driven with the same
> software. Some detailed differences (R4400 likes more nops than
> R4600 sometimes), but nothing serious.
That "nothing serious" did cost me days. No manual tells you that the R4600
sometimes needs more nops than the R4400 ...
> You will need ifdefs for MIPS-1 vs MIPS-3 in any code which messes
> with the interrupt levels or TLB.
That was my solution. As soon as one tries to support more MIPS CPU flavours
this turns into headacke. 18.104.22.168 has several flavours of exception
handlers for different types of CPUs plus some special flavours that handle
> And there again it's worse, because you'll search in vain for any
> systematic documentation about this.
Yep. Luckily this will only affect a very low number of Linux hackers.