RFD: selective linking of floating point support for *printf / *scanf
Wed Sep 3 20:29:00 GMT 2014
W dniu 2014-09-03 22:19, Joel Sherrill pisze:
> I considered this approach in the past specifically for floating point
> formats. At one point in history and on some architectures, declaring
> a floating point variable on the stack of the printf() that did work would
> result in using the FPU even in a task that otherwise didn't use the FPU.
> Separating this functionality into a subroutine would eliminate that.
>  With RTEMS and some other RTOSes, a task/thread can be specified
> as integer only and, if possible, we disable the FPU when that thread is
> executing. This can significantly improve context switch time but runs
> the risk of an integer only task inadvertently using the FPU. Long ago,
> on the HPPA, GCC would use FPU multiply for array index calculations
> because FP multiply was faster. That was a surprise. We have seen
> implicit use of FPU registers on at least SPARC and PowerPC since
> then at various times.
> DISCLAIMER: That was 20+ years of gcc and newlib history above.
> Issues come and go but an approach to save memory and avoid the
> issue is a good thing IMO. :)
I think such approach would be better than the one currently in newlib
(printf() and iprintf()), because of the reasons you mentioned and
because it wouldn't result in code duplication if you actually need
both. It would be also easier to maintain - only one function instead of
two (I know that now the functions are generated with preprocessor, but
Users could modify such modular printf anyway they like - overriding any
__printf_handle_...() they like to keep the code size lower (;
If someone ever comes with a way to modify gcc to detect need for
floating point it would work too (gcc/ld would select right library
automatically), but for now I guess it's the simplest solution that has
all the benefits and is easy to do... Plus the modularity would make
this monstrous implementation of printf() much more readable (;
More information about the Newlib