From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27743 invoked by alias); 21 Aug 2006 15:58:37 -0000 Received: (qmail 27733 invoked by uid 22791); 21 Aug 2006 15:58:36 -0000 X-Spam-Check-By: sourceware.org Received: from ausmtp06.au.ibm.com (HELO ausmtp06.au.ibm.com) (202.81.18.155) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 21 Aug 2006 15:58:33 +0000 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp06.au.ibm.com (8.13.6/8.13.6) with ESMTP id k7LFxu808511516 for ; Tue, 22 Aug 2006 01:59:56 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.250.242]) by sd0208e0.au.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k7LG1krd211656 for ; Tue, 22 Aug 2006 02:01:51 +1000 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k7LFwMah003018 for ; Tue, 22 Aug 2006 01:58:22 +1000 Received: from [9.125.0.240] ([9.125.0.240]) by d23av01.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7LFwKh4003004; Tue, 22 Aug 2006 01:58:21 +1000 Message-ID: <44E9D816.9070809@cn.ibm.com> Date: Mon, 21 Aug 2006 18:34:00 -0000 From: Wu Zhou User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Wu Zhou , gdb-patches@sourceware.org Subject: Re: [RFC] decimal float point patch based on libdecnumber: gdb patch References: <20060821070736.tr378yu70gk8s8cc@imap.linux.ibm.com> <20060821125031.GA16703@nevyn.them.org> In-Reply-To: <20060821125031.GA16703@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00147.txt.bz2 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