From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31148 invoked by alias); 30 Apr 2002 23:38:01 -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 31133 invoked from network); 30 Apr 2002 23:37:58 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 30 Apr 2002 23:37:58 -0000 Received: from romulus.sfbay.redhat.com (remus.sfbay.redhat.com [172.16.27.252]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id QAA29416 for ; Tue, 30 Apr 2002 16:37:56 -0700 (PDT) Received: (from kev@localhost) by romulus.sfbay.redhat.com (8.11.6/8.11.6) id g3UNbpu22645 for gdb-patches@sources.redhat.com; Tue, 30 Apr 2002 16:37:51 -0700 Date: Tue, 30 Apr 2002 16:38:00 -0000 From: Kevin Buettner Message-Id: <1020430233751.ZM22644@localhost.localdomain> To: gdb-patches@sources.redhat.com Subject: [PATCH] rs6000-tdep.c: Add fpscr comment MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-04/txt/msg01167.txt.bz2 I've just committed the patch below. * rs6000-tdep.c: Added comment describing how fpscr register numbers were chosen. Index: rs6000-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v retrieving revision 1.62 diff -u -p -r1.62 rs6000-tdep.c --- rs6000-tdep.c 30 Apr 2002 00:26:43 -0000 1.62 +++ rs6000-tdep.c 30 Apr 2002 23:34:38 -0000 @@ -2026,7 +2026,21 @@ rs6000_convert_from_func_ptr_addr (CORE_ Most of these register groups aren't anything formal. I arrived at them by looking at the registers that occurred in more than one - processor. */ + processor. + + Note: kevinb/2002-04-30: Support for the fpscr register was added + during April, 2002. Slot 70 is being used for PowerPC and slot 71 + for Power. For PowerPC, slot 70 was unused and was already in the + PPC_UISA_SPRS which is ideally where fpscr should go. For Power, + slot 70 was being used for "mq", so the next available slot (71) + was chosen. It would have been nice to be able to make the + register numbers the same across processor cores, but this wasn't + possible without either 1) renumbering some registers for some + processors or 2) assigning fpscr to a really high slot that's + larger than any current register number. Doing (1) is bad because + existing stubs would break. Doing (2) is undesirable because it + would introduce a really large gap between fpscr and the rest of + the registers for most processors. */ /* Convenience macros for populating register arrays. */