On Fri, 29 Aug 1997 21:12:34 -0700  Jonathan Stone wrote:

> 
> >  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.

There's no concept of "Architecture not supported"?  FWIW, file(1)
doesn't know about the mips3 headers - I'll try and remember to file a
PR, I think I've got this working with my Ultrixified NetBSD file(1).

> 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.

The way I understand it is that longs should stay 32 bits, but that long
longs (64 bits) now fit in a single register, instead of spanning two
registers as they currently do now.  I _think_ the same applies with the
FP regs (mips1 has 32 * 32bit or 16 * 64bit, and mips3 has 32 * 64bit).

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

I've never been about to get gcc to emit working mips3 code on Ultrix.
This is typical, floating point or not:

	balrog:~ 1205> cat foo.c
	double
	foo(double a, double b)
	{
		return(a + b);
	}

	main()
	{
		double a, b, c;
		c = foo(a, b);
	}
	balrog:~ 1206> gcc -g -mfp64 -mips3 -o foo foo.c
	balrog:~ 1207> ./foo
	Illegal instruction (core dumped)
	balrog:mersenne/delta/mers 1208> gdb foo
	GDB is free software and you are welcome to distribute copies of it
	 under certain conditions; type "show copying" to see the conditions.
	There is absolutely no warranty for GDB; type "show warranty" for details.
	GDB 4.16 (mips-dec-ultrix4.5), Copyright 1996 Free Software Foundation, Inc...
	(gdb) run
	Starting program: /home/simonb/src/math/mersenne/delta/mers/foo 

	Program received signal SIGILL, Illegal instruction.
	0x400204 in main () at foo.c:8
	8       {
	(gdb) 

There also seems to be some problem (I think all the libraries need to
be compiled with -mips3?) under NetBSD:

	vlad:~ 119> gcc -g -mfp64 -mips3 -o foo foo.c
	ld: /var/tmp/cc03105a1.o: ISA mismatch (-mips3) with previous modules (-mips1)

After some quick experiments I can't get the MIPS compiler to use
odd-numbered fp regs for doubles, seeming to indicate it still believes
that the fp regs are only 32 bit. gcc does this quite willingly, even
without -mfp64.

> 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....

Is it a simple enough case to just save 64 bit gp and fp regs?

Simon.