Re: I want to rid ugly float load/stores used only for data movement

[M L Riechers Mlr <mlr%sun.rse.com@localhost>]

On Sat, 22 Feb 2003 16:42:39 -0800 Jason R Thorpe
<thorpej%wasabisystems.com@localhost> 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
> switching.
> 
> -- 
>         -- Jason R. Thorpe <thorpej%wasabisystems.com@localhost>

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
specifically):

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
    possibility.

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
    data movements.

Is this along the line of your notions, Jason?  Further thoughts?

-Mike