Michael Smith writes:

>To that end, I'd like to stir a little discussion about the MipsCo
>boxes, particularly with regard to the NetBSD mips support of the r3k 
>in a big-endian environment. All the MipsCo machines of which I am
>aware are r3kbe (there are probably some r2k machines but I know
>nothing of them).

>Is the MI mips code ready for showtime? 

I beleive that bcopy() still needs to be re-written to be bi-endian:
e.g., by using macros to do "load higher address" (word,byte), rather
than explicit lwl/lwr.	

Otherwise, I think the MI mips code is basically ready for showtime.
Michael Hitch has got an r4k-based DECstation to single-user prompt.
These machines have nontrivial secondary caches, and so need some more
support than was in Per's original Pica code.

I haven't looked at later OpenBSD code; I'll leave that to someone who
has. Certainly I think writing "MI" mips support is the right way to
go. Until recently, none of the NetBSD/mips developers had access to
r4k machines; that's no longer the case and things are happening.

Getting NetBSD-current up on one of the bi-endian ARC-like machines
may be a useful porting path to going bi-endian.


>How would one go about
>constructing a arch subtree to make use of it?  What still needs
>work?  Per recently committed an r3kbe port (wgrisc) to the OBSD
>tree which I have been studying for a while now in an effort to
>reach some understanding of the various issues, but I'm still
>lagging 8(

All I can say for now is: see arch/pmax/pmax.  

You'll need port-specific versions of
	clock.c
	autoconf.c
	conf.c
	disksubr.c
	machdep.c
	sys_machdep.c
	vm_machdep.c
	pmap.c

And also of the include files in arch/pmax/include that just include
files from arch/mips/include.


I don't know how far Michael Hitch has got with the r4k version of
pmap.c; when that works reliably with 2nd-level caches, there's likely
to be an MI arch/mips/mips/pmap.c, with #ifdef's to allow compiling
for mips1, mips3 or (soon) both. Some of the other files could (and
hopefully will) be made more MI. The pmax cpu.c is more-or-less MI;
it's only separate to allow a callback to estimate the CPU clock
speed, and thus the DECstation model number.


Also, there *are* people interested in working on newer MipsCo
hardware, (e.g., Magnums). This list exists so they can speak for
themselves, so I'll let them do so...