Re: Pros and cons of high-level intermediate languages

shankar@sgi.com (Shankar Unni)
Thu, 23 Jul 1992 00:17:01 GMT

          From comp.compilers

Related articles
Pros and cons of high-level intermediate languages ssp@csl36h.csl.ncsu.edu (1992-07-20)
Re: Pros and cons of high-level intermediate languages boehm@parc.xerox.com (1992-07-21)
Re: Pros and cons of high-level intermediate languages chased@rbbb.Eng.Sun.COM (1992-07-21)
Re: Pros and cons of high-level intermediate languages bbx!bbx.basis.com!scott@unmvax.cs.unm.edu (1992-07-22)
Re: Pros and cons of high-level intermediate languages shankar@sgi.com (1992-07-23)
Re: Pros and cons of high-level intermediate languages Olivier.Ridoux@irisa.fr (1992-07-23)
Re: Pros and cons of high-level intermediate languages fjh@munta.cs.mu.OZ.AU (1992-07-23)
Re: Pros and cons of high-level intermediate languages tmb@idiap.ch (1992-07-23)
Re: Pros and cons of high-level intermediate languages henry@zoo.toronto.edu (1992-07-23)
Re: Pros and cons of high-level intermediate languages tarvydas@tsctrl.guild.org (1992-07-23)
Re: Pros and cons of high-level intermediate languages graham@maths.su.oz.au (1992-07-24)
[23 later articles]
| List of all articles for this month |
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
--


Post a followup to this message

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