Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!ksr!breakpoint!richt
From: richt@breakpoint.ksr.com (Rich Title)
Newsgroups: comp.arch
Subject: Re: Complex Instructions
Message-ID: <531@ksr.UUCP>
Date: 18 Apr 89 13:31:50 GMT
References: <57252@yale-celray.yale.UUCP>
Sender: nobody@ksr.UUCP
Reply-To: richt@ksr.UUCP (Rich Title)
Organization: Kendall Square Research, Cambridge MA
Lines: 43

In article <57252@yale-celray.yale.UUCP> leichter@CS.YALE.EDU (Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)) writes:

> [Discussion of VMS call conventions & stack unwinding...]

>Now, you can argue about whether such a condition handling mechanism is impor-
>tant.  Unix gets by without it...

In UNIX, setjmp/longjmp are the mechanism for stack unwinding. UNIX didn't
make the VMS mistake of getting stack-unwind mixed up with condition
handling: longjmp can be executed from anywhere (though it is most commonly
done from within a handler). 

setjmp simply saves an entire register set, so longjmp need not do the 
frame-by-frame unwind that VMS's $UNWIND must do. 

The advantage of the UNIX method of stack unwinding is that it is 
relatively portable, and doesn't make demands on the calling conventions.
The disadvantage is that the establish-an-unwind-point (the setjmp call)
is more expensive: an entire register set must be saved, as opposed to
just putting a word on the stack as in VMS. So there's pro & cons to each
approach.

>In fact, what often gets overlooked in discussing the VAX architecture was
>that it was NOT designed by hardware people alone.  It was the result of a
>lot of give and take between hardware and software people.  It was the soft-
>ware people who said "we want a condition handling facility which provides
>certain features (in particular, no cost to code which doesn't use it...

Well, to rebut that one, let me simply quote you again (!)

>Here's a simple example:  It's common for procedures to have a two different
>paths, one for a simple case, one for a complex case.  It may very well be
>that the simple case path uses fewer registers than the complex case path.
>So you'd be tempted to say "on entry (i.e., using the procedure entry mask)
>just save the registers that the simple case uses (or that both use); if the
>complex case occurs, save and restore those explicitly".  This is illegal
>under the procedure call standard, for a simple reason:  If the stack gets
>unwound through the complex case's code, the registers it had saved "by hand"
>would not be restored...

Aha! So there *is* a cost to the code that is not using it after all...

    - Rich