From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2501 invoked by alias); 15 Jun 2003 01:44:24 -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 19100 invoked from network); 15 Jun 2003 01:36:39 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by sources.redhat.com with SMTP; 15 Jun 2003 01:36:39 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7C3912B5F; Sat, 14 Jun 2003 21:36:04 -0400 (EDT) Message-ID: <3EEBCD84.6010005@redhat.com> Date: Sun, 15 Jun 2003 01:44:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cgd@broadcom.com Cc: Kevin Buettner , gdb-patches@sources.redhat.com Subject: Re: [WIP/RFC] MIPS registers overhaul References: <1030510002453.ZM3880@localhost.localdomain> <3EBD6131.30209@redhat.com> <1030514220025.ZM10373@localhost.localdomain> <3EC461C1.1080104@redhat.com> <3ECA8EC6.6030405@redhat.com> <3ECB9DE2.1020906@redhat.com> Content-Type: multipart/mixed; boundary="------------080504050405060106010009" X-SW-Source: 2003-06/txt/msg00504.txt.bz2 This is a multi-part message in MIME format. --------------080504050405060106010009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 7 Chris? --------------080504050405060106010009 Content-Type: message/rfc822; name="mailbox-message://ac131313@movemail/fsf/gdb/patches#8430822" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mailbox-message://ac131313@movemail/fsf/gdb/patches#8430822" Content-length: 4907 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: cagney@localhost.redhat.com Received: from localhost (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id E028E2B2F for ; Wed, 21 May 2003 11:54:00 -0400 (EDT) Envelope-to: cagney@gnu.org Delivery-date: Wed, 21 May 2003 11:48:51 -0400 Received: from fencepost.gnu.org by localhost with IMAP (fetchmail-6.2.1) for cagney@localhost (single-drop); Wed, 21 May 2003 11:54:00 -0400 (EDT) Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.20) id 19IVpj-0006xH-D1 for cagney@gnu.org; Wed, 21 May 2003 11:48:51 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19IVja-0007mk-Nj for cagney@gnu.org; Wed, 21 May 2003 11:43:01 -0400 Received: from sources.redhat.com ([66.187.233.205]) by monty-python.gnu.org with smtp (Exim 4.20) id 19IVhe-0007Lm-Kz for cagney@gnu.org; Wed, 21 May 2003 11:40:30 -0400 Received: (qmail 19692 invoked by alias); 21 May 2003 15:40:30 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Delivered-To: mailing list gdb-patches@sources.redhat.com Received: (qmail 19642 invoked from network); 21 May 2003 15:40:29 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 21 May 2003 15:40:29 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 4DEE02B2F; Wed, 21 May 2003 11:40:18 -0400 (EDT) Message-ID: <3ECB9DE2.1020906@redhat.com> Date: Wed, 21 May 2003 11:40:18 -0400 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cgd@broadcom.com Cc: Kevin Buettner , gdb-patches@sources.redhat.com Subject: Re: [WIP/RFC] MIPS registers overhaul References: <1030510002453.ZM3880@localhost.localdomain> <3EBD6131.30209@redhat.com> <1030514220025.ZM10373@localhost.localdomain> <3EC461C1.1080104@redhat.com> <3ECA8EC6.6030405@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.3 required=5.0 tests=FROM_ENDS_IN_NUMS,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 X-Spam-Level: Content-length: 1852 > At Tue, 20 May 2003 16:23:34 -0400, Andrew Cagney wrote: > >> When a 64 bit kernel goes to save/resume an o32 process, how does it do >> it? Does it have a choice? > > > it has limited choice. > > > >> For instance, do a 64 bit FP restore then clear the FR bit; the reverse; >> some other variant; ...? > > > So, if the process is running with FR=0, then the save/restore should > ("must" i believe) be done with FR=0. > > When FR=0, there are two options as to how to do it: > > for (i = 0; i < 32; i++) > move/store word from c1 reg $i (i.e., dmfc1/sdc1) > > OR: > > for (i = 0; i < 32; i += 2) > move/store dword from c1 reg $i (i.e., dmfc1/sdc1) That isn't quite the detail I was looking for. Does the code need to look like: save:: save FSR if (FSR & FR) save 32x32 FP else save 32x64 FP restore:: restore FSR if (FSR & FR) restore 32x32 FP else restore 32x64 FP that is, the FSR[FR] bit (wonder if I've got the names right) needs to set/clear the FR bit before it even starts to consider saving/restoring the other registers. The reverse operation: save:: save FSR make FP registers 64 bit save 32x64 FP restore:: // assume FSR[FR] set to 64 bit mode restore 32x64 FP restore FSR operation not being valid. Andrew > (move to / load for the state restore, of course.) > > (of course, these will typically be written in assembly code, and > "fully unrolled" -- the pseudo-C-code is to demonstrate the concept > only.) > > either one is valid, though all implementations that I know of choose > the latter because it's fewer instructions and almost certainly more > efficient. > > > the linux kernel presents that to o32 userland (o32 ptrace syscall) as > an array of 32 32-bit values, but IIRC it's stored internally as (8 > byte reg, 8 byte pad) * 16. > > > > cgd > > --------------080504050405060106010009--