Subject: Re: Mips3 ultrix binaries
To: Jonathan Stone <email@example.com>
From: Simon Burge <firstname.lastname@example.org>
Date: 08/30/1997 14:41:20
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))
> # define ECOFF_BADMAG(ep) ECOFF_BADMAG_MIPS1(ep)
> (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
foo(double a, double b)
return(a + b);
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...
Starting program: /home/simonb/src/math/mersenne/delta/mers/foo
Program received signal SIGILL, Illegal instruction.
0x400204 in main () at foo.c:8
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
> 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?