From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32762 invoked by alias); 12 Oct 2005 14:42:52 -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 32733 invoked by uid 22791); 12 Oct 2005 14:42:49 -0000 Received: from ausmtp01.au.ibm.com (HELO ausmtp01.au.ibm.com) (202.81.18.186) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 12 Oct 2005 14:42:49 +0000 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp01.au.ibm.com (8.12.10/8.12.10) with ESMTP id j9CEjj7k286968 for ; Thu, 13 Oct 2005 00:45:45 +1000 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.250.244]) by sd0208e0.au.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9CEjkgZ173356 for ; Thu, 13 Oct 2005 00:45:46 +1000 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.12.11/8.13.3) with ESMTP id j9CEgjuU020784 for ; Thu, 13 Oct 2005 00:42:45 +1000 Received: from [9.181.133.252] ([9.181.133.252]) by d23av03.au.ibm.com (8.12.11/8.12.11) with ESMTP id j9CEggvn020766; Thu, 13 Oct 2005 00:42:43 +1000 Date: Wed, 12 Oct 2005 14:42:00 -0000 From: Wu Zhou To: Daniel Jacobowitz cc: bje@au1.ibm.com, gdb-patches@sources.redhat.com Subject: Re: [RFC] Decimal Floating Point support for GDB (Part 1: patch) In-Reply-To: <20051009200814.GB7107@nevyn.them.org> Message-ID: References: <20051002205724.GB31820@nevyn.them.org> <20051009200814.GB7107@nevyn.them.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2005-10/txt/msg00108.txt.bz2 On Sun, 9 Oct 2005, Daniel Jacobowitz wrote: > On Sun, Oct 09, 2005 at 01:27:10PM +0800, Wu Zhou wrote: > > > I'm afraid I am not very happy with this approach :-( > > > > > > * c-exp.y (parse_number): Parse the decimal floating point, which > > > has a suffix ('df', 'dd' or 'dl') and return STRING here. > > > > In fact. I am not very happy with that either. But this is what came out > > of my mind at this time, provided that gcc and glibc support for DFP is > > not ready yet. If the gdb-building compiler already support dfp types > > (_Decimal32, _Decimal64 and _Decimal64) and sscanf (GDB uses it to parse > > floating point number) could recognize and scan decimal types, I won't > > adopt this method. > > I'd rather work with decNumber than mix host and target types. > > > If we have a GDB type system representation for decimal floats, the C > > > parser should use it, and for lexing purposes it should probably be a > > > FLOAT. > > > > Okay. I didn't thought of adding a gdb type for decimal floats. Maybe I > > should (It seems to be a good approach). But I am not very familar > > with GDB's type system. Any clue about how to start? adding a > > builtin_type for DFP and letting it have three or more fields (like sign, > > coefficient, exponent...)? I will take some more looks into the code. > > Or just use the decNumber packed representation, in value_contents(). > Take a look at all the references to FLOATFORMAT to see how we handle > floating point types. I did had some looks at FLOATFORMAT, but found that there are quite some difference between DFP encoding format and normal binary floating encoding format: for example, dfp's fields is composed of combinator bits, exponent continuation bits and coefficient continuation bits. While most bfp floatformat is composed of two fields (exponent bits and coefficient bits). And they also have different representation for non-finite number (infinity and NaN). So I am now thinking of adding a builtin type other than TYPE_CODE_FLT to represent dfp. This type (I am thinking of using TYPE_CODE_DECFLT) will have three fundamental type like TYPE_CODE_FLT for different sizes. In the fields it will have four fields: signedness, combinator, exponent continuation and coefficient continuation. And these fields will merged together into value.aligner.contents. In this way, we can not only support the setting and printing of dfp types (constants or variables), but also can add other feature (such as arithmetic operation) as needed. Is there any clear deficiency in this method? Do you think that it is feasible? and also extensible? I will start to code in this direction if there is not any obvous weakness. Best Regards - Wu Zhou