From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg McGary To: "Frank Ch. Eigler" Cc: cgen@sourceware.cygnus.com Subject: Re: defining 2-operand version of 3-operand insns? Date: Wed, 06 Dec 2000 10:40:00 -0000 Message-id: References: <200012012217.PAA04718@kayak.mcgary.org> <20001201173254.G20294@redhat.com> X-SW-Source: 2000-q4/msg00245.html Greg McGary 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