From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9532 invoked by alias); 30 Jul 2010 00:17:16 -0000 Received: (qmail 9521 invoked by uid 22791); 30 Jul 2010 00:17:15 -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; Fri, 30 Jul 2010 00:17:11 +0000 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o6U0H847018320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Jul 2010 20:17:08 -0400 Received: from greed.delorie.com ([10.3.112.10]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o6U0H6Xx018539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jul 2010 20:17:07 -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 o6U0H6kE024854; Thu, 29 Jul 2010 20:17:06 -0400 Received: (from dj@localhost) by greed.delorie.com (8.14.3/8.14.3/Submit) id o6U0H6lM024851; Thu, 29 Jul 2010 20:17:06 -0400 Date: Fri, 30 Jul 2010 00:17:00 -0000 Message-Id: <201007300017.o6U0H6lM024851@greed.delorie.com> From: DJ Delorie To: Mike Frysinger CC: gdb-patches@sourceware.org In-reply-to: <201007291941.18708.vapier@gentoo.org> (message from Mike Frysinger on Thu, 29 Jul 2010 19:41:17 -0400) Subject: Re: [rx sim] add decode cache References: <201007291841.o6TIfcgn017022@greed.delorie.com> <201007291741.50553.vapier@gentoo.org> <201007292200.o6TM0TlC021758@greed.delorie.com> <201007291941.18708.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/msg00570.txt.bz2 > 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. In the case of the m32c, the cgen implementation is *so* complex, that there's still a few opcodes it doesn't support, and I haven't been able to figure out how to fix it yet. CGEN at the time really didn't like variable length opcodes.