home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!pmafire!news.dell.com!swrinde!mips!darwin.sura.net!wupost!think.com!spdcc!iecc!compilers-sender
- From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
- Newsgroups: comp.compilers
- Subject: Re: Pros and cons of high-level intermediate languages
- Keywords: translator, design
- Message-ID: <92-07-075@comp.compilers>
- Date: 23 Jul 92 09:14:14 GMT
- References: <92-07-064@comp.compilers> <92-07-073@comp.compilers>
- Sender: compilers-sender@iecc.cambridge.ma.us
- Reply-To: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
- Organization: Computer Science, University of Melbourne, Australia
- Lines: 77
- Approved: compilers@iecc.cambridge.ma.us
-
- 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
- --
- Send compilers articles to compilers@iecc.cambridge.ma.us or
- {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.
-