From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3139 invoked by alias); 14 May 2004 11:59:44 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 3132 invoked from network); 14 May 2004 11:59:43 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 14 May 2004 11:59:43 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i4EBxh0m028806 for ; Fri, 14 May 2004 07:59:43 -0400 Received: from pobox.surrey.redhat.com (pobox.surrey.redhat.com [172.16.10.17]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i4EBxg327602; Fri, 14 May 2004 07:59:42 -0400 Received: from [172.31.0.98] (vpn50-23.rdu.redhat.com [172.16.50.23]) by pobox.surrey.redhat.com (8.12.8/8.12.8) with ESMTP id i4EBxUtl028861; Fri, 14 May 2004 12:59:38 +0100 Message-ID: <40A4B5B4.7030309@redhat.com> Date: Fri, 14 May 2004 11:59:00 -0000 From: Nick Clifton User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) MIME-Version: 1.0 To: Peter Barada CC: binutils@sources.redhat.com Subject: Re: objdump fails for ColdFire References: <20040508144302.86F96990F4@baradas.org> <40A3A5DB.6080302@redhat.com> <20040513233200.EDD2098C8A@baradas.org> In-Reply-To: <20040513233200.EDD2098C8A@baradas.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-05/txt/msg00279.txt.bz2 Hi Peter, >I'm thinking of splitting print_insn_m68k into two parts, the first >part which iterates over the table looking for opcodes that match, and >the second whihc would either accept an instruction (based on >opc->args) and print it out, or reject it. This function would be >called from the loop where 'best' is updated, and if reutrns a >non-zero then it had accepted and printed out the function. > > This is a very good idea. Note - you can use booleans rather than zero/non-zero for the return value. >I'm also looking at all the special code to deal with deciding which >alternates (i.e, wait for fmoveml instead of fmove if more than one >register) which appearenly is there since the opcode table is layed >out in alphabetical order instead of an order that would best suit the >disassembler. (then this special case wouldn't have to be there since >fmoveml could be placed *before* fmovel). > > Excellent - anything that removes special cases in favour of a more generic approach will get the thumbs up from me. Cheers Nick