This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]