Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 15 Nov 2002 13:05:40 -0800
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        Doug Rabson <dfr@nlsystems.com>
Cc:        ia64@FreeBSD.ORG
Subject:   Re: setjmp/longjmp and libc_r [was: Re: cvs commit: src/lib/libc/ia64/gen _setjmp.S]
Message-ID:  <20021115130540.A34636@kayak.xcllnt.net>
In-Reply-To: <200211151955.19145.dfr@nlsystems.com>
References:  <200211140640.gAE6eNq9016231@repoman.freebsd.org> <200211150909.32267.dfr@nlsystems.com> <20021115174328.GA4288@dhcp01.pn.xcllnt.net> <200211151955.19145.dfr@nlsystems.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 15, 2002 at 07:55:19PM +0000, Doug Rabson wrote:
> On Friday 15 November 2002 5:43 pm, Marcel Moolenaar wrote:
> > On Fri, Nov 15, 2002 at 09:09:32AM +0000, Doug Rabson wrote:
> > > > > I've managed to reload my memory from magtape :-). To use
> > > > > setjmp/longjmp for thread switching, you would need to call
> > > > > flushrs from setjmp. That would simplify longjmp at the cost of
> > > > > severely pessimising setjmp.
> > > >
> > > > This is exactly what we now have and what I'm willing to
> > > > sacrificy at this time. It's easy enough to optimize
> > > > setjmp/longjmp once we have the *context stuff.
> > >
> > > This is totally wrong.
> >
> > No, it's a step in different direction than you would have chosen.
> > Pick your words with care. See also below.
> 
> I didn't choose this direction, Intel recommends it.

That's not what I mean. I don't think it's beneficial to try to explain
myself. See below.

> > Ah, I see. You avoid having the dirty registers on the kernel stack
> > by doing an exception restore to the original stack, do a flushrs and
> > then switch to the alternate stack. I wondered about this
> > hoop-jumping...
> 
> This also allows the possibility of saving/restoring the high floating 
> point state in user-mode instead of kernel mode which might be a good 
> thing in some situations.

I have to think about this angle. I've been thinking about the high FPs
in the context of SMP. The goal being to avoid saving the high FP in
cpu_switch altogether and deal with processes moving to a different CPU
in a lazy way. The same principle as avoiding the flushrs in setjmp...

> > Thus: I want people to sign-up for a libc_r that uses *context before
> > 5.0-RELEASE, but preferrably tomorrow. A well-intended timeline would
> > be very nice...
> 
> I want to see a libc_r which uses *context too. Its trivial to write 
> thread switching this way and they are designed for it (i.e. no more MD 
> grovelling around in the jmp_buf to setup the stack etc). I've been 
> using makecontext/switchcontext in my own code and it works very well. 
> Changing libc_r to switch this way should be easy if Dan hasn't already 
> done it.

Ok. I guess this is the best I can get. I'll work on it this weekend.
I'll restore the previous behaviour of setjmp/longjmp while I'm at it.

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel@xcllnt.net

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




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