This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC floating point usage
- From: Joel Sherrill <joel dot sherrill at OARcorp dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Richard Henderson <rth at redhat dot com>, Mike Stump <mrs at apple dot com>, Geoff Keating <geoffk at geoffk dot org>, "steby at enea dot se" <steby at enea dot se>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 16 Oct 2002 15:43:03 -0500
- Subject: Re: GCC floating point usage
- Organization: OAR Corporation
- References: <360570000.1034800416@warlock.codesourcery.com>
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