From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 723 invoked by alias); 29 Jul 2010 19:34:15 -0000 Received: (qmail 488 invoked by uid 22791); 29 Jul 2010 19:34:14 -0000 X-SWARE-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Jul 2010 19:34:06 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o6TJXudi018842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Jul 2010 15:33:56 -0400 Received: from greed.delorie.com ([10.3.112.10]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o6TJXs9A010933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jul 2010 15:33:55 -0400 Received: from greed.delorie.com (greed.delorie.com [127.0.0.1] (may be forged)) by greed.delorie.com (8.14.3/8.14.3) with ESMTP id o6TJXrKl018299; Thu, 29 Jul 2010 15:33:53 -0400 Received: (from dj@localhost) by greed.delorie.com (8.14.3/8.14.3/Submit) id o6TJXrRa018296; Thu, 29 Jul 2010 15:33:53 -0400 Date: Thu, 29 Jul 2010 19:34:00 -0000 Message-Id: <201007291933.o6TJXrRa018296@greed.delorie.com> From: DJ Delorie To: Mike Frysinger CC: gdb-patches@sourceware.org In-reply-to: <201007291523.07679.vapier@gentoo.org> (message from Mike Frysinger on Thu, 29 Jul 2010 15:23:06 -0400) Subject: Re: [rx sim] add decode cache References: <201007291841.o6TIfcgn017022@greed.delorie.com> <201007291523.07679.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/msg00552.txt.bz2 > 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. > 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.