From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20805 invoked by alias); 27 Nov 2002 08:12:05 -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 20788 invoked from network); 27 Nov 2002 08:12:03 -0000 Received: from unknown (HELO executor.cambridge.redhat.com) (195.224.55.237) by sources.redhat.com with SMTP; 27 Nov 2002 08:12:03 -0000 Received: from talisman.cambridge.redhat.com (talisman.cambridge.redhat.com [172.16.18.81]) by executor.cambridge.redhat.com (Postfix) with ESMTP id 390A8ABAF8; Wed, 27 Nov 2002 08:12:03 +0000 (GMT) Received: (from rsandifo@localhost) by talisman.cambridge.redhat.com (8.11.6/8.11.0) id gAR8C0x24381; Wed, 27 Nov 2002 08:12:00 GMT X-Authentication-Warning: talisman.cambridge.redhat.com: rsandifo set sender to rsandifo@redhat.com using -f To: cgd@broadcom.com Cc: gdb-patches@sources.redhat.com Subject: Re: Simulation of MIPS recip and rsqrt instructions References: From: Richard Sandiford Date: Wed, 27 Nov 2002 00:12:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-11/txt/msg00672.txt.bz2 cgd@broadcom.com writes: > In adding those calls to sim_fpu_inv() I did not notice the changes to > sim_fpu_inv() in our source which replace its entire body with: > > #if 0 > ... old body ... > #else > const sim_fpu sim_fpu_one = { > sim_fpu_class_number, 0, IMPLICIT_1, 0 > }; > return sim_fpu_div (f, &sim_fpu_one, r, sim_fpu_round_default); > #endif > > 8-) Ah. ;) Out of interest, how come you're using these local constants? I noticed the same thing in cp1.c. Is it just supposed to lead to better optimisation than the global sim_fpu_one? > > Unfortunately, sim_fpu_inv isn't commented and cp1.c seems to be > > its only active user. Which should change? > > For small values of only. 8-) > > common/cgen-accfp.c seems to use it as well for "invsf" and "invdf". Yeah, but nothing seems to use invsf and invdf. AFAICT, the mips port really is the only active user. > Anybody got a clue as to what the cgen-accfp.c 'invsf' and 'invdf' fns > are supposed to do? Not me. I looked at the cgen docs, but it didn't mention it explicitly. But like you & Andrew say, it's probably better to patch sim_fpu_inv(). Please install my second patch if it's OK. I realise I missed the change log first time, so here it is again. Richard * sim-fpu.c (sim_fpu_inv): Use sim_fpu_div. Index: sim/common/sim-fpu.c =================================================================== RCS file: /cvs/src/src/sim/common/sim-fpu.c,v retrieving revision 1.4 diff -c -d -p -F^[(a-zA-Z0-9_^#] -r1.4 sim-fpu.c *** sim/common/sim-fpu.c 12 Jun 2002 00:46:11 -0000 1.4 --- sim/common/sim-fpu.c 26 Nov 2002 20:33:46 -0000 *************** INLINE_SIM_FPU (int) *** 1754,1786 **** sim_fpu_inv (sim_fpu *f, const sim_fpu *r) { ! if (sim_fpu_is_snan (r)) ! { ! *f = *r; ! f->class = sim_fpu_class_qnan; ! return sim_fpu_status_invalid_snan; ! } ! if (sim_fpu_is_qnan (r)) ! { ! *f = *r; ! f->class = sim_fpu_class_qnan; ! return 0; ! } ! if (sim_fpu_is_infinity (r)) ! { ! *f = sim_fpu_zero; ! f->sign = r->sign; ! return 0; ! } ! if (sim_fpu_is_zero (r)) ! { ! f->class = sim_fpu_class_infinity; ! f->sign = r->sign; ! return sim_fpu_status_invalid_div0; ! } ! *f = *r; ! f->normal_exp = - r->normal_exp; ! return 0; } --- 1754,1760 ---- sim_fpu_inv (sim_fpu *f, const sim_fpu *r) { ! return sim_fpu_div (f, &sim_fpu_one, r); }