Path: utzoo!attcan!uunet!husc6!uwvax!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.arch
Subject: Re: register save/restore (longjmp)
Message-ID: <14512@mimsy.UUCP>
Date: 12 Nov 88 19:03:04 GMT
References: <3300037@m.cs.uiuc.edu> <5938@killer.DALLAS.TX.US> <196@celerity.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 34

In article <196@celerity.UUCP> jjw@celerity.UUCP (Jim) writes:
>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.

This is probably the best approach.  It does affect optimisation,
obviously, but at least at the moment, calls to setjmp() are rare;
not too many functions should have much trouble here.

>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.

This is not hard to solve:  Save all registers in memory before entry 
to setjmp(); have setjmp() note (in some fashion) when it is done saving
state; and have longjmp() check to be sure the state is done, and if not,
restore nothing.  The last will succeed since there are no live registers
around the setjmp call itself.

>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.

This is certainly acceptable.

The situation is much worse in GCC, which decides which variables
should be placed in registers, and adheres to the letter of X3J11 by
guaranteeing only volatile variables.  Under `-traditional', GCC
attempts to accept old PCC-based code, to the extent of turning off the
`volatile' keyword, but NOT to the extent of not promoting variables
into registers, so there is no way to guarantee any local variable!
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris