Re: [RFC] decimal float point patch based on libdecnumber: gdb patch

[Daniel Jacobowitz <drow at false dot org>]

On Sun, Jul 23, 2006 at 01:47:58AM -0400, Wu Zhou wrote:
> My point is to keep these usage so as they are consistent with how  
> flaot/double is handled.  What is your idea on this?

I think it would be more useful to search for all reference to decimal
float, than it would be to exactly parallel the float/double support.

> >Why is reverse_dfp necessary?  It says GDB uses the opposite endianness
> >from decNumber, but I don't see why.  This might be a related problem,
> >but are you accomodating target endianness when you read values from
> >the target?  If not, a cross debugger will do the wrong thing.
> 
> We are using an array of gdb_byte to represent decimal values.  The  
> first byte is the most significant. This might be not the same as the  
> underlying byte order of the architecuture.  In this kind of  
> situation, reverse_dfp is needed to do conversion.
> 
> But in big-endian machine, this might be not needed. I will try a test  
> on ppc64.

This is where you're getting in trouble; it's too hard to keep track of
which format is which.  You need to make it clear when a decimal
floating point number is in "target format" and when it is in "host
format".

It might be easier to understand if you used two separate routines,
even if they both do the same thing.  That is, have a
decfloat_to_target and a decfloat_to_host.  They can consider the
endianness of the host and the endianness of the target.

I don't understand "the first byte is the most significant".  Does
decNumber always use that layout whether the host system is little
endian or big endian?  Then why does the target sometimes have it in
the other order?

> BTW, I am not very sure what you means by saying "are you accomodating  
> target endianness when you read values from the target?". I guess you  
> mean that I _need_ to accommodate the endianness when reading values  
> from the target, right? Then putting some code into  
> decimal_from_string / decimal_to_string to convert the byte order if  
> needed is right what you want to see, right?  Any advices?

I don't know where you should put it.  Probably, whenever you store it
as an opaque representation (array of bytes), store it in the target's
byte order.  When you store it in a local _Decimal128 store it in the
host byte order.

It's important to take advantage of type safety here if you can.  When
it's stored as a series of bytes it should always be in the same order,
not sometimes in target order and sometimes in host order.  Everyone
will just get confused.

-- 
Daniel Jacobowitz
CodeSourcery