Now, back to NetBSD/mips64.

Forthcoming NetBSD/mips64 will have I=32 LP=64 programming model just
like as NetBSD/alpha.  ELF-32 binary will be handled with 32bit system
call package, tentatively called 'netbsd32', and so-called N32 will be
care in the similar context.  Matthew Green once told me that
'compat/sparc32' could be a code base, then we reached some point of
the 'sparc32' should be 'netbsd32' and having arch/ inside to cope with
multi-architectureness.

Conservative and logical way toward NetBSD/mips64 is to well establish
mips64-ness on R4x00 DECstations prior to reap forward.  However,
given the fact NetBSD/pmax (and NetBSD/newsmips) is somehow behind
from leading-edge development efforts and to avoid 'compatibility-dom'
for existings, NetBSD/arc will be a sane platform since time zero.

Here starts implemetations.  As MIPS processor provides a concise way
to distinguish process 'programming model' with CP0 status register,
detecting and switching 32/64-ness looks not hard. 

The size of USPACE might be doubled, but having space for 64bit FP
registers statically sounds annoying, it would be malloc'ed at runtime
at the time when the first CP1 unusable trap was detected.

My concern right now is how seriously we have to worry about software
FP arithmetic emulation.  Early generation of CP1 had variations of
which FP instruction was implemented by circuit or not, then FP
emulation code had to be prepare for ANY of CP1 instructions.  That's
Kazumasa Utashiro told many years ago.  Does it matter in modern MIPS
processor's dense transistor towns?

Hay, Matthew, you're challenged.  NetBSD/mips64 might reap over
NetBSD/sparc64.  Do you take this? :-)

Tohru Nishimura
Information Technology Centre
Nara Institute of Science and Technology