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

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

Daniel Jacobowitz wrote:
> On Mon, Aug 21, 2006 at 07:07:36AM -0400, Wu Zhou wrote:
>> decimal128 is defined like this in libdecnumber:
>>
>> typedef struct
>> {
>>   uint8_t bytes[DECIMAL128_Bytes];      /* decimal128: 1, 5, 12, 110 bits */
>> } decimal128;
>>
>> It is always big-endian.
>>
>> When parsing dfp constant in our patch, we are also using a byte array  
>> to store its value. It is big-endian too:
>>
>>   struct {
>>        gdb_byte val[16];
>>        struct type *type;
>>   } typed_val_decfloat;
>>
>> But when transfering them into gdb's value system  
>> (value_from_decfloat), we need to do endianess transfer in little  
>> endian machine. This is why exchange_dfp is needed.
> 
> Why?  Why can't that use exactly the same big endian representation?
> It's big endian on the target, it's big endian in the library, so what
> are you doing that needs it to be little endian?

But as far as I know, the endianess of struct "value" in the target memory is architecture depedent. 
  To name a example, in value_from_decfloat, we need to set the raw content of val to the dfp 
constant user inputed, I am using this:
   memcpy (value_contents_raw (val), decbytes, len);

decbytes is big-endian on all both x86 and ppc64 platforms.  But the value_contents_raw (val) is 
little endian on x86 / x86_64 system, and big endian on ppc64.  So exchange_dfp is needed.

> Sorry to keep asking this; I really want to understand this one issue
> before I review the code.

no problem at all. I guess I didn't make myself understood.  Or that I have some misunderstanding 
about the problem (correct me if you find any). Maybe a direct talk might be good.  Wish to see you 
on gcc IRC (I see that you are gray when I post this).

Regards
- Wu Zhou