From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22049 invoked by alias); 30 Jan 2008 18:15:56 -0000 Received: (qmail 22029 invoked by uid 22791); 30 Jan 2008 18:15:56 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Jan 2008 18:15:24 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.1/8.14.1) with ESMTP id m0UIBKt7018004; Wed, 30 Jan 2008 19:11:20 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.1/8.14.1/Submit) id m0UIBJS0006582; Wed, 30 Jan 2008 19:11:19 +0100 (CET) Date: Wed, 30 Jan 2008 18:27:00 -0000 Message-Id: <200801301811.m0UIBJS0006582@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: bauerman@br.ibm.com CC: drow@false.org, luisgpm@linux.vnet.ibm.com, gdb-patches@sourceware.org In-reply-to: <1201706206.11950.237.camel@localhost.localdomain> (message from Thiago Jung Bauermann on Wed, 30 Jan 2008 13:16:46 -0200) Subject: Re: Printing decimal128 types out of registers References: <1200927274.32125.36.camel@localhost.localdomain> <200801211730.m0LHUGbu021315@brahms.sibelius.xs4all.nl> <1194460412.6686.34.camel@localhost> <1200596592.27321.20.camel@gargoyle> <1200598580.32125.11.camel@localhost.localdomain> <1200670954.10815.1.camel@gargoyle> <20080119000423.GA15057@caradoc.them.org> <1200927274.32125.36.camel@localhost.localdomain> <20080121175413.GA25254@caradoc.them.org> <1201101039.11950.56.camel@localhost.localdomain> <20080123152007.GA8286@caradoc.them.org> <1201706206.11950.237.camel@localhost.localdomain> 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: 2008-01/txt/msg00811.txt.bz2 > From: Thiago Jung Bauermann > Date: Wed, 30 Jan 2008 13:16:46 -0200 > > > If this is too complicated, I wouldn't argue against a patch that just > > added them if the floating point regsiters are present. Seems like it > > won't be useful on a lot of processors though. > > Actually, this option is more appropriate. I have recently learned that > there are some regular float instructions which can be directly used in > DFP values stored in FP registers, like fabs, fneg and the other > floating point move instructions. So it is very useful to have the > pseudo-registers around even without specific DFP hardware. > > The attached patch is a rework of Luis' patch, with the following > modifications: > > - don't use tdesc XML machinery to define the DFP pseudo-regs; > - fixed logic in rs6000_pseudo_register_reggroup_p as noted by Daniel; > - put DFP pseudo-regs in float register group; > - the DFP pseudo-regs don't show up if there's no FPU; > - reorganized the pseudo_register_{read,write} functions: there's now > a generic one which concentrates the gdb_asserts and checking, and > calls either the SPE or DFP as appropriate. > - documentation: mention the DFP pseudo-regs in the Decimal Floating > Point subsection, and created a PowerPC architecture subsection to > talk about them in more detail. I had to rename the PowerPC Embedded > section to avoid a node name conflict. > > This patch is on top of the SPE macro cleanup patch which I just posted: > > http://sourceware.org/ml/gdb-patches/2008-01/msg00794.html > > Is this ok? Looks mostly reasonable to me, but I don't see why you need ppc_dl0_upper_regnum, and ppc_dl15_regnum.