Fri Dec 1 13:10:00 GMT 2000
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
More information about the Newlib