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

[Jim Blandy <jimb@redhat.com>]

Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:
> 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.

That could be due to my 2005-05-16 change.  I have to admit, I didn't
feel very confident in my understanding of that code at all, and I was
grateful to have found a relatively straightforward way to make it at
least produce the right field values.  If you are up to the task of
going into utils-gen.scm and making it produce minimal and correct
fetches, please do.