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] |
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] |