Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: DJ Delorie <dj@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [rx sim] add decode cache
Date: Thu, 29 Jul 2010 21:42:00 -0000	[thread overview]
Message-ID: <201007291741.50553.vapier@gentoo.org> (raw)
In-Reply-To: <201007291933.o6TJXrRa018296@greed.delorie.com>

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

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 #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2010-07-29 21:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-29 18:42 DJ Delorie
2010-07-29 19:23 ` Mike Frysinger
2010-07-29 19:34   ` DJ Delorie
2010-07-29 21:42     ` Mike Frysinger [this message]
2010-07-29 22:00       ` DJ Delorie
2010-07-30  0:09         ` Mike Frysinger
2010-07-30  0:17           ` DJ Delorie
2010-07-30  1:04         ` Kevin Buettner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201007291741.50553.vapier@gentoo.org \
    --to=vapier@gentoo.org \
    --cc=dj@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox