> On Mon, Dec 06, 1999 at 10:58:10AM +0100, Kevin D. Kissell wrote:
> > I'm working on cleaning up and enhancing the
> > MIPS/Linux code to support the new families
> > of CPUs coming out of MIPS Technologies Inc.
> > In doing so, I've come across and fixed a number
> > of bugs, most of which I've also passed back to
> > Ralf Baechle for integration with the moving
> > target at linux.sgi.com. But I came across
> > something this morning that, while not a problem
> > for us, puzzles me. In arch/mips/mm/r6000.c,
> > which has your name on it, there is a compiler
> > directive to use MIPS III instructions, and the
> > resulting code does indeed end up containing
> > 64-bit (daddiu, etc.) instructions. I've never
> > actually programmed an R6000, but all of the
> > information I have on that processor indicates
> > that it is a MIPS II, 32-bit design, and that those
> > instructions should therefore cause exceptions.
> > Am I mistaken, or is that directive a bug?
> It obviously is. The R6000 code isn't supposed to work and given that
> currently none of the Linux/MIPS hackers has a) R6000 documentation and
> b) an R6000 machine an R6000 port ever happening is highly unprobable.
> As the result of this I think I'm going to just burry the R6000 support
> and while I'm at it also the R8000.
Since the R6000 was an ECL machine produced in late 1992, just
before the MIPS/SGI merger. There were only a few machines sold
and the machine was designed to be a Fortran FP specialist.
Hence the R6000 is long since dead. We still have the MIPS risc/os 5.01
operating system source code, so if anybody has lots of free cycles
to waste, I'm sure we can send them locore.