Re: Pros and cons of high-level intermediate languages

shankar@sgi.com (Shankar Unni) writes:


>bbx!bbx.basis.com!scott@unmvax.cs.unm.edu (Scott Amspoker) writes:
> [ re optimizing around setjmp()
>
>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.


But then if you *do* have a machine where register variables are saved and
restored by setjmp/longjmp, then the compiler will be unable to do any
optimization on the local variables, since you have declared them as
volatile!


What about option (c): let the compiler handle the details.


It is not difficult. There are basically two cases:
(1) Registers can be saved/restored by setjmp/longjmp.
In this case, there is nothing to do.
(2) Registers cannot be easily saved/restored by setjmp/longjmp.
In this case, compiler can check each function to see whether
it contains a call to setjmp. (setjmp is a macro, so there is
no problem with the programmer taking its address and calling it
via a function pointer). If the function does contain a call to
setjmp, then just mark all the local variables as volatile.


Of course in case (2) the compiler can apply much more sophisticated
optimization than just considering everything volatile. For example it
might prevent the local variables from being stored in registers but still
consider them as candidates for common sub-expression elimination and many
other optimizations. I would be much more inclined to say that the
compiler is in a better position to say which variables are used after
setjmp is called than the programmer. When you consider further the
possiblilty that the code may have to be maintained, the likelyhood of
maintenance programmers accidentally introducing extremely obscure bugs is
another reason to prefer letting the compiler handle it.


>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.


The whole "ANSI setjmp/volatile" spec. is a knee-jerk reaction by the
Luddites in the C compiler implementors community who are too lazy to
bother implementing a very simple modification to their compilers that would
benefit users (:-).


The benefit is two-fold: firstly it is much easier to use setjmp (and much
easier for less experienced programmers in particular), and secondly it
allows much more room for smart compilers to do a decent job of
optimization. The ANSI spec (like the C++ committee's Humpty-Dumpty
const) goes against the grain of the language, which was designed to give
compilers as much opportunity to generate efficient code as possible.
--
Fergus Henderson fjh@munta.cs.mu.OZ.AU
--

Return to the comp.compilers page.
Search the comp.compilers archives again.