Path: utzoo!attcan!uunet!seismo!esosun!cogen!celerity!jjw
From: jjw@celerity.UUCP (Jim )
Newsgroups: comp.arch
Subject: Re: register save/restore (longjmp)
Message-ID: <196@celerity.UUCP>
Date: 9 Nov 88 18:05:00 GMT
References: <3300037@m.cs.uiuc.edu> <5938@killer.DALLAS.TX.US> <7580@aw.sei.cmu.edu> <3473@pt.cs.cmu.edu> <6800006@modcomp> <17965@utzoo.uucp>
Reply-To: jjw@celerity.UUCP (Jim (JJ) Whelan)
Organization: FPS Computing, San Diego CA
Lines: 42

In article <6800006@modcomp> joe@modcomp.UUCP writes in response to
firth@bd.sei.cmu.edu (Robert Firth):
>The callee-save implementations that I have seen all have a fast longjump
>mechanism.  Typically, the setjmp(x) call saves (an adjusted version of) the
>entire machine state in x, and longjmp(x) jumps simply by restoring that
>state.  No attempt is made to depend on information which may or may not be
>on the stack after the setjmp call.

Of course, this is the mechanism which results in the situation described by
bsy@PLAY.MACH.CS.CMU.EDU (Bennet Yee) in article <3473@pt.cs.cmu.edu>:

> ... your registers have the same values as when they returned from the
>setjmp.  On Vaxen, your registers have the same values as they had when you
>called the next function from within the same function that called the
>setjmp.  So depending on one or the other behaviour for your register
>variables is not safe.  It's a minor but significant semantic difference.

This is more than a minor difference since optimizing compilers will keep any
variable in a register when necessary.

henry@utzoo.uucp (Henry Spencer) in article <17965@utzoo.uucp> points out
one solution:
>			... X3J11 has wimped out on
>it, in a big way:  the values of *any* local variables (not just register
>variables -- the compiler may be quietly promoting things into registers!)
>that have changed since the setjmp are *indeterminate* after a longjmp,
>unless the variables are declared "volatile".  Note, there is no guarantee
>that you get *either* of the above cases!  The values may even be trash!

As Harry Spencer stated this "invalidates essentially every existing
program that uses setjmp/longjmp."

It is possible for the information saved in the "jump buffer" to indicate
where the register information is being saved on the stack so that it can be
restored by longjmp.  This is the mechanism used in the FPS Model 500.
There are some difficulties with signal handlers using longjumps since the
callee could be in the middle of saving the state when the signal occurs.

The use of setjmp does require that the compiler generate some additional
code on calls (especially if signal handlers can perform longjmp's) so there
are compiler optimization options which do not guarantee "non-volatile"
variable contents.