From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31765 invoked by alias); 6 Dec 2006 23:16:16 -0000 Received: (qmail 31755 invoked by uid 22791); 6 Dec 2006 23:16:15 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate5.de.ibm.com (HELO mtagate5.de.ibm.com) (195.212.29.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 06 Dec 2006 23:16:08 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id kB6NG5Iu259730 for ; Wed, 6 Dec 2006 23:16:05 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kB6NG5gP3289194 for ; Thu, 7 Dec 2006 00:16:05 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kB6NG5tZ009164 for ; Thu, 7 Dec 2006 00:16:05 +0100 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id kB6NG5Z9009161; Thu, 7 Dec 2006 00:16:05 +0100 Message-Id: <200612062316.kB6NG5Z9009161@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 7 Dec 2006 00:16:05 +0100 Subject: Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix) To: jimb@codesourcery.com (Jim Blandy) Date: Wed, 06 Dec 2006 23:16:00 -0000 From: "Ulrich Weigand" Cc: drow@false.org (Daniel Jacobowitz), gdb-patches@sourceware.org In-Reply-To: from "Jim Blandy" at Dec 06, 2006 01:21:48 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00084.txt.bz2 Jim Blandy wrote: > 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? This misses the case a') an integer (bitfield) of some size < 32 bit that is part of a 32-bit integer in a floating-point register mangled as a float > 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. Note that my original proposal did not require refcounts, since it did not store pointers to struct value, only to types. (And value already contains pointers to types, so this is nothing new.) > 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. I'm not sure I see how this would solve the problem at hand: assume r2v creates a value containing special functions to read and write the register. Then common code goes and creates a value refering to a sub-field of that value. How do we access that derived value? Using the same access functions as provided for the full value -- but how do they know they should operate only on a part (which part)? It would appear that this is exactly the same problem as we're currently discussing ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com