>  Here's a start - I can now execute a dhrystone program compiled on
>Ultrix with the -mips3 option.  All it does is recognize the mips3 binary
>as a valid ECOFF binary.  I'm not sure what to do to verify that it's
>only valid on mips3 cpus.

Uh, do you mean like

#define ECOFF_BADMAG_MIPS1(ep) ((ep)->f.f_magic != ECOFF_MAGIC_MIPSEL)
#define ECOFF_BADMAG_MIPS3(ep) ((ep)->f.f_magic != ECOFF_MAGIC_MIPSEL3)

#ifdef MIPS3
 /* allow mips3 user executables if this really is a mips3. */
# define ECOFF_BADMAG(ep) \
	(ECOFF_BADMAG_MIPS1(ep) && ((CPUISMIPS3) ? ECOFF_BADMAG_MIPS3(ep) : 1))
#else
# define ECOFF_BADMAG(ep) ECOFF_BADMAG_MIPS1(ep)
#endif

(which might need another #include), or something else?
To user code, the mips3 is a superset of the mips1 (that's how we
treat it now!) so disallowing mips1 user code on a mips3 is not sensible.

The exec-package semantics means that, on a mips1, we'll still try and
execute mips3 binaries as shell scripts; I'm not sure how to fix that.

We also need to sort out the register semantics implied by the ecoff
type 'MIPSEL3'... this, I have no clue on.  At least for gcc, -mips3
doesnt' change the size of data types.

Could someone try compiling some FP code with gcc -mfp64, running it
on Ultrix, and reporting what happens on boht NetBSD and Ultrix?

If there's only one active user of the FPU, this might just work
on NetbSD. But  it will lose on the first FPU context-switch....