Behaviour of setjmp/longjmp and registers
Tim Olson
tim at crackle.amd.com
Thu Jan 26 02:18:24 AEST 1989
In article <7283 at polyslo.CalPoly.EDU> cquenel at polyslo.CalPoly.EDU (96 more school days) writes:
| henry at 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 at crackle.amd.com)
More information about the Comp.lang.c
mailing list