From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17485 invoked by alias); 16 Oct 2002 20:43:05 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 17478 invoked from network); 16 Oct 2002 20:43:04 -0000 Received: from unknown (HELO mail.oarcorp.com) (216.107.91.226) by sources.redhat.com with SMTP; 16 Oct 2002 20:43:04 -0000 Received: (qmail 15532 invoked from network); 16 Oct 2002 20:43:03 -0000 Received: from unknown (HELO OARcorp.com) (136.205.65.100) by 0 with SMTP; 16 Oct 2002 20:43:03 -0000 Message-ID: <3DADCF57.10BFB2B8@OARcorp.com> Date: Wed, 16 Oct 2002 14:56:00 -0000 From: Joel Sherrill Organization: OAR Corporation X-Accept-Language: en MIME-Version: 1.0 To: Mark Mitchell CC: Richard Henderson , Mike Stump , Geoff Keating , "steby@enea.se" , "gcc@gcc.gnu.org" Subject: Re: GCC floating point usage References: <360570000.1034800416@warlock.codesourcery.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg01002.txt.bz2 Mark Mitchell wrote: > > > I think that the proper solution to this to have a mode in which > > the compiler does not *prefer* to use FP registers for integral > > data. But the assembler would set a bit if any FP registers are > > used, which would then be collected by the linker to indicate > > whether or not the process as a whole uses FP registers. > > This is a dynamic property; not a static one. Linking in printf is > fine, if you never call it with "%g", and you know that it doesn't > use floating-point registers otherwise. You don't want two printfs; > memory is tight, and you want to be able to share your one printf > between tasks. As an aside which will have to be rechecked when this all settles, at one point, the code generated for the newlib printf actually touched the FPU even if you did not use a FP format specifier. I believe this was triggered by having local float/double variables even though they were not used. I recall that the code was modified to add local scope blocks and declare them closer to the point of use. > You just don't want the compiler to generate FP register moves for > integer programs. Right. Also at least the HPPA port used to do integer multiplies in the FPU so move may not be the only case. > > Anything less is asking for trouble. > > Yes, programmers have to be very careful not to accidentally let FP > slip into no-FP tasks. But, hey, we're in C on embedded systems; we > have to be careful about lots of things. This is just one more... Yes. And given a tiny bit of hardware help, the run-time can enforce that no-FP tasks do not utilize the FPU. > -- > Mark Mitchell mark@codesourcery.com > CodeSourcery, LLC http://www.codesourcery.com -- Joel Sherrill, Ph.D. Director of Research & Development joel@OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985