From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 384 invoked by alias); 8 Jul 2005 18:44:28 -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 360 invoked by uid 22791); 8 Jul 2005 18:44:24 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 08 Jul 2005 18:44:24 +0000 Received: from drow by nevyn.them.org with local (Exim 4.51) id 1Dqxpm-0006oB-4l; Fri, 08 Jul 2005 14:44:22 -0400 Date: Fri, 08 Jul 2005 18:44:00 -0000 From: Daniel Jacobowitz To: Ian Lance Taylor Cc: gdb-patches@sourceware.org Subject: Re: PATCH RFA: Fix simulator handling of floating point absolute value Message-ID: <20050708184420.GA26128@nevyn.them.org> Mail-Followup-To: Ian Lance Taylor , gdb-patches@sourceware.org References: <20050708140058.GA17316@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-07/txt/msg00085.txt.bz2 On Fri, Jul 08, 2005 at 10:51:11AM -0700, Ian Lance Taylor wrote: > > I have no references for this concern, but could you check that this > > change is appropriate for at least MN10300 and SH64, since they share > > ths code? > > I think I'll need a little help to fully satisfy this request. The > issue is how the fabs instruction on the MN10300 and SH handle NaNs. > This is something that can only be determined via a detailed processor > manual or by testing on real hardware. > > The manual for the SH4a is, fortunately, clear: the fabs instruction > is described as "FRn & H'7FFF FFFF -> FRn." So for the SH4a, at > least, my proposed patch is correct. > > I found a processor manual for the MN10300 AM33 on the web, but all it > says about the fabs instruction is "This takes an absolute value of > the register (FSm), and stores the result in the register (FSn)." > > A hardware designer implementing the floating point absolute > instruction has a choice. He or she can implement a simple > instruction which clears the sign bit. Or he or she can implement an > instruction which checks for NaN input, and, in that case, does not > clear the sign bit. Since sim-fpu.c is intended to be for generic > use, I think it is reasonable to bet on the simple implementation, and > force a simulator for a processor which takes the complex > implementation to do something different. Especially since it is > correct for at least two out of three processors. That's good enough for me; thank you, Ian. Patch is OK. -- Daniel Jacobowitz CodeSourcery, LLC