From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19145 invoked by alias); 3 Sep 2006 16:44:21 -0000 Received: (qmail 19135 invoked by uid 22791); 3 Sep 2006 16:44:19 -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, 03 Sep 2006 16:44:13 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GJv4s-00020Y-Rh; Sun, 03 Sep 2006 12:44:10 -0400 Date: Sun, 03 Sep 2006 16:44: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: <20060903164410.GA7408@nevyn.them.org> Mail-Followup-To: Wu Zhou , gdb-patches@sourceware.org References: <20060821070736.tr378yu70gk8s8cc@imap.linux.ibm.com> <20060821125031.GA16703@nevyn.them.org> <44E9D816.9070809@cn.ibm.com> <20060821160834.GA22192@nevyn.them.org> <44FA97FA.1070100@cn.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44FA97FA.1070100@cn.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-09/txt/msg00014.txt.bz2 On Sun, Sep 03, 2006 at 04:53:14PM +0800, Wu Zhou wrote: > It is like this. The structures decimal32, decimal64 and decimal128 are > big-endian in current libdecnumber implementation: > > typedef struct > { > uint8_t bytes[DECIMAL128_Bytes]; /* decimal128: 1, 5, 12, 110 bits */ > } decimal128; > > But variables/constants of _Decimal32, _Decimal64 and _Decimal128 (which > are the DFP extension to c language types) in the memory are stored in > little-endian on x86, and big-endian on ppc64. So the byte swapping is > needed on x86. OK, that makes sense: note that this is needed precisely when converting from a target decimal float to a host decimal128. That is a better time to do the conversion. > Ben Elliston is planning to change the memory layout of > decimal32/decimal64/decimal128 to host byte order in later > libdecnumber/gcc. Then the byte swapping will not be needed in gdb. But > that is when GCC gets to stage 1 again, which might be around the end of > this year. > > So one option is for us to keep the byte swapping code in gdb, and when the > byte order in libdecnumber is changed to host byte order, we can easily > delete them. This, however, is not correct. Libdecnumber will presumably change to use host endianness. GDB will fetch numbers in target endianness. If you're using a native i386 debugger, then you won't need to swap; but if you're using an i386 <-> powerpc debugger, then you will. The swap will need to be in the same place, just with a different condition. I would recommend that you always store the bytes in struct value in target endianness. Then, have two functions which convert between a "struct value" and a "decimal128". Then it should be clear which one has which representation. Then, for instance, you can use decimal128 in typed_val_decfloat, and in the argument of value_from_decfloat. And that function can be responsible for the exchange. Similarly, in print_decimal_floating, you have bytes in target endianness; you can convert them to a "struct value", which will have the same bytes, and convert the value to a decimal128 which you can print. The only part of that which is tricky is converting the bytes back to a struct value. You could write a new function, value_from_bytes, to do that; just like value_from_longest. -- Daniel Jacobowitz CodeSourcery