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

[Hans-Peter Nilsson]

> Date: Fri, 02 Dec 2005 14:13:26 -0500
> From: Dave Brolley <brolley@redhat.com>

> The switch generator stops when it has tested enough bits to resolve 
> ambiguity among the defined insns, but since it wasn't going on to test 
> the remaining bits, the decoder was recognizing invalid insns as valid. 
> This additional test goes on to test all the fixed bits in each insn to 
> ensure that they are all correct.

I assume you mean with opcode definitions for

opcode=
0?0
1?0

(where opcode & 2 is don't care and opcode & 1 is invalid)
that there was *before* the extra generated code, only a test
generated for (opcode & 4) and that there's *now* (opcode & 5)
== 4 and (opcode & 5) == 0, with 1 and 5 flagged as invalid
insns; not that you mean that there are now checks for (opcode &
7) == 0 and (opcode & 7) == 4.

> It does appear that we could be 
> smarter about generating the test, however. In this case the tests 
> appear to be redundant. We could probably add some logic to test only 
> the untested bits and to not generate the additional test at all if all 
> of the bits have already been tested.

Recent GCC should optimize out any obviously redundant tests
with if-tests that are covered by an outer switch/case.

Anyway, I briefly tested timing before/after a regened sim/cris,
and time difference seems to be in the noise, at least for the
test programs I used.  I guess most interesting codes fit nicely
in the scache or something.  So I'm only worried about
correctness with the widened opcode fetches and the opcode
checks as above.

> >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.
> This change looks ok to me. Please commit it.

Done, thanks.

brgds, H-P