Unbreak CRIS sim: fix -gen-decode-insn-entry. And why the widened mem fetch?

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

Dave Brolley's changes broke the CRIS sim in at least two
places: in CGEN (see further below) and by assuming that all
sims also have CGEN disassemblers (film at 11).  Tsk tsk.
*Please* regen, cgen-maint-rebuild and test all CGEN simulators
when hacking general changes into the CGEN sim machinery.  It's
not like there are too many...

Anyway, I think I unbroke it (clean test-results), but I'm not
sure this is the best change.  I don't like these diffs in the
generated sim (this one seemingly unrelated to the breakage,
maybe it's due to Jim Blandy's change on 2005-05-16):

Index: cpuv10.h
@@ -684,9 +684,9 @@ struct scache {
   unsigned int length;
 #define EXTRACT_IFMT_MOVUCWR_CODE \
   length = 4; \
-  word_1 = GETIMEMUHI (current_cpu, pc + 2); \
+  word_1 = GETIMEMUSI (current_cpu, pc + 2); \
   f_operand2 = EXTRACT_LSB0_UINT (insn, 16, 15, 4); \
-  f_indir_pc__word = (0|(EXTRACT_LSB0_UINT (word_1, 16, 15, 16) << 0)); \
+  f_indir_pc__word = (0|(EXTRACT_LSB0_UINT (word_1, 32, 15, 16) << 0)); \
   f_mode = EXTRACT_LSB0_UINT (insn, 16, 11, 2); \
   f_opcode = EXTRACT_LSB0_UINT (insn, 16, 9, 4); \
   f_size = EXTRACT_LSB0_UINT (insn, 16, 5, 2); \

Why fetch more than needed?  Can't that cause spurious invalid
accesses at the end of defined memory?  Doesn't it slow down the
simulator?  (Hm, I guess I can measure that...)  I don't have
the full context of all cases when this can happen, but for the
case above, it's for moving a 16-bit constant field
zero-extended into a 32-bit register.

And this one:

@@ -364,8 +364,14 @@ crisv10f_decode (SIM_CPU *current_cpu, I
           case 11 : /* fall through */
           case 12 : /* fall through */
           case 13 : /* fall through */
-          case 15 : itype = CRISV10F_INSN_BCC_B; goto extract_sfmt_bcc_b;
-          case 14 : itype = CRISV10F_INSN_BA_B; goto extract_sfmt_ba_b;
+          case 15 :
+            if ((base_insn & 0xf00) == 0x0)
+              { itype = CRISV10F_INSN_BCC_B; goto extract_sfmt_bcc_b; }
+            itype = CRISV10F_INSN_X_INVALID; goto extract_sfmt_empty;
+          case 14 :
+            if ((base_insn & 0xff00) == 0xe000)
+              { itype = CRISV10F_INSN_BA_B; goto extract_sfmt_ba_b; }
+            itype = CRISV10F_INSN_X_INVALID; goto extract_sfmt_empty;
           default : itype = CRISV10F_INSN_X_INVALID; goto extract_sfmt_empty;
           }
         }

Aren't those tests redundant when base_insn == entire_insn (so
to speak; there is no entire_insn as per the patch below)?
Should I have conditionalized the whole generated if-test?

The change below mimics the test in
sim-decode.scm:-gen-decode-fn where entire_insn is conditionally
declared as a parameter to @prefix@_decode.  Without it, I get
compilation errors for the undeclared entire_insn.
Ok to commit?

	* utils-sim.scm (-gen-decode-insn-entry): Correct last change for
	non-(adata-integral-insn? CURRENT-ARCH) case.

Index: utils-sim.scm
===================================================================
RCS file: /cvs/src/src/cgen/utils-sim.scm,v
retrieving revision 1.13
diff -p -u -r1.13 utils-sim.scm
--- utils-sim.scm	18 May 2005 21:52:57 -0000	1.13
+++ utils-sim.scm	2 Dec 2005 03:33:15 -0000
@@ -636,7 +636,9 @@
 			  ";\n")
 			 "")
 		     ; Generate code to check that all of the opcode bits for this insn match
-		     indent "    if ((entire_insn & 0x" (number->hex (insn-base-mask insn)) ") == 0x" (number->hex (insn-value insn)) ")\n" 
+		     indent "    if (("
+		     (if (adata-integral-insn? CURRENT-ARCH) "entire_insn" "base_insn")
+		     " & 0x" (number->hex (insn-base-mask insn)) ") == 0x" (number->hex (insn-value insn)) ")\n" 
 		     indent "      { itype = " (gen-cpu-insn-enum (current-cpu) insn) ";"
 		     (if (with-scache?)
 			 (if fn?

brgds, H-P