Date: Tue, 14 Jan 2003 16:47:23 -0800 (PST) From: John Polstra <jdp@polstra.com> To: sparc@freebsd.org Cc: tmoestl@gmx.net Subject: Re: Sparc64 floating point questions Message-ID: <200301150047.h0F0lNFc037477@vashon.polstra.com> In-Reply-To: <20030115003013.GA3536@crow.dom2ip.de> References: <XFMail.20030114144825.jdp@polstra.com> <20030115003013.GA3536@crow.dom2ip.de>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <20030115003013.GA3536@crow.dom2ip.de>, Thomas Moestl <tmoestl@gmx.net> wrote: > On Tue, 2003/01/14 at 14:48:25 -0800, John Polstra wrote: > > I think that the CVSup failure one person reported was caused by the > > fact that I'm not currently saving/restoring the floating point state > > on thread context switches. > > Hmmm, how do you switch contexts? If it's voluntary in some form > (i.e. using a function call like longjmp()), you do not need to save, > as the floating-point registers are not preserved across function > calls (so the compiler should save and reload them across calls as > needed, unless that's different for m3). It's not always voluntary. Timer signals are used for pre-emption. Though as a temporary work-around, cvsup can be made non-pre-emptive by adding the magic argument "@M3nopreemption" to the command line. It works OK like that, since it is so I/O intensive. > When switching by signals in some form, sendsig() should save > the registers in the signal context, so this should be safe when > restoring the context by returning from the signal handler. > However, this saving is not currently done, which is a bug. OK, I think that must be the problem. By the way, I know that at some point in the past the FP state was not saved on the i386 when signal handlers were invoked. It was definitely necessary to save the FP state when switching threads in the i386 port of Modula-3. I seem to recall that somebody may have changed the kernel to preserve the FP state since that time. > The attached patch should fix this (it also implements getcontext() > and setcontext(), setcontext() will not work for ucontexts from > signals and some optimizing remains to be done though). Thanks for the patch. I am not in a good position to test it, because I don't have a Sparc box myself. I've just been using panther.freebsd.org. I think at least for now I'll just explicitly save all of the FP registers when I switch threads. That way this thing should stand a chance of working with 5.0-RELEASE. > > I need to find out how to do that. It > > looks like if I save and restore the FSR and the FPRS and %q0 through > > %q60, that will do it. Am I missing anything? > > Yes, that should do it. Good, and thanks. > Yes, unless you want to use UltraSPARC specific instructions. Then, > you could do: > > wr %g0, ASI_BLK_P, %asi > stda %f0, [...] %asi > stda %f16, [...] %asi > stda %f32, [...] %asi > stda %f48, [...] %asi > > This stores 16 floating-point registers at a time, i.e. 64 bytes, > which is a complete 2nd-level-cache line, so it should be faster. I don't know much about Sparc machines. But it sounds like there exist 64-bit Sparcs which are not UltraSPARCs. So I'd better do it the most general way. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa 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?200301150047.h0F0lNFc037477>