Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP
Path: utzoo!utcsri!greg
From: greg@utcsri.UUCP (Gregory Smith)
Newsgroups: comp.arch
Subject: Re: subroutine frequency
Message-ID: <4160@utcsri.UUCP>
Date: Wed, 18-Feb-87 00:27:03 EST
Article-I.D.: utcsri.4160
Posted: Wed Feb 18 00:27:03 1987
Date-Received: Wed, 18-Feb-87 21:32:27 EST
References: <1881@homxc.UUCP> <898@moscom.UUCP> <476@mntgfx.MENTOR.COM> <651@mcgill-vision.UUCP>
Reply-To: greg@utcsri.UUCP (Gregory Smith)
Organization: CSRI, University of Toronto
Lines: 38
Keywords: register stack frame variable
Summary: 

In article <651@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP writes:

>>> The method used has a large effect on whether setjmp/longjmp can put
>>> the correct values back into register variables (SYSVID says they
>>> may be unpredictable :-(.
>> Sad, but true.
>
>WHAT?!?!  I can't see any reason that longjmp can't get the registers
>back - if it can't restore them easily on that architecture then just
>have setjmp save them in the jmp_buf!  What's the problem?  This will
>make longjmp basically useless, especially in the face of compilers
>that optimize non-"register" variables into registers!

jmp_buf env;

main(){
	register int i;
	int j;
	i = j = 1;
	if(setjmp(env)){
		printf( "i==%d, j==%d\n", i, j );
		exit(0);
	}
	i = j = 2;
	func();
}

func(){
	longjmp( env, 1 );
}

The above program should ideally report that i=2. Certainly it will say
that j is 2. If i is saved in the jmp_buf, and restored by longjmp,
then i will be reported as 1.
-- 
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg
Have vAX, will hack...