From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14386 invoked by alias); 23 Jul 2006 14:02:06 -0000 Received: (qmail 14376 invoked by uid 22791); 23 Jul 2006 14:02:05 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sun, 23 Jul 2006 14:02:02 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G4eWt-0001Yk-Ip; Sun, 23 Jul 2006 10:01:59 -0400 Date: Sun, 23 Jul 2006 14:02:00 -0000 From: Daniel Jacobowitz To: Wu Zhou Cc: gdb-patches@sourceware.org Subject: Re: [RFC] decimal float point patch based on libdecnumber: gdb patch Message-ID: <20060723140158.GA5828@nevyn.them.org> Mail-Followup-To: Wu Zhou , gdb-patches@sourceware.org References: <20060723014758.9rm87choaoc8cw08@imap.linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060723014758.9rm87choaoc8cw08@imap.linux.ibm.com> User-Agent: Mutt/1.5.11+cvs20060403 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-07/txt/msg00318.txt.bz2 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