Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!amdcad!crackle!tim
From: tim@crackle.amd.com (Tim Olson)
Newsgroups: comp.arch
Subject: Re: Complex Instructions
Message-ID: <25283@amdcad.AMD.COM>
Date: 19 Apr 89 03:53:47 GMT
References: <57252@yale-celray.yale.UUCP> <531@ksr.UUCP>
Sender: news@amdcad.AMD.COM
Reply-To: tim@amd.com (Tim Olson)
Organization: Advanced Micro Devices, Inc. Sunnyvale CA
Lines: 24
Summary:
Expires:
Sender:
Followup-To:

In article <531@ksr.UUCP> richt@ksr.UUCP (Rich Title) writes:
| In article <57252@yale-celray.yale.UUCP> leichter@CS.YALE.EDU (Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)) writes:
| 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.

Not necessarily.  As has been pointed out here in the past,
register-windowed machines can get by with very simple
setjmp()/longjmp() implementations.  Setjmp() only needs to save the
current stack pointer and stack-cache bounds in the jmpbuf; longjmp()
restores these values (the standard return from a function makes sure
that the frame being returned into is entirely in the stack cache). 

This implementation also makes "register" variables act like memory
variables -- after a longjmp() both contain the same values as of the
time of the longjmp() call, rather than having register values suddenly
restored to their contents at the time of the setjmp() call.

	-- Tim Olson
	Advanced Micro Devices
	(tim@amd.com)