Subject: Re: I want to rid ugly float load/stores used only for data movement
To: None <firstname.lastname@example.org, email@example.com,>
From: M L Riechers Mlr <firstname.lastname@example.org>
Date: 02/22/2003 21:56:09
On Sat, 22 Feb 2003 16:42:39 -0800 Jason R Thorpe
<email@example.com> wisdom imparted:
> On Sat, Feb 22, 2003 at 06:09:13PM -0500, David Edelsohn wrote:
> > MLR> Would anyone point me in the correct direction?
> > Your intent cannot be implemented safely in GCC. If GCC knows it
> > has FPRs and FPRs hold 64-bit values (which they must), it will use them
> > for 64-bit moves. Cannot be avoided safely.
> That's kind of a bummer. I seem to recall the idea of "no-implicit-fp"
> coming up on the GCC mailing list recently, too. The reason people want
> is to eliminate unpredictable context switch times and/or speed up context
> -- Jason R. Thorpe <firstname.lastname@example.org>
Let me see if I'm getting the drift of this (I'm assuming for the
purpose of this exercise that the processor in question has a hardware
floating point unit, and WRT NetBSD powerpc and the NetBSD kernel
1. If a process never touches a floating point instruction, then the
kernel never "issues" a floating point save area, and in effect
the process has no claim on float registers to save/restore on a
context switch (or giving the float reg set up when some other
process needs it).
2. As soon as a process uses a float instruction for any reason (say
a gratuitous lfd/stfd instuction sequence solely for a data move),
then the process is saddled with a claim on float registers to
save/restore on a context switches -- although the same mechanism
used to trap the float use event in the first place might bar the
necessity to save/restore the registers, unless a float register
is used again in a context switch return.
3. If most processes unmeaningly hit a gratuitous float event on most
context switches, then the kernel will be forced to spend a
significant amount of time saving/restoring float register sets.
4. A process that did not use float at all might nevertheless be
affected by some (increased) unpredictability in its context
switch-in or switch-out, or in some other way. (Hmmm, I really
haven't thought that one through, but it occurs to me as a
5. And, (not specifically following from your comments, but I'd like
to point out anyway), the trap to the kernel on first float
instruction use is itself a non-trivial event, which arguably
should happen only if the process is sincere in its intent to use
floating point arithmetic. Presumably, this alone would
disqualify the use of float resources for trivial memory to memory
Is this along the line of your notions, Jason? Further thoughts?