Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!ncar!gatech!rutgers!njin!princeton!phoenix!haahr
From: haahr@phoenix.Princeton.EDU (Paul Gluckauf Haahr)
Newsgroups: comp.lang.c
Subject: Re: Behaviour of setjmp/longjmp and registers
Summary: caller-saves does it right
Message-ID: <5771@phoenix.Princeton.EDU>
Date: 24 Jan 89 18:03:40 GMT
References: <8812@alice.UUCP> <1989Jan23.190446.8559@utzoo.uucp>
Reply-To: haahr@princeton.edu (Paul Gluckauf Haahr)
Organization: Princeton University, Princeton NJ
Lines: 25

henry@utzoo.uucp (Henry Spencer) writes:
[ quoting andrew koenig (alice!ark) on john reiser's implementation
of longjmp() that unwound the stack to restore all register variables
that had been saved in previous stack frames ]
> >However, when it came to the ANSI committee, they decided it
> >would be too hard to mandate this kind of implementation...
> 
> Don't forget that it was (relatively) easy on the VAX because one of the
> things that the all-singing-all-dancing VAX procedure call does is to save
> a register mask.  This makes the VAX stack pretty much self-describing,
> at the cost of slowing down every function call and increasing the use
> of stack space.  Most other implementations consider that too high a
> price to pay.

a setjmp/longjmp implementation that restores all variables (including
those in registers) falls out of a caller saves function call protocol.
no muss, no fuss, just restore the stack pointer and pc.  this will
work in the presence of inter-procedural optimization, if setjmp() is
marked as a function that trashes all registers.

this is one of the several reasons i consider caller-saves a better
approach to function call protocol.

paul haahr
princeton!haahr or haahr@princeton.edu