Re: defining 2-operand version of 3-operand insns?

[Greg McGary <greg at mcgary dot org>]

Greg McGary <greg@mcgary.org> writes:

> Processing decoder for bits 31 30 29 28 27 26 ...
> Filtering 2 instructions.
> Instruction add2rambiguity-filtered by add3r
> Instruction add3rambiguity-filtered by add2r
> Processing decode entry 0 in decode_table_0, invalid ...

First, Here's a patch to add a space:

Index: insn.scm
===================================================================
RCS file: /usr/rback/release/tools-src/cygnus-unified/src/cgen/insn.scm,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 insn.scm
--- insn.scm	2000/12/05 17:50:18	1.1.1.1
+++ insn.scm	2000/12/06 18:34:40
@@ -729,7 +729,7 @@
 		 (keep? (not superset-insn)))
 	    (if (not keep?) 
 		(logit 2
-		       "Instruction " (obj:name insn) "ambiguity-filtered by "
+		       "Instruction " (obj:name insn) " ambiguity-filtered by "
 		       (obj:name superset-insn) "\n"))
 	    keep?))
 	insn-list)

> All of the instructions for which I have 2 & 3 operand versions
> defined as above are excluded from the sim decoder as ambiguous.
> Since the 2-operand versions are exclusively an assembler-language
> convenience, they should be ignored from the simulator.
> Unfortunately, I don't see a `NO-SIM' attribute.  Should I add one, or
> is there a better way out of this jam?

I have an idea.  filter-harmlessly-ambiguous-insns drops insns that
have fewer mask bits, retaining the most specific format.  A solution
to my problem would be to also compare number of operands and consider
the insn with more operands to be more specific.

Doug, does that sound reasonable to you, or are you philosophically
opposed to the entire 2/3 operand insn hack?

Greg