From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15879 invoked by alias); 13 Dec 2005 22:43:15 -0000 Received: (qmail 15872 invoked by uid 22791); 13 Dec 2005 22:43:15 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 13 Dec 2005 22:43:14 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id jBDMhCYN013710 for ; Tue, 13 Dec 2005 17:43:12 -0500 Received: from post-office.corp.redhat.com (post-office.corp.redhat.com [172.16.52.227]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id jBDMhB112392 for ; Tue, 13 Dec 2005 17:43:11 -0500 Received: from greed.delorie.com (dj.cipe.redhat.com [10.0.0.222]) by post-office.corp.redhat.com (8.11.6/8.11.6) with ESMTP id jBDMhBN22641 for ; Tue, 13 Dec 2005 17:43:11 -0500 Received: from greed.delorie.com (greed.delorie.com [127.0.0.1]) by greed.delorie.com (8.13.1/8.13.1) with ESMTP id jBDMhBaI025314 for ; Tue, 13 Dec 2005 17:43:11 -0500 Received: (from dj@localhost) by greed.delorie.com (8.13.1/8.13.1/Submit) id jBDMh6MN025311; Tue, 13 Dec 2005 17:43:06 -0500 Date: Wed, 14 Dec 2005 18:40:00 -0000 Message-Id: <200512132243.jBDMh6MN025311@greed.delorie.com> From: DJ Delorie To: gdb-patches@sourceware.org In-reply-to: () Subject: Re: RFA: contribute Renesas M32C sim References: <20051009201500.GD7107@nevyn.them.org> 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/msg00219.txt.bz2 > >> + 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.