From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9415 invoked by alias); 16 Jun 2003 18:06:22 -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 9277 invoked from network); 16 Jun 2003 18:06:18 -0000 Received: from unknown (HELO mms1.broadcom.com) (63.70.210.58) by sources.redhat.com with SMTP; 16 Jun 2003 18:06:18 -0000 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.5.2)); Mon, 16 Jun 2003 11:06:11 -0700 Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA06695; Mon, 16 Jun 2003 11:05:49 -0700 (PDT) Received: from ldt-sj3-010.sj.broadcom.com (ldt-sj3-010 [10.21.64.10]) by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id h5GI6Aov012609; Mon, 16 Jun 2003 11:06:10 -0700 (PDT) Received: (from cgd@localhost) by ldt-sj3-010.sj.broadcom.com ( 8.11.6/8.9.3) id h5GI6AT25617; Mon, 16 Jun 2003 11:06:10 -0700 X-Authentication-Warning: ldt-sj3-010.sj.broadcom.com: cgd set sender to cgd@broadcom.com using -f To: "Andrew Cagney" 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> <3EEBCD84.6010005@redhat.com> From: cgd@broadcom.com Date: Mon, 16 Jun 2003 18:06:00 -0000 In-Reply-To: <3EEBCD84.6010005@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-WSS-ID: 12F0D8991094692-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00540.txt.bz2 At Sat, 14 Jun 2003 21:36:04 -0400, Andrew Cagney wrote: > Chris? Sorry, I must have missed that msg... 8-) > That isn't quite the detail I was looking for. Does the code need to > look like: > > save:: > save FSR > if (FSR & FR) *** when FR == 1, it's 32 64-bit registers. so, invert. > save 32x32 FP *** or, save 16 (even) 64-bit FP registers, if MIPS2 or later. *** in fact, on MIPS2 and later, better to do that, since it'll be *** more efficient (fewer instructions). > 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. It's Status:FR (or, SR:FR, but i prefer to call the regs by their proper names 8-). (also, "or, use notation of your choice." 8-) (it's in the normal CP0 status register, not in any of the FPU control registers. all of the latter are user-accessable, but Status:FR is not.) > 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. So, I looked at the specifications, and I don't couldn't find any place where this is defined by the current architecture to be UNPREDICTABLE, but i may have missed it. I would expect -- but haven't checked -- that this would work as well. Looking at the diagrams in the MIPS32 and MIPS64 specs which try to explain opration behaviour w/ the various FR modes, I think i'd *expect* it to work. Based on the diagrams in the manuals, I'd *expect* that if you do this, the even registers would contain all of the data used in FR=0 mode, and the odd registers would contain... whatever they were initialized with when FR was set to 0 initially. Personally, I wouldn't do this. 8-) Note also that some processors do have ... interesting hazards when changing Status:FR modes, too. If one can keep the number of FR mode changes to a minimum one can also reduce the number of hazard-avoidance sequences needed. In the former example, you do one Status:FR set per save/restore. In the latter, you do two. cgd -- Chris Demetriou Broadcom Corporation Principal Design Engineer Broadband Processor Business Unit Any opinions expressed in this message are mine, not necessarily Broadcom's.