From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6028 invoked by alias); 16 Feb 2004 16:20:37 -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 5954 invoked from network); 16 Feb 2004 16:20:35 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 16 Feb 2004 16:20:35 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id BB4A61A448A; Mon, 16 Feb 2004 11:16:22 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16432.60630.254802.622655@localhost.redhat.com> Date: Mon, 16 Feb 2004 16:20:00 -0000 To: gdb-patches@sources.redhat.com Subject: Re: [RFA] sh-tdep.c: optimize and rename virtual register conversion functions In-Reply-To: <20040216155533.GI18953@cygbert.vinschen.de> References: <20040210161422.GI4162@cygbert.vinschen.de> <16432.57568.176468.343897@localhost.redhat.com> <20040216155533.GI18953@cygbert.vinschen.de> X-SW-Source: 2004-02/txt/msg00409.txt.bz2 Corinna Vinschen writes: > On Feb 16 10:25, Elena Zannoni wrote: > > Corinna Vinschen writes: > > > Hi, > > > > > > the functions sh_sh4_register_convert_to_virtual and > > > sh_sh4_register_convert_to_raw are only called once each. In both > > > cases, the register numbers are already tested for the correct range, > > > before the function is actually called. Therefore it's possible to > > > optimize the register number tests away from both functions. > > > > > > Also, I'd like to propose to rename both functions to get rid of the > > > "sh4" in the name. The functions are universal so I'd like to reuse > > > them for an upcoming SH variant with different virtual register numbering, > > > if that's ok. > > > > > > Can you elaborate a bit about this new SH variant? > > It will introduce a couple of new real registers which requires to > increment the pseudo double precision register numbers. At the moment > I can't go into too much detail otherwise. > > > Is the test in the > > function conflicting with a different test for the new variant? > > Actually, it was a thinko on my side. The new variant will result > in incrementing SH_NUM_REGS but when I sent this patch, I was still > using another register count for this very cpu. Therefore, the > register test is only superfluous, nothing else. It does not conflict > with anything. > > So, if you think that the test should be kept in that function, that's > fine with me. The only remaining bit is the naming of the function then. > The new cpu is not a sh4 type, but it's using the same pseudo register > functions as the sh4. The function would just not be sh4 specific anymore. Ok, thanks. Just rename the function for now, we can revisit later. elena