From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2192 invoked by alias); 29 Jul 2010 21:42:31 -0000 Received: (qmail 2184 invoked by uid 22791); 29 Jul 2010 21:42:31 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Jul 2010 21:42:25 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 1A7ED1B40C2; Thu, 29 Jul 2010 21:42:24 +0000 (UTC) From: Mike Frysinger To: DJ Delorie Subject: Re: [rx sim] add decode cache Date: Thu, 29 Jul 2010 21:42:00 -0000 User-Agent: KMail/1.13.1 (Linux/2.6.34; KDE/4.4.5; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <201007291841.o6TIfcgn017022@greed.delorie.com> <201007291523.07679.vapier@gentoo.org> <201007291933.o6TJXrRa018296@greed.delorie.com> In-Reply-To: <201007291933.o6TJXrRa018296@greed.delorie.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1707885.NQO4QOeExj"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201007291741.50553.vapier@gentoo.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-07/txt/msg00562.txt.bz2 --nextPart1707885.NQO4QOeExj Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-length: 2327 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 ? >=20 > 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. >=20 > 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 coul= d=20 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. >=20 > I agree. I'm working on porting the m32c opcodes over to it, but so > many other things are higher on my priority list... >=20 > 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. >=20 > 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=20 decode/sim, we too have a big tree of if/switch/masks to pull out arguments= .=20=20 ive always been annoyed that we had to copy the decode file, gut it, and th= en=20 fill in the sim pieces to make it work. seems like this opc2c might be a w= ay=20 back from that. -mike --nextPart1707885.NQO4QOeExj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. Content-length: 836 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iQIcBAABAgAGBQJMUfWeAAoJEEFjO5/oN/WBnL8QAM+M5U8FU46YhsI5ojTD/8mV 5KWF/sJxMXSDDJ3vlUjyJScnje7uGsJacMcP87bJtlxZ3YluhSHWDCtcGCUGnvvG GH9IjRcoW5pB5I5tlpdKO7AU+DtkYrY/Va1V3YTZMYcfTAzRVs0hc3+IfnIMWq/p go2MsrT3EVImiiFQ2kkI5GTEhOFzBq4KJdkf5zbVJbGbMPN/flyRaUlZ4OgQYz+l ZNa7GoHD0ZRvq94y8JBpoC3YX4tCGWyZ5A++GeqmMrGiuA5V3vRRwui6T+0fPaVW h+lSwemyGaQu2xmTLOD38X/q7bNQ1TMPnXbYblBsosaRlF1yYJXk7ybWHY9lxG9N pIFMs8/Wt7qE70762LtXO7hEK0eEmsmpWvlxZEaaZwnRtQUVY2y0Z6KR6dqdLpOp /KIvXVT/Di3tQfhq1xkkAnFtqNEgqtIpcPEVcgfirnSXebXZLieFNQql82/02MK4 CDo2kUz1RZU5sUN+8K7tJfwX2hMC5QpELJ546UHhzrl/wYZgU//aXohH1/3MBuas 6gsqpWmAw5ZS3wm28DW895SZKelFNrEuflNZKWeKWDtmeR6uCfvlyhK9cM/bIfmj 4oFJdI8JNKzTlx8dZIc94kty6LUqGWCe0HTrV1MI8WbCNU5QZa/QsJjgL/RQmpkc czNNPRGk7CWTsYf3nGlC =pfY6 -----END PGP SIGNATURE----- --nextPart1707885.NQO4QOeExj--