MIPS pseudo-insns and Re: Patch to add -mfp32 support to MIPSgas

[cgd at broadcom dot com]

First, no good deed goes unpunished.  For doing the good deed of
adding test cases...  there are new test failures:

	Test:				Fails on:

	MIPS -mgp32 -mfp32		(a) (b)
	MIPS -mgp32 -mfp64		(a) (b)
	MIPS -mgp64 -mfp32		(a) (b)
	MIPS -mgp64 -mfp64		(a) (b)
	MIPS -mabi=32			(a) (b)
	MIPS -mgp32 -mfp32 (SVR4 PIC)	(a)
	MIPS -mgp32 -mfp64 (SVR4 PIC)	(a)
	MIPS -mgp64 -mfp32 (SVR4 PIC)	(a)
	MIPS -mgp64 -mfp64 (SVR4 PIC)	(a)
	MIPS -mabi=32 (SVR4 PIC)	(a)

(a): mips-linux, mipsel-linux, mips64-linux, mips64el-linux
(b): mips-ecoff, mipsel-ecoff

I didn't spend any time looking into them, other fish to fry.  I was
just boggled by the sheer amount of output generated by the little
script that i used to check for failures from my 10-target builds.

(mips-elf, mipsel-el, mips64-elf, mips64el-elf look OK, in case you're
wondering what else i tried.  8-)


r.sandiford@redhat.com ("Richard Sandiford") writes:
> In the second patch, I failed to pick up on the fact that the way the "move"
> instruction is expanded depends on mips_gp32.  The patch below makes it
> depend on HAVE_32BIT_GPRS instead, so that the 32-bit version gets used when
> a 32-bit ABI is selected.  I've added a move test to the testcases.
> 
> But, can anyone explain these entries in mips-opc.c:
> 
> {"move",    "d,s",	0x00000025, 0xfc1f07ff,	WR_d|RD_s,		M1|G6	},/* or */
> {"move",    "d,s",	0x0000002d, 0xfc1f07ff, WR_d|RD_s,		M3	},/* daddu */
> {"move",    "d,s",	0x00000021, 0xfc1f07ff, WR_d|RD_s,		M1	},/* addu */
> {"move",    "d,s",	0x00000025, 0xfc1f07ff,	WR_d|RD_s,		M1	},/* or */
> 
> The archives say that "addu" is preferred to "or" because some processors
> have two addition units but only a single logic unit:
> 
>      <http://sources.redhat.com/ml/binutils/1999-10/msg00132.html>
> 
> But why that last entry?  And why not use "addu" for -mgp32 as well?

I think the notion with the last entry is so that a correctly-shaped
'or' will disassemble to as 'move'.

Personally, I think that's a bug, since i think it'd be nice to be
able to go:

	* assemble 1
	* disassemble 1
	* possibly trivial modifications to get syntax right
	* assemble 2
	* disassemble 2

and get the same output from the two different 'assemble' passes, and
get the same output from the two different 'disassemble' passes.

that would mean that in My Little World 'disassemble' shouldn't spit
out pseudo-ops names for instructions (if those could then be
re-assembled differently).


But it gets better than that!

We now have -mtune, so we can rationally decide based on the processor
type how to implement 'li' and 'move'!

Yes, it's a micro-optimization, but in terms of the actual work done
by the compiler and assembler it should be approximately free (and why
blow the cycles if you really can tune well).


To the above ends, i would:

(1) remove all entries for 'li' and 'move' in the current mips opcode
table and replace them with M_LI and M_MOVE entries respectively.
(That would alos allow the instructions to disassemble as their actual
instruction opcodes.)

(2) in M_LI and M_MOVE, use an equivalent of the existing algorithm
for picking instructions but in the case where CPUs are known to work
better one way or another, optimize.


What do people think of this?  I'd be willing to do the work myself
if it's desired (unless somebody beats me to it; it seems like this
would be simple to do, and a nice project for a beginner).



chris