Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Jan 2003 14:30:55 +0100
From:      Thomas Moestl <tmoestl@gmx.net>
To:        John Polstra <jdp@polstra.com>
Cc:        sparc@freebsd.org
Subject:   Re: Sparc64 floating point questions
Message-ID:  <20030117133055.GA304@crow.dom2ip.de>
In-Reply-To: <200301170216.h0H2G0PZ040597@vashon.polstra.com>
References:  <XFMail.20030114144825.jdp@polstra.com> <20030115003013.GA3536@crow.dom2ip.de> <200301150047.h0F0lNFc037477@vashon.polstra.com> <20030115021706.GA5902@crow.dom2ip.de> <200301170216.h0H2G0PZ040597@vashon.polstra.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2003/01/16 at 18:16:00 -0800, John Polstra wrote:
> In article <20030115021706.GA5902@crow.dom2ip.de>,
> Thomas Moestl  <tmoestl@gmx.net> wrote:
> > 
> > Oh, I should have mentioned that %fprs is a bit special; the kernel
> > uses the FEF bit to test whether floating point support is enabled for
> > the process, and will only save the state across context switches in
> > that case. It will also lazily restore the context, i.e. it will
> > disable the FEF bit and reload the registers only when the process
> > uses floating point operations for the next time (which triggers an
> > exception in that case).
> > That means that %fprs must be restored first, otherwise this might
> > clear FEF and cause stale values to be reloaded later.
> > In fact, you do not need to save it at all; the only other bits in
> > that register are the DU (upper fp register file half dirty) and DL
> > (lower half dirty) bits, which are automatically maintained.
> > For performance, it would probably be best to always just set the FEF
> > bit before reloading the other registers (this is not required
> > though), like:
> > 
> > 	 wr	%g0, FPRS_FEF, %fprs
> 
> I'm a little bit confused about this.  Won't the instruction above
> clear the DU and DL bits?

Yes.

>  And isn't that a bad thing to do?  It seems like the state
> maintained in those bits is per-process rather  than per-thread.

Since you are going to write to all fp registers anyway, both will get
set automatically. These bits are not used by the hardware and exist
only to allow software to skip saving unused registers. The kernel
does not currently make use of them. However, if it (or a userland
thread manager) did, and a switch was to take place before all
registers were restored, the missing dirty bits would indicate that
the yet unaccessed parts of the registers need not be saved, which
does not matter at all since their old values will not be used any
more.
The kernel itself does never clear DU and DL, so it is possible to use
them in user land to skip unnecessary saving (and unneccesary
reloading if one of the halves was not accessed at all); in this case
it would be necessary to clear the bits explicitely after reloading.
Both will however get set currently each time the fp registers are
restored after a (kernel) context switch, so this does probably not
really pay off. Also, things would break if the kernel started to use
them for saving decisions.

Setting FEF explicitely before reloading makes sure that a fp state
that was saved on a previous context switch and that might not have
been restored yet will not be restored due to the following register
accesses. Since all registers will be overwritten anyway, this would
just eat cycles unnecessarily.

	- Thomas

-- 
Thomas Moestl <tmoestl@gmx.net>	http://www.tu-bs.de/~y0015675/
              <tmm@FreeBSD.org>	http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0  9C0F 1FE6 4F1D 419C 776C

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030117133055.GA304>