Behaviour of setjmp/longjmp and registers

[96 more school days]

henry at utzoo.uucp writes :
>However, an implementation that simply trashes the registers (rather,
>allows them to be trash) or, still worse, does likewise for automatic
>variables not declared "register" (i.e. by promoting them to registers
>and then not preserving them), is probably not going to sell well when
>word gets around.

	Promoting register variables to automatic is not
	strictly necessary to not restore it on a longjmp.
	(if you can follow that sentance structure).

	Automatic variables need not be restored according to ANSI.

	Older machines had the effect of restoring variables that
	were left on the stack, but my argument is this :

	That there is actually not that much code out there (that
	purports to be portable :-) ) that DEPENDS on this 
	behaviour.  I looked at the bourne shell, and it uses
	setjmp/longjmp only for goto-purposes.

	Given the current breed of compiler writers, I would expect
	a fair number of compilers NOT to attempt to save miscellaneous
	registers.

	Consider a register file that is divided into 
	SAVED and NOTSAVED registers which (by convention)
	are/are-not saved on a procedure call. Do we save
	the NOTSAVED class registers on a setjmp ?

	What about a machine like the Pyramid with sliding register
	windows.  It has 4 classes of registers.
	Global Registers    : not touched on a procedure call.
	Parameter Registers : Contain parameters on entry to routine
	Local Registers     : For normal automatic variables
	Temporary Registers : For transient temporaries in expressions



>The old de-facto rule was that register variables
>had either current values or values as of the setjmp call, and that
>other automatics weren't touched at all.

If this "existing practice" could be supported with a reasonable
expense, I would say go for it, but the following things argue against it:

-- With many new architectures, it's not easy to do.
   (It doesn't come for free when restoring the frame-pointer)

-- Compiler technology has improved to the point where the
   concept of what is "in registers" and what isn't is not
   only hard to guarantee, but in some of the more different 
   architectures, might not even make sense.

   (As I've said in a previous posting) 
-- The real purpose of setjmp/longjmp is as a global goto
   when you have to go around the stack.  It shouldn't
   need any "features" that make it easier to use.o

-- When a signal handler (or other equivalently nasty program)
   needs to save state, then it can store (!) just the variables
   it needs in volatile variables that it keeps associated with 
   the setjmp.

-- No semi-legitimate uses of setjmp/longjmp that come to mind
   actually would require the restoral of variables to function.

>will thus break essentially every longjmp-using program in existence.

	Do you have some evidence here ?

--chris

The life of a signal-handler is nasty, brutish and short.