From owner-freebsd-arch  Wed Jan  9  0: 0:39 2002
Delivered-To: freebsd-arch@freebsd.org
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP id 515E437B425
	for <arch@FreeBSD.ORG>; Wed,  9 Jan 2002 00:00:21 -0800 (PST)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA14368;
	Wed, 9 Jan 2002 19:00:14 +1100
Date: Wed, 9 Jan 2002 19:00:59 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender:  <bde@gamplex.bde.org>
To: Dan Eischen <eischen@vigrid.com>
Cc: <arch@FreeBSD.ORG>
Subject: Re: Getcontext resolution?
In-Reply-To: <3C3ADC3B.F75D2669@vigrid.com>
Message-ID: <20020109184836.A7595-100000@gamplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG

On Tue, 8 Jan 2002, Dan Eischen wrote:

> Bruce Evans wrote:
> >
> > On Mon, 7 Jan 2002, Dan Eischen wrote:
> > > #if 0
> > >       fnstcw  MC_FP_CW_OFFSET(%edx)               /* save control word */
> > >       movl    $UC_MC_VALID, MC_FLAGS_OFFSET(%edx) /* mcontext valid, no FP */
> > > #else
> > >       fnsave  MC_FP_REGS_OFFSET(%edx)             /* save FP regs */
> > >       movl    $MC_FP_VALID, MC_FLAGS_OFFSET(%edx) /* mcontext and FP valid */
> > > #endif
> >
> > Even the fnstcw will cause a trap the the kernel on i386's if the state
> > isn't already in the FPU, so little or negative might be gained relative
> > to a syscall that can sometimes just copy the state.
>
> But it will only occur the first time and not on subsequent context
> switches, right?  Unless the process gets swapped out and then resumed
> again by the kernel.  In that case, you are saying that the kernel
> doesn't restore the FPU state when the process gets resumed?

Every time per kernel context switch (including ones to ithreads in
-current).  On every kernel context switch, the kernel saves the FPU
state in the pcb (if it is in the FPU) and sets CR0_TS in cr0 (if it
isn't already set) so that the next FPU instruction in the process
traps to the kernel for restoring the FPU state from the pcb.  The
kernel never restores the FPU state at context switch time since it
has no idea if the state will be used again and guesses that it will
not be.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message