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

[Wu Zhou <woodzltc at cn dot ibm dot 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