Re: [rx sim] add decode cache

Kevin Buettner
2010-07-30T01:04:39Z

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