From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25177 invoked by alias); 6 Dec 2006 21:21:09 -0000 Received: (qmail 25167 invoked by uid 22791); 6 Dec 2006 21:21:09 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 06 Dec 2006 21:21:02 +0000 Received: (qmail 15862 invoked from network); 6 Dec 2006 21:20:59 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 Dec 2006 21:20:59 -0000 To: "Ulrich Weigand" Cc: drow@false.org (Daniel Jacobowitz), gdb-patches@sourceware.org Subject: Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix) References: <200612061629.kB6GTROh021274@d12av02.megacenter.de.ibm.com> From: Jim Blandy Date: Wed, 06 Dec 2006 21:21:00 -0000 In-Reply-To: <200612061629.kB6GTROh021274@d12av02.megacenter.de.ibm.com> (Ulrich Weigand's message of "Wed, 6 Dec 2006 17:29:27 +0100 (CET)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00078.txt.bz2 That analysis of the current use of the r2v/v2r functions is really helpful. I feel very happy to have a thorough and detailed explanation of what's going on. Thank you, Ulrich. It seems to me the hard case to deal with is the alpha STS/LDS conversions. If I understand properly, the alpha's issue here is as follows: - a 32-bit float stored in a floating-point register with LDS gets converted to a 64-bit floating-point value. Extracting it with STS does the reverse, but in a way that preserves the exact bit pattern. So the LDS and STS instructions can be used to store 32-bit integers as well as 32-bit floats, although the integer's bits get re-interpreted as float fields and the value looks odd. And this is the standard way to handle 32-bit integers stored in floating-point registers. - a 64-bit structure can also be stored in a floating-point register, with no bit rearrangement. So the alpha needs to distinguish three cases: a) a 32-bit integer in a floating-point register, mangled as a float. b) an integer of some size at some offset within the floating-point register, not mangled because it is part of a larger structure. c) a 64-bit value stored in the register. The alpha register_to_value function could represent a) as a value with a bitpos of 64, indicating that special decoding is necessary. It would represent b) and c) using normal bit positions and lengths. Wouldn't this work? Couldn't something similar be done for the 387? I'm reluctant to get into storing original types and having reference counts; it's a lot of complexity in the core code to handle architectures that are doing odd things. I've got unsubmitted patches for GDB that implement a new kind of value, whose contents are read and written via functions provided by the user, based on a generic closure pointer. Future r2v / v2r functions could produce values of this sort, instead of using odd bitpos values. So the kludge wouldn't last forever.