Behaviour of setjmp/longjmp and registers

[Wonderly]

>From article <5771 at phoenix.Princeton.EDU>, by haahr at phoenix.Princeton.EDU (Paul Gluckauf Haahr):
> 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.

Except that this kills any efficency that one might try to gain through
the use of normal scratch registers at the lowest level of function call.

What is the expense of 

	for (i=0; i < cnt; ++i)
		cnt[i] = strlen (str[i]);

when caller saves verses the case where called saves?  If caller uses a
lot of registers, it will continually save/restore them if caller saves
whereas when called saves, it can decide when all of that work should
really be done.

It strikes me that setjmp() could save all GP registers.  I know of at
least one implementation were a jmp_buf is enough space for the entire
register set.  longjmp() of course just reloads the registers grabs the
return value passed, and jumps to the return address given to it (on the
stack or elsewhere).  The expense is a consideration but the results are
guaranteed in the cases I can think of.

Unwinding the stack doesn't seem necessary and in fact seems counter
productive.  Of course there are those that would argue that
setjmp()/longjmp() must be efficient because they want to call setjmp in
a tight loop some place!

-- 
Gregg Wonderly                             DOMAIN: gregg at ihlpb.att.com
AT&T Bell Laboratories                     UUCP:   att!ihlpb!gregg