[rx sim] add decode cache

[Kevin Buettner]

On Thu, 29 Jul 2010 18:00:29 -0400
DJ Delorie <dj@redhat.com> wrote:

> 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?

Use of opc2c's decoder in writing GDB's prologue analyzer has several
advantages over the ad hoc decoders that we often write for a GDB
architecture port:

1) There's usually some amount of effort required to understand the
   instruction set encodings, and additional effort require to decide
   how to best decode the ones that GDB might care about.  Use of
   the opc2c decoder meant that much of that work was already done.
   The author of the prologue analyzer must still have a rudimentary
   understanding of the instruction encodings though.  (E.g. are the
   instructions fixed width or variable width?  What's the length
   of the shortest instruction?  Etc.)

2) The ad hoc instruction decoders that I've either written, or have
   worked upon for GDB usually involve masking some magic number with
   the instruction under consideration and then comparing that result
   with another magic number.  Sometimes these magic numbers are made
   a bit less magic by mapping them to a symbolic constant via the use
   of a suitable define or enum.  But coming up with them is error
   prone and it's by no means certain that code using them is
   adequately tested.

   The opc2c decoder, on the other hand, already has symbolic constants
   assigned to each instruction.  There is greater certainty that the
   decoded instruction is correct since it's used in the simulator and
   disassembler too.

3) The opc2c decoder decodes the instruction's operands too.  When
   writing an ad hoc decoder, the operand decoding is usually
   accomplished via shifts, masks, etc.   Again, there are more
   magic numbers involved, and yet more sources of error that can
   easily creep into the prologue analyzer.

   I do recall, however, being a bit surprised by the operand order
   for one of the RX instructions at one point.  Not a big deal, but
   it's worth noting that the prologue analyzer's author still has to
   take some care to get things right.

So, to summarize...  The opc2c decoder is better tested since it is
used in other tools.  Due to the fact that it provides symbolic
decoding of the opcodes and operands, prologue analyzer code is easier
to write, and has a better chance of being correct.  There is also a
savings of development time since the author of the prologue analyzer
need not do a detailed analysis of instruction and operand formats.

Kevin