Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!ucbvax!hplabs!amdcad!crackle!tim
From: tim@crackle.amd.com (Tim Olson)
Newsgroups: comp.lang.c
Subject: Re: Behaviour of setjmp/longjmp and registers
Message-ID: <24193@amdcad.AMD.COM>
Date: 25 Jan 89 16:18:24 GMT
References: <25@torsqnt.UUCP> <8867@bloom-beacon.MIT.EDU> <7222@polyslo.CalPoly.EDU> <1989Jan23.005859.24468@utzoo.uucp> <7283@polyslo.CalPoly.EDU>
Sender: news@amdcad.AMD.COM
Reply-To: tim@amd.com (Tim Olson)
Organization: Advanced Micro Devices, Inc. Sunnyvale CA
Lines: 31
Summary:
Expires:
Sender:
Followup-To:

In article <7283@polyslo.CalPoly.EDU> cquenel@polyslo.CalPoly.EDU (96 more school days) writes:
| henry@utzoo.uucp writes :
| >However, an implementation that simply trashes the registers (rather,
| >allows them to be trash) or, still worse, does likewise for automatic
| >variables not declared "register" (i.e. by promoting them to registers
| >and then not preserving them), is probably not going to sell well when
| >word gets around.
| 
| 	What about a machine like the Pyramid with sliding register
| 	windows.  It has 4 classes of registers.
| 	Global Registers    : not touched on a procedure call.
| 	Parameter Registers : Contain parameters on entry to routine
| 	Local Registers     : For normal automatic variables
| 	Temporary Registers : For transient temporaries in expressions

Register-windowed machines are usually very easy to write
setjmp()/longjmp() for, because the registers are treated as a
"stack-cache".  Thus, all you have to save is the current stack-cache
pointer in the jmpbuf, and restore it upon a longjmp().  This makes
automatic variables act just as statics do: their value is that as of
the time of the longjmp().  This is much cleaner than the botch of
saving the register contents in the jmpbuf and restoring them.

Of course, you still have to worry about optimizations such as register
coalescing, etc.



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