From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17102 invoked by alias); 13 Dec 2005 22:47:26 -0000 Received: (qmail 17094 invoked by uid 22791); 13 Dec 2005 22:47:25 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 13 Dec 2005 22:47:24 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EmIva-0003mG-Sf for gdb-patches@sourceware.org; Tue, 13 Dec 2005 17:47:22 -0500 Date: Thu, 15 Dec 2005 00:01:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Subject: Re: RFA: contribute Renesas M32C sim Message-ID: <20051213224722.GA14462@nevyn.them.org> Mail-Followup-To: gdb-patches@sourceware.org References: <20051009201500.GD7107@nevyn.them.org> <200512132243.jBDMh6MN025311@greed.delorie.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200512132243.jBDMh6MN025311@greed.delorie.com> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00220.txt.bz2 On Tue, Dec 13, 2005 at 05:43:06PM -0500, DJ Delorie wrote: > > > >> + void > > >> + prefix (src_allowed, dest_allowed, index_bytewidth) > > >> + { > > >> + } > > > > > > And what's that for? > > > > I don't know. I thought it was some sort of annotation for opc2c to > > consume, but that doesn't seem to be so. I'll find out. > > I remember talking to Jim about this, but I don't see him answering in > the mail archives, and since I was checking on the m32c/gdb status I > figured I'd at least get this one answered. > > In short, that function exists so it can be called, it's the callers > that are important at the moment. > > The callers act as documentation for what prefixes and indexes are > permitted for each opcode. As I was going through the tedious process > of implementing each opcode, I added all the calls to prefix() with > the correct arguments. The function does nothing yet, but at some > point in the future it may fault if prefixes are used where the real > chip doesn't support them. Then please add some useful information there, so that the next reviewer through the code does not remove it :-) -- Daniel Jacobowitz CodeSourcery, LLC