From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30666 invoked by alias); 16 Jun 2003 20:06:07 -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 30619 invoked from network); 16 Jun 2003 20:06:05 -0000 Received: from unknown (HELO mms3.broadcom.com) (63.70.210.38) by sources.redhat.com with SMTP; 16 Jun 2003 20:06:05 -0000 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.5.2)); Mon, 16 Jun 2003 13:06:10 -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 NAA02499; Mon, 16 Jun 2003 13:05:38 -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 h5GK5xov016011; Mon, 16 Jun 2003 13:05:59 -0700 (PDT) Received: (from cgd@localhost) by ldt-sj3-010.sj.broadcom.com ( 8.11.6/8.9.3) id h5GK5x828046; Mon, 16 Jun 2003 13:05:59 -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> <3EECAB89.10609@redhat.com> From: cgd@broadcom.com Date: Mon, 16 Jun 2003 20:06:00 -0000 In-Reply-To: <3EECAB89.10609@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-WSS-ID: 12F0FCB81171446-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00544.txt.bz2 It's unfair to make me think really hard after being gone for almost a week. I've had to resort to experimental analysis. 8-) It would be good, BTW, to reference against the MIPS32 or MIPS64 specs; I dunno that everybody in the world has a MIPS IV spec, and certainly I might but if i do it's not as handy. At Sun, 15 Jun 2003 13:23:21 -0400, Andrew Cagney wrote: > >> 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) > > mfc1/sc1 yah. > > OR: > > for (i = 0; i < 32; i += 2) > > move/store dword from c1 reg $i (i.e., dmfc1/sdc1) > > OK, I'm going to go out on a limb here. I don't think the two are > equivalent, and I think the second is wrong. For big-endian, the > second would store fp[n+0] ||| fp[n+1] backwards. No, the two are not equivalent, in terms of the memory layout that results on big endian systems. (On little-endian systems, AFAICT they end up producing the same results.) However, neither is more correct w.r.t. what's allowed by the MIPS architecture; both will work with MIPS2 and later hardware. Doing the stores as dwords is clearly more efficient, though. > When extracting a double from a MIPS register pair, GDB does the rough > equivalent of: > > [...] > > (See register_to_type. The code dates back to ~92 and was added to > fix IRIX double value display problems.) The effect is to always get > the least significant part of a double value from fp[n+0], and the > most significant from fp[n+1]. Err, I'm not sure what code you reference. I couldn't find "register_to_type" (case insensitively), anywhere in the GDB source. I do note that the code in mips-tdep.c: static void mips_read_fp_register_single (struct frame_info *frame, int regno, char *rare_buffer) static void mips_read_fp_register_double (struct frame_info *frame, int regno, char *rare_buffer) but i'm not sure whether your pseudo-code above is meant to convey the operation of the latter, and, if so for 8-byte FPRs (with the mips2 compat thing), or 4 byte FPRs... (8 byte FPRs with mips2 compat looks ... scary. 8-) > Given MIPS xor endian sillyness, I'm not quite sure which silliness you mean. The "ReverseEndian" xoring (in the pseudo-code) happens only if Status:RE is set. I'll admit that the 'bytesel' logic in the sw/swc1 ops takes a while to understand. 8-) Normally (when RE is not set) it behaves in (IMO) a sane enough way... > Anyway, this, I believe, means that any implementation of: > > union { > float flt; > double dbl; > int32 i32; > int64 i64; > } $fp0 > > is going to need, for BE, a big-byte little-word DOUBLE, and a similar > INT64. Otherwize, $f0.int32 would modify the wrong part of the double > register. Alternatively, some of those union values could be given > magic offsets. Looking at kevin's patch: Right. I think the "assume 4 bytes of pad before the 4-byte item" is the right way to look at it. And then to follow on from that: * if 32-bit FPU (32-bit MIPS or 64-bit MIPS with FR == 0), assume you have 16 of them, or * if 64-bit FPU, you have 32. (at least, that's the way it should work for "normal" FPU usage. For single-float, where $f0 and $f1 contain independent singles, it's another story.) Re: your other message, re: the kernel shifting them around: I *think* that the linux kernel does shift things around as appropriate, at least for the r4k-and-later chips. (TBH, I'm not sure that it's correct for the r2k/r3k.) It's been so long that i forgot what the issue at the root of this disucssion was. Could you remind me? 8-) cgd -- Chris Demetriou Broadcom Corporation Principal Design Engineer Broadband Processor Business Unit Any opinions expressed in this message are mine, not necessarily Broadcom's.