At Thu, 3 Jan 2002 22:31:05 +0000 (UTC), manu@netbsd.org wrote:
> So modifying sys/arch/mips/include/types.h so that mips_reg_t is always
> long long seems reasonnable to me, since this will work with no overhead
> for o32, n32 and n64. I think about removing alls the #if on
> _MIPS_BSD_API and just do typedef long long mips_reg_t
> 
> Is this reasonable?

Well, aside from the following results of changing that type, yes it's
reasonable:

(1) it's completely unnecessary and wasteful on 32-bit MIPS systems.
    I.e., the systems that typically have the least performance to
    squander.

(2) it breaks binary compatibility in a number of places.  The ones
    that jump out are:

	* everything that uses sigcontext or related data types

	* core dump

	* ptrace

    There are probably more.

In addition, I'd guess that it'll hose DDB, but i'm not completely
sure about that.


Oh, did i mention that the 'yes' above was a little sarcastic?  8-)


So, there are two choices that I see, really:

(1) make NetBSD userland bits see all of the above in their current
    sizes.  You can do this, and pass the 64-bit values around in the
    kernel.  It won't be trivial, but it's probably doable.

    You wouldn't be able to get meaningful coredumps or run debuggers
    even on the assembly of the n32 binaries though.

(2) The Right Thing: go the whole mips / mips64 route, with the
    'mips64' kernels only being runnable on MIPS III, IV, V, and 64
    processors, obviously.  Allow N32 (and 64-bit) binaries to be run
    only on the latter.


chris