Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Jan 2002 17:55:46 -0500 (EST)
From:      Daniel Eischen <eischen@pcnet1.pcnet.com>
To:        Nate Williams <nate@yogotech.com>
Cc:        Terry Lambert <tlambert2@mindspring.com>, Dan Eischen <eischen@vigrid.com>, k Macy <kip_macy@yahoo.com>, Peter Wemm <peter@wemm.org>, Julian Elischer <julian@vicor-nb.com>, arch@FreeBSD.ORG
Subject:   Re: KSE question
Message-ID:  <Pine.SUN.3.91.1020125174754.4674A-100000@pcnet1.pcnet.com>
In-Reply-To: <15441.56832.170618.611705@caddis.yogotech.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 25 Jan 2002, Nate Williams wrote:
> > > The FPU usage is problematic, but is also resolvable, as a
> > > tools issue.
> > > 
> > > Specifically, if an ELF section were generated whenever
> > > the compiler generated FPU code (let's call this section
> > > "flags", for the sake of argument), then the flag "FPU=1"
> > > could be set there.
> > 
> > [ ... ]
> > 
> > Interesting.  I think we only care about FPU state
> > during signal deliver and preemptions though, and in
> > that case, the kernel can just pass us the "FPU used"
> > flag and/or "FPU format" along with the interrupted
> > context.
> 
> There's lots of talk about using this 'FPU used' flag, but at least my
> read of things from the long discussion before was that it may not be
> possible to implement this on the x86 architectures we currently
> support.
> 
> It sounds like a great idea, *IF* if can be done.

The kernel knows if the FPU has been used and it also knows
the format (x87 vs SSE/XMM).  As long as the FPU context
comes from the kernel, then it can also tell us whether
it is valid and it's format.

I'm reworking [gs]etcontext; let's hold off on this for
a bit and I'll post the changes.

-- 
Dan Eischen

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1020125174754.4674A-100000>