This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rx sim] add decode cache
> 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.