Path: utzoo!attcan!uunet!modcomp!joe
From: joe@modcomp.UUCP
Newsgroups: comp.arch
Subject: Re: register save/restore
Message-ID: <6800006@modcomp>
Date: 5 Nov 88 04:12:00 GMT
References: <3300037@m.cs.uiuc.edu>
Lines: 30
Nf-ID: #R:m.cs.uiuc.edu:3300037:modcomp:6800006:000:1465
Nf-From: modcomp.UUCP!joe    Nov  4 23:12:00 1988


firth@bd.sei.cmu.edu (Robert Firth) writes:

> Which is better - caller saves or callee saves?
> [...]
> Which is more efficient?
> [...]
> The most blatant case is that of the longjump, which appears in other
> languages as a GOTO or RAISE statement.  This causes a jump out of a
> procedure to somewhere further up the call chain, and so must reset the
> environment of the destination.  If the caller saves state, then this is
> simple: the jump is a jump, and the destination knows where all the state
> has been saved.  In most implementations, one need only reset the frame
> pointer to the current incarnation of the destination procedure, and take
> the jump to the label.
> 
> But if the callee saves, then the caller has no idea how to recover his
> saved state, which may be buried any number of stack frames further down.
> It is therefore necessary to unwind the entire stack before taking the jump.
> The difference in cost can easily be a factor of 100 or more.
                                         ^^^^^^^^^^^^^^^^^^^^^

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.

Joe Korty		I'm suffering from a virus ...
uunet!modcomp!joe		... but my machine isn't.