From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5320 invoked by alias); 5 Jan 2004 15:50:53 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 5313 invoked from network); 5 Jan 2004 15:50:52 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 5 Jan 2004 15:50:52 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id BD24F2B8F; Mon, 5 Jan 2004 10:50:53 -0500 (EST) Message-ID: <3FF987DD.9080908@gnu.org> Date: Mon, 05 Jan 2004 15:50:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 MIME-Version: 1.0 To: fnf@ninemoons.com Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Remove some hardwired assumptions about register sets References: <200312170614.hBH6Ebtl003033@fred.ninemoons.com> <20031223020339.GA13570@nevyn.them.org> <3FF5C642.3000504@gnu.org> <200401021611.11737.fnf@ninemoons.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg00092.txt.bz2 >> Daniel, the patch adds a global variable "num_mips_processor_regs" > > > We could use a new "tdep->num_mips_processor_regs" variable instead. > That is probably cleaner anyway. > > >> I'm wondering what motivated the change? >> ... sidestep the issue >> ... made all the arrays the same size. > > > The problem is the assumption that all the arrays are the same size, > or perhaps more fundamentally, that "all mips architectures will have > registers sets of similar size'. The number of registers is determined by "num_regs". Thinking about it, wouldn't ->num_mips_processor_regs be redundant information? > I'm working on port, which will soon be contributed, that currently > adds 384 new register names (reg numbers 32-415) for a matrix > coprocessor (cop 2). > > When contributed though the names will be reduced to just 69 new > names (32-100). The original port assigned separate register names to > each of the individual 256 matrix elements (16 vectors of 16 elements) > instead of handling each 16 element vector as a single named vector > register. > > Still, even with 69 new names, it gets really ugly having all the > other *_reg_name[] arrays have to be full of mostly null strings. True, but it isn't that much memory. Does setting "num_regs" to ARRAY_SIZE (relevant register name array) + magic:32 work? What of the function deprecated_mips_set_processor_regs_hack which would need an array size sanity check. Andrew