Re: handling setjmp/longjmp in new front-end

[Fergus Henderson <fjh at cs dot mu dot oz dot au>]

On 29-Dec-2000, Richard Henderson <rth@redhat.com> wrote:
> On Fri, Dec 29, 2000 at 06:27:00PM +1100, Fergus Henderson wrote:
> > The existing Mercury compiler generates C code that uses
> > setjmp() and longjmp().
> 
> For what do you use setjmp/longjmp?

For implementing commits (the Mercury equivalent to Prolog's '!' (cut)
operator).  Prolog-style nondeterminism is implemented using continuation
passing, and commits become longjmps.

> Perhaps you really want to be using gcc's exception handling mechanisms?

Perhaps.  That's what we do for the .NET port.
But commits are not an "exceptional" event.

We don't need the handling of cleanups (e.g. C++ destructors) that you
get with exception handling, since we know that the stack frames that
a commit unwinds will all be Mercury stack frames, which don't have
any cleanups.

Which is likely to be more efficient, __builtin_{setjmp,longjmp} or
exception handling?

> > What exactly are the restrictions?  Is it just that __builtin_longjmp()
> > must always be called with the second argument being `1', or is there
> > more to it?
> 
> The only extra restriction that I am aware of is that you cannot
> __builtin_longjmp to a jmpbuf within the current function.

OK, that's easy to avoid. 

Thanks for the advice.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.