From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11342 invoked by alias); 1 Jul 2002 21:24:55 -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 11314 invoked from network); 1 Jul 2002 21:24:50 -0000 Received: from unknown (HELO potter.sfbay.redhat.com) (205.180.83.107) by sources.redhat.com with SMTP; 1 Jul 2002 21:24:50 -0000 Received: from localhost.redhat.com (IDENT:kCV47x5QkGo1W/0wRN66Agah/Q45MDpq@romulus.sfbay.redhat.com [172.16.27.251]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g61LQ1Q13011; Mon, 1 Jul 2002 14:26:01 -0700 Received: by localhost.redhat.com (Postfix, from userid 469) id 9FCA6107D6; Mon, 1 Jul 2002 17:24:00 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15648.51312.63195.689336@localhost.redhat.com> Date: Mon, 01 Jul 2002 14:24:00 -0000 To: Joern Rennecke Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: Unreviewed patches In-Reply-To: <3D208CF1.AB7AC45A@superh.com> References: <3D205F19.1B99290F@superh.com> <15648.31077.572892.886182@localhost.redhat.com> <3D208CF1.AB7AC45A@superh.com> X-SW-Source: 2002-07/txt/msg00012.txt.bz2 Joern Rennecke writes: > Elena Zannoni wrote: > > > > Joern Rennecke writes: > > > Wed Jun 12 13:20:51 2002 J"orn Rennecke > > > > > > include/gdb: > > > * sim-sh.h: Add enum constants for sh[1-4], sh3e, sh3?-dsp. > > > > Yes, sorry for the delay. > > > > Is there any real reason to not just have one enum, which included the > > dsp registers as well? > > Yes. The values are supposed to stay the same, to retain compatibility. > Besides, you would need to re-design parts of the simulator to remove > the overlaps. > OK, I see what you are saying, but I don't think that removing the overlaps from the gdb<->sim interface necessarily forces you to remove the overlaps from inside the simulator. It just cleans up the sim_fetch_register and sim_store_register code. I am not sure I understand your claim about compatibility. You mean older gdb's with new sims? That cannot happen. Or you mean the layout of the registers that gdb has internally? That is staying the same (and the 'g' packet layout stays the same as well) The thing you need is to define a 'translation' step in gdb between gdb and sim register numbering schemes. Much the same as dwarf2_reg_to_regnum & friends do between gcc and gdb. > > I mean, if the simulator didn't reuse register > > numbers for FP regs and DPS regs, then you could get rid of this ugly > > code in interp.c: > > > > else case 44: > > if (target_dsp) > > RE = val; > > else case 45: case 46: case 47: case 48: case 49: case 50: > > [...] > > case 26: > > val = target_dsp ? A0 : FI (1); > > break; > > [...] > > etc. etc. > > > > And with that you could get rid of the target_dsp variable. > > Definitely not. The same 0xfxxx opcodes mean different things to sh3-dsp > and sh3e. > Using the same register number for fpscr and dsr is natural, since the same > opcodes are used to load/store dsr on sh3-dsp and fpscr on sh3e. > Ok, I see that the variable is used in the simulation of those instructions. But that bears no relation with the interface we are trying to define here. > > I think the changes below depend on the cgen patches being accepted first. > > They have. > I don't see any replies to your message to the cgen/gdb-patches lists. Elena > -- > -------------------------- > SuperH > 2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ > T:+44 1454 462330