From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31048 invoked by alias); 30 Jul 2010 01:04:39 -0000 Received: (qmail 31038 invoked by uid 22791); 30 Jul 2010 01:04:38 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_05,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 01:04:28 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o6U14Qji024592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 29 Jul 2010 21:04:26 -0400 Received: from mesquite.lan ([10.3.113.3]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o6U14PSn028049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 29 Jul 2010 21:04:26 -0400 Date: Fri, 30 Jul 2010 01:04:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Subject: Re: [rx sim] add decode cache Message-ID: <20100729180425.26894989@mesquite.lan> In-Reply-To: <201007292200.o6TM0TlC021758@greed.delorie.com> References: <201007291841.o6TIfcgn017022@greed.delorie.com> <201007291523.07679.vapier@gentoo.org> <201007291933.o6TJXrRa018296@greed.delorie.com> <201007291741.50553.vapier@gentoo.org> <201007292200.o6TM0TlC021758@greed.delorie.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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/msg00571.txt.bz2 On Thu, 29 Jul 2010 18:00:29 -0400 DJ Delorie wrote: > For the m32c, I used opc2c for the simulator, and cgen was used for > everything else. For RX, opc2c was pushed to libopcodes, and it's > used for the simulator, disassembler, *and* gdb. Nowhere else are RX > opcodes decoded. Maybe Kevin can comment on how different it was to > use opc2c's decoder for gdb's prolog analyzer? Use of opc2c's decoder in writing GDB's prologue analyzer has several advantages over the ad hoc decoders that we often write for a GDB architecture port: 1) There's usually some amount of effort required to understand the instruction set encodings, and additional effort require to decide how to best decode the ones that GDB might care about. Use of the opc2c decoder meant that much of that work was already done. The author of the prologue analyzer must still have a rudimentary understanding of the instruction encodings though. (E.g. are the instructions fixed width or variable width? What's the length of the shortest instruction? Etc.) 2) The ad hoc instruction decoders that I've either written, or have worked upon for GDB usually involve masking some magic number with the instruction under consideration and then comparing that result with another magic number. Sometimes these magic numbers are made a bit less magic by mapping them to a symbolic constant via the use of a suitable define or enum. But coming up with them is error prone and it's by no means certain that code using them is adequately tested. The opc2c decoder, on the other hand, already has symbolic constants assigned to each instruction. There is greater certainty that the decoded instruction is correct since it's used in the simulator and disassembler too. 3) The opc2c decoder decodes the instruction's operands too. When writing an ad hoc decoder, the operand decoding is usually accomplished via shifts, masks, etc. Again, there are more magic numbers involved, and yet more sources of error that can easily creep into the prologue analyzer. I do recall, however, being a bit surprised by the operand order for one of the RX instructions at one point. Not a big deal, but it's worth noting that the prologue analyzer's author still has to take some care to get things right. So, to summarize... The opc2c decoder is better tested since it is used in other tools. Due to the fact that it provides symbolic decoding of the opcodes and operands, prologue analyzer code is easier to write, and has a better chance of being correct. There is also a savings of development time since the author of the prologue analyzer need not do a detailed analysis of instruction and operand formats. Kevin