Re: [rx sim] add decode cache

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: Text/Plain, Size: 3003 bytes --]

On Thursday, July 29, 2010 18:00:29 DJ Delorie wrote:
> > 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.

right ... i'm booting the Linux kernel all the way to userspace with the 
Blackfin sim.  and then running some benchmarks in that.  the faster i can 
make this the happier i'll be :).

sometimes i go even crazier and boot U-Boot in the sim, load a uImage over the 
simulated network from a real host (via tun/tap), and then boot the kernel 
that way.  decompression is the worst part.

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

yeah, we've had to do a lot of checks to make sure we dont go decoding invalid 
opcodes as valid insns.  we had a lot of this originally, but after putting 
together a lot of test cases that basically test the entire opcode space to 
make sure we dont revert behavior (only a few ten thousand insns in that one 
test ;x).

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

i havent been able to figure out cgen.  but from what i can see, with a 
complete implementation already, i cant say it's worth the effort to move to 
the cgen infrastructure.  but it does look like opc2c wouldnt be too much 
effort to integrate and it'd be worth the work to have our opcodes/sim 
integrated better.

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

yeah, we use lacc/yex too with our parser.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]