Re: [RFC] Decimal Floating Point support for GDB (Part 1: patch)

[Wu Zhou <woodzltc@cn.ibm.com>]

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