This is the mail archive of the
mailing list for the newlib project.
Re: RFD: selective linking of floating point support for *printf / *scanf
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Freddie Chopin <freddie_chopin at op dot pl>, "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Wed, 3 Sep 2014 15:19:39 -0500
- Subject: Re: RFD: selective linking of floating point support for *printf / *scanf
- Authentication-results: sourceware.org; auth=none
- References: <CAMqJFCpWKXVmmc-YLKf9XO6H8C_YnTEcgzkJAidE21MirJbi-w at mail dot gmail dot com> <54077549 dot 6080509 at op dot pl>
On 9/3/2014 3:08 PM, Freddie Chopin wrote:
> Sorry if I missed something, but I have an idea that wasn't (probably)
> How about implementing printf()/scanf() to call external functions to do
> processing of a token? For example when printf() encounters %f it calls
> __printf_handle_f(). This calls would be implemented in a way that this
> function can actually do nothing (just consume some input in case of
> scanf() or load variable from va_list and print nothing in case of
> printf(), but do nothing else), so you could have 2 versions of these
> functions - one normal, which does what it's supposed to do (so uses
> floating point calculations), and another one, which would be a stub
> just consuming input or printing nothing (this is pretty simple and no
> floating point math). The version could be selected with a switch for
> linker, manually selecting the library or some other way.
> In the first stage it would be quite OK to have only "normal" versions
> and we could just redefine symbols in user code to point to empty stubs (;
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. :)
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985