[rx sim] add decode cache

[DJ Delorie]

> ok, so the cached info isnt as generic as i'd like ;).  i wonder if
> we could fit a cache in there somewhere though ...

I don't think the decode is as cpu-intensive as the semantics, though.
It seems to me there are a *lot* of loops in most software, so the
more info you can re-use, the better.  Actually, decoding a single
opcode's syntax and semantics doesn't take that long, it's just that
benchmarks tend to run *zillions* of opcodes, so even tiny savings add
up.

> doesnt seem like it's limited to CISC arches though ... in the
> Blackfin decode/sim, we too have a big tree of if/switch/masks to
> pull out arguments ive always been annoyed that we had to copy the
> decode file, gut it, and then fill in the sim pieces to make it
> work.  seems like this opc2c might be a way back from that.

There's no reason why it *wouldn't* work for RISC architectures, of
course, I just never tried it, and don't know how optimal it would be
with it.  However, if you have a RISC case where an operand field
isn't fully used, and certain operand patterns mean a whole different
opcode, opc2c can help you there - it will only decode to a specific
opcode if its operands are valid too, which is *really* hard to get
right with simple mask tables.

For the m32c, I used opc2c for the simulator, and cgen was used for
everything else.  For RX, opc2c was pushed to libopcodes, and it's
used for the simulator, disassembler, *and* gdb.  Nowhere else are RX
opcodes decoded.  Maybe Kevin can comment on how different it was to
use opc2c's decoder for gdb's prolog analyzer?

For the RX assembler, I used bison.  The resulting file *looks* like
an opc2c input file - syntax followed by semantics - but I didn't try
to use the same input file for both purposes.