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

[Matt Thomas <matt%3am-software.com@localhost>]

At 06:56 PM 2/22/2003, M L Riechers Mlr wrote:
> 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).

Floating point register are never saved or restored on a context switch.
Each processor knows which was the last lwp that used FP (which "owns"
the FP unit).  If another lwp request uses of FP unit, when the FP lazy
switch code will save the current FP state into owner's state area,
revoke the owner, set the owner to the new lwp, and then enable FP in
the saved-MSR of the lwp.  Now FP instructions won't trap in the new
owner but will trap in the old lwp.

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

Not true.

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

Not true.

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

Not true

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

This I agree with.

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

BTW, do you have a small C snipet that shows this happening?


--
Matt Thomas               Internet:   matt%3am-software.com@localhost
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message