> > In the case of NetBSD, the ```printf()''' function contains floating
> > point code which (for one architecture at least) results in the
> > compiler generating instructions to save floating point registers on
> > function entry (and thus gain the FP state) even if the fp code
> > proper is actually never reached.

> I'm tempted to say "over my dead body".  vfprintf() is a complicated
> piece of code, and I'd hate to see it become even more complicated
> without hard numbers on what difference it makes (run on a variety
> of processors, of course).

I believe the idea was to change the *kernel* to do lazy FP
saving.  How will that change vfprintf? [Gordon Ross
suggested doing FP formatting stuff in a separate routine
which will affect vfprintf.  But moving everything for the
[%eEfFgG] format in a separate routine is pretty
straightforward even if it seems somewhat unpalatable --
just wrap up the relavant case body (lines 395..460 in
vprintf.c version 1.17) in a routine with lots of args.
Even without this change lazy FP state saving is a good idea
IMHO.]