Re: vfprintf.c patch

[Joel Sherrill <joel dot sherrill at OARcorp dot com>]

Doug Evans wrote:
> 
> Joel Sherrill writes:
>  > The ideal solution would be to break out the FP printing
>  > into a separate function but that was more risky to implement.
> 
> I responded:
>  > Already done, but the other way around.
>  > IIRC, see iprintf vs printf.
> 
> Joel responded:
>  > iprintf() is non-standard.
> 
> So what did you mean when you said "separate function"?

If vfprintf() did not actually declare any float/doubles
and when it detected the need to print one (%f, %g, etc)
it could call a subroutine with appropriate information
and a (void *) pointer to the argument.  This avoids
all use of float and double in the main body.

>  > Difference in view.
> 
> Careful.  It's tricky business infering what anyone's viewpoint based on the
> few words they put in email (which in a reply are in turn based on
> the few words you put in email).

Agreed.  I just meant that providing iprintf() was the solution with
a different technical viewpoint.  And that I did not know if it
was worth arguing about. :)
 
>  > I just believe in the rule of least
>  > surprise.  Printing an integer, string, or character should
>  > not require FPU operations.
> 
> No disagreement here.

Unfortunately, I think gcc breaks this rule on some ports.  I recall
the HPPA using the FPU for integer multiplies.  And I recall someone
reporting on the RTEMS list that the PowerPC would do moves of
8-byte structures with FP load/stores. 

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985