Subject: printf() using floating point ...
To: None <email@example.com>
From: Gordon W. Ross <firstname.lastname@example.org>
Date: 06/14/1995 10:29:41
> Date: Wed, 14 Jun 1995 19:00:49 +1000 (EST)
> From: Andrew Cagney <email@example.com>
> Sender: firstname.lastname@example.org
> Precedence: list
> X-Loop: tech-kern@NetBSD.ORG
> On RISC processors, there is significant overhead in saving floating
> point registers during a context switch. To avoid this a kernel will
> often start a process with the FPU disabled and then wait for a
> FPU-disabled exception before enabling it. 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.
> Has any one looked into this? (If it makes sense :-)
This will affect the Sun3 also, when we add the logic to do the
"lazy FPU switch" thing. The m68k compiler saves and restores
some floating point registers in the prologue and epilog of any
function that contains any float (or double) automatic variables.
Perhaps we could reorganize printf (doprint?) to force it to call
a separate function for any of the "%f%g" family, just so there
are no float or double variables in the more common code path.