Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Jun Sun" <jsun@mvista.com>, "Daniel Jacobowitz" <dan@debian.org>
Cc: "MIPS/Linux List \(SGI\)" <linux-mips@oss.sgi.com>
Subject: Re: FP emulator patch
Date: Thu, 16 Aug 2001 22:40:26 +0200	[thread overview]
Message-ID: <01b001c12693$b4920140$0deca8c0@Ulysses> (raw)
In-Reply-To: 3B7C1BB9.7011790E@mvista.com

> > current->used_math should never be set to zero in this sort of
> > situation.  It's not an ownership flag!  It marks whether the FP state
> > in the thread structure is valid.
>
> Daniel, it is funny that I agree with your last statement but cannot agree
> with your first one.
>
> Under the above mentioned situation, after we make the copy of FPU state
from
> thread structure to the saved signal context, we need to set used_math bit
to
> zero.  This way when the signal handler uses FPU for the first time - if
it
> ever uses it -, the normal lazy FPU switch mechanism can kick in smoothly.

We've had a lot of messages crossing here, but please
explain yourself here why clearing used_math helps in
this case.  If, as has been proposed, the current
thread does not own the FPU, and thus CU1 is not
enabled, the FPU switch mechanism should kick in
during the signal handler regardless. The signal
handler will inherit the thread's FPU state from
the thread context, and will muck with it, but
if, as has been noted, the sigcontext has
been loaded from the thread context before
the handler is dispatched, and is restored after
the handler executes, we're fine.  The only thing
I can see that clearing used_math would achieve
would be to guarantee the signal handler a virgin
FPU context.

            Regards,

            Kevin K.

WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: Jun Sun <jsun@mvista.com>, Daniel Jacobowitz <dan@debian.org>
Cc: "MIPS/Linux List (SGI)" <linux-mips@oss.sgi.com>
Subject: Re: FP emulator patch
Date: Thu, 16 Aug 2001 22:40:26 +0200	[thread overview]
Message-ID: <01b001c12693$b4920140$0deca8c0@Ulysses> (raw)
Message-ID: <20010816204026.XQT9NBMwwtA3WVaxktQNQPRLQSZPE0MONKuUkJbTMlo@z> (raw)
In-Reply-To: 3B7C1BB9.7011790E@mvista.com

> > current->used_math should never be set to zero in this sort of
> > situation.  It's not an ownership flag!  It marks whether the FP state
> > in the thread structure is valid.
>
> Daniel, it is funny that I agree with your last statement but cannot agree
> with your first one.
>
> Under the above mentioned situation, after we make the copy of FPU state
from
> thread structure to the saved signal context, we need to set used_math bit
to
> zero.  This way when the signal handler uses FPU for the first time - if
it
> ever uses it -, the normal lazy FPU switch mechanism can kick in smoothly.

We've had a lot of messages crossing here, but please
explain yourself here why clearing used_math helps in
this case.  If, as has been proposed, the current
thread does not own the FPU, and thus CU1 is not
enabled, the FPU switch mechanism should kick in
during the signal handler regardless. The signal
handler will inherit the thread's FPU state from
the thread context, and will muck with it, but
if, as has been noted, the sigcontext has
been loaded from the thread context before
the handler is dispatched, and is restored after
the handler executes, we're fine.  The only thing
I can see that clearing used_math would achieve
would be to guarantee the signal handler a virgin
FPU context.

            Regards,

            Kevin K.

  reply	other threads:[~2001-08-16 20:36 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-16 18:23 FP emulator patch Kevin D. Kissell
2001-08-16 18:23 ` Kevin D. Kissell
2001-08-16 18:49 ` Pete Popov
2001-08-16 18:53 ` Daniel Jacobowitz
2001-08-16 19:15   ` Jun Sun
2001-08-16 20:40     ` Kevin D. Kissell [this message]
2001-08-16 20:40       ` Kevin D. Kissell
2001-08-16 21:34       ` Jun Sun
2001-08-16 22:33         ` Kevin D. Kissell
2001-08-16 22:33           ` Kevin D. Kissell
2001-08-16 22:38           ` Pete Popov
2001-08-16 22:37         ` Daniel Jacobowitz
2001-08-16 23:12           ` Jun Sun
2001-08-16 23:38           ` Kevin D. Kissell
2001-08-16 23:38             ` Kevin D. Kissell
2001-08-16 19:20 ` Kevin D. Kissell
2001-08-16 19:20   ` Kevin D. Kissell
2001-08-16 20:20   ` Jun Sun
  -- strict thread matches above, loose matches on Subject: below --
2002-09-10 11:55 Carsten Langgaard
2001-08-16 22:58 Kevin D. Kissell
2001-08-16 22:58 ` Kevin D. Kissell
2001-08-16 23:14 ` Jun Sun
2001-08-16 23:46   ` Kevin D. Kissell
2001-08-16 23:46     ` Kevin D. Kissell
2001-08-15 12:53 Carsten Langgaard
2001-08-15 18:06 ` Daniel Jacobowitz
2001-08-16  0:05   ` Kevin D. Kissell
2001-08-16  0:05     ` Kevin D. Kissell
2001-08-16  4:20   ` Atsushi Nemoto
2001-08-16 12:35     ` Kevin D. Kissell
2001-08-16 12:35       ` Kevin D. Kissell
2001-08-16  7:07   ` Carsten Langgaard
2001-08-16  4:35 ` Atsushi Nemoto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='01b001c12693$b4920140$0deca8c0@Ulysses' \
    --to=kevink@mips.com \
    --cc=dan@debian.org \
    --cc=jsun@mvista.com \
    --cc=linux-mips@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox