Date: Mon, 7 Jan 2002 13:49:13 -0700 From: Nate Williams <nate@yogotech.com> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: Nate Williams <nate@yogotech.com>, Dan Eischen <eischen@vigrid.com>, Peter Wemm <peter@wemm.org>, Archie Cobbs <archie@dellroad.org>, Alfred Perlstein <bright@mu.org>, arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <15418.2505.568006.160724@caddis.yogotech.com> In-Reply-To: <Pine.SUN.3.91.1020107153321.18416A-100000@pcnet1.pcnet.com> References: <15418.518.723982.571226@caddis.yogotech.com> <Pine.SUN.3.91.1020107153321.18416A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Thread 1: > > > --------- > > > /* munch some FP stuff */ > > > pthread_yield(); /* allow thread 2 to run */ > > > /* munch some more FP stuff */ > > > > > > Assume that pthread_yield only saves the FP control word (which > > > is what it does currently in libc_r). > > > > > > Thread 2: > > > --------- > > > /* FP munchy munchy */ > > > pthread_yield(); /* allow thread 1 to run */ > > > /* FP munchy munch munch */ > > > > > > > > > What FP state exists in registers across the call to > > > pthread_yield(). > > > > *NOW* I understand. Thanks for being patient with me. > > > > Here is some code snippets on that note. (It's been a *LONG* time since > > I looked at this, so be nice to me. :) > > > > Basically, we do a 'fsave' on an 108 byte array (which is the amount of > > space required to save a complete processor state of the FPU unit on a > > 387), and then later restore the same state. > > Ok, but are you sure that the FP state isn't being saved > because it also has to handle restoring thread contexts > interrupted by signals? I noticed it was using siglongjmp... Again, it's been a long time since this was done. We may be inefficient in some cases (saving the context twice), but I do know that w/out the fsave/frstr code, threads that did FPU operations ended up with *really* funky answers, and FPU errors were never caught correctly. > If you have a call to a function in the middle of doing > some FP stuff, that function itself could do a slew of > other FP calculations: > > /* FP munch */ > foo_fp_munch_lots_more(); > /* FP munch some more */ > > What guarantees do you have that the FP state is restored > to where it was prior to calling foo_fp_munch_lots_more()? Because the code (and code similar to it) is called by the thread scheduler when a thread switches context. Above, if the thread switches context (involuntarily or voluntarily), the code I posted (and others routines similar to it it) also saves the context, and just before the context is switched back to the above thread, the FPU context is restored (along with all of the other information necessary to restore the thread context). Not all thread switches are done using yield. Nate 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?15418.2505.568006.160724>