Re: RFD: selective linking of floating point support for *printf / *scanf

[Freddie Chopin <freddie_chopin@op.pl>]

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.[1]
> Separating this functionality into a subroutine would eliminate that.
>
> [1] 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 
still).

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 (;

Regards,
FCh