Newsgroups: | comp.compilers |
From: | shankar@sgi.com (Shankar Unni) |
Organization: | Silicon Graphics, Inc. |
Date: | Thu, 23 Jul 1992 00:17:01 GMT |
References: | 92-07-064 92-07-070 |
Keywords: | translator, design |
bbx!bbx.basis.com!scott@unmvax.cs.unm.edu (Scott Amspoker) writes:
> * The ANSI spec which renders stack variables unpredictable after
> a longjump() sucks. This is solved by declaring them 'volatile'
> but then you might lose bigtime in the optimizer.
This is totally bogus. Let us assume that the ANSI spec were to say: local
variables are guaranteed to retain their values when a longjmp() takes you
back to the stack.
Now how would this be done on a machine with several registers (i.e.
something more modern than an 8085)? You'd either:
(a) have to save register-cached variables back to stack before every
call, making the call overhead prohibitive and slowing the whole
program down tremendously, OR
(b) Make "longjmp()" unwind stack-frame by stack-frame to return to the
setjmp() point, making *that* very expensive.
For (a), you only have to do the flushing in routines that call
"setjmp()", and only for calls executed after the call to setjmp(). A
compiler smart enough to do this, can also flush only those variables that
are actually used after the setjmp() call.
But this is pretty much what you are doing by finding those variables
yourself and declaring them "volatile". You lose no more and possibly
less by doing so, because you can often tell better than a compiler which
variables you are *really* depending to keep their values after a
longjmp() - there are usually only a couple at most in any routine.
The whole "optimizer/volatile" bogeyman is a knee-jerk reaction by the
Luddites in the C programming community who are too lazy to identify the
really volatile variables.
--
Shankar Unni E-Mail: shankar@sgi.com
Silicon Graphics Inc. Phone: +1-415-390-2072
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.