This is the mail archive of the
cgen@sourceware.org
mailing list for the CGEN project.
Unbreak CRIS sim: fix -gen-decode-insn-entry. And why the widened mem fetch?
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: cgen at sourceware dot org
- Cc: brolley at redhat dot com, jimb at redhat dot com
- Date: Fri, 2 Dec 2005 04:42:35 +0100
- Subject: Unbreak CRIS sim: fix -gen-decode-insn-entry. And why the widened mem fetch?
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