From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20792 invoked by alias); 1 May 2004 14:28:00 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20588 invoked from network); 1 May 2004 14:27:59 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 1 May 2004 14:27:59 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i41ERwKI030046; Sat, 1 May 2004 10:27:59 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i41ERvv16935; Sat, 1 May 2004 10:27:57 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7D7282B9D; Sat, 1 May 2004 10:27:52 -0400 (EDT) Message-ID: <4093B3E8.5080108@gnu.org> Date: Sat, 01 May 2004 14:28:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: DJ Delorie Cc: binutils@sources.redhat.com, gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Add host's floatformat References: <40939DD4.3000706@gnu.org> <200405011325.i41DP0i7031346@greed.delorie.com> In-Reply-To: <200405011325.i41DP0i7031346@greed.delorie.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-05/txt/msg00022.txt.bz2 >>This patch adds the host's floatformat (when known) to floatformat.[hc]. > > > Since we *are* the host, don't we *always* know what the host't float > format is? I mean, we can just cast to float. But still, we should > be able to auto-detect which floatformat is used at runtime, rather > than guess in configure (and miss lots of host processors). > > We should be able to have a pre-compiled table of float constants and > their hex representations, and just scan the table for bit equality to > see which entries match. > > It might be a bit more complex to code the first time around, but it > will be a lot less hackish in the long run (and maintenance-free :) The patch, which is effectively lifed from GDB's code base has been working well. However, I'll change those variables to functions so that the possability you describe can be easily implemented. Andrew