This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rx sim] add decode cache


On Thursday, July 29, 2010 15:33:53 DJ Delorie wrote:
> > if the rx sim is ultimately built on top of opc2c, and you're
> > caching the results of that, then shouldnt it be possible to keep
> > the cache in a generic place where everyone using opc2c would be
> > able to leverage it ?
> 
> Well, that depends on the memory management scheme that the simulator
> is using.  In the RX case, it's using page tables, so when a page of
> memory is allocated, the corresponding page of decode pointers is
> allocated as well.  Technically, it's not a "cache" in that sense, as
> we store *all* decodes, not just the LRU ones.
> 
> Plus, the information that's cached isn't the decode logic that opc2c
> produces, it's the semantic logic that rx-decode.opc adds on top of
> that.  Look at sim/m32c/m32c.opc for an alternate example.  The decode
> is the same, but the semantics are completely different.

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

> > also, on a semi-related note, i cant find any documentation or info
> > in the archives on opc2c.  it seems to have been quietly merged with
> > the rx port and not really given any public info.  looking at the rx
> > opc file, it seems like it'd be useful to port some peeps over to
> > it.
> 
> I agree.  I'm working on porting the m32c opcodes over to it, but so
> many other things are higher on my priority list...
> 
> opc2c was originally used in my m32c simulator, but was undocumented
> there too.  It's not RX-specific (not with two chips behind it) but it
> is designed to decode CISC architectures, like the m32c, RX, or i386.
> Specifically, cases where you don't know the length of the opcode
> until you've started decoding it.
> 
> All it does, however, is build the decode logic and pull out the
> operands.  It doesn't decode the semantics at all; it's just a way of
> building a complex if/switch tree from some comments.

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

Attachment: signature.asc
Description: This is a digitally signed message part.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]