Xref: utzoo comp.std.c:1103 comp.sys.encore:223
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!accuvax.nwu.edu!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.std.c,comp.sys.encore
Subject: Re: setjmp/longjmp
Message-ID: <17179@mimsy.UUCP>
Date: 28 Apr 89 17:54:49 GMT
References: <1447@cunixc.cc.columbia.edu> <1989Apr27.165319.23986@utzoo.uucp>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 33

In article <1989Apr27.165319.23986@utzoo.uucp> henry@utzoo.uucp
(Henry Spencer) writes:
>... in the general case [getting variables right after setjmp/longjmp is]
>very hard.

It is not *that* hard.  It does inhibit some optimisation:

>... a very clever compiler can change save/restore conventions when
>it notices the setjmp() ....

This is a reasonable approach.  setjmp/longjmp are rare enough that I
doubt it will slow things much.

	... compiler code for function call ...
	if (function is setjmp || function is longjmp ||
	    setjmp is called previously in this function) {
		for (all active registers)
			if (register is used only to hold function address)
				/* do nothing */;
			else
				store the register and mark it invalid;
	}
	... generate the call itself ...
	if (function is longjmp)
		reachable = FALSE;	/* all variables are now dead */

(here `previously' means `is reachable via a flow path that might have
run before this function call is reached'---the call can appear below
if there is a loop label above this call.)  setjmp and longjmp
themselves then need not save or restore any registers.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris