home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / compiler / 1252 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  2.4 KB
  1. Path: sparky!uunet!europa.asd.contel.com!emory!ogicse!das-news.harvard.edu!spdcc!iecc!compilers-sender
  2. From: shankar@sgi.com (Shankar Unni)
  3. Newsgroups: comp.compilers
  4. Subject: Re: Pros and cons of high-level intermediate languages
  5. Keywords: translator, design
  6. Message-ID: <92-07-073@comp.compilers>
  7. Date: 23 Jul 92 00:17:01 GMT
  8. References: <92-07-064@comp.compilers> <92-07-070@comp.compilers>
  9. Sender: compilers-sender@iecc.cambridge.ma.us
  10. Reply-To: shankar@sgi.com (Shankar Unni)
  11. Organization: Silicon Graphics, Inc.
  12. Lines: 39
  13. Approved: compilers@iecc.cambridge.ma.us
  14.  
  15. bbx!bbx.basis.com!scott@unmvax.cs.unm.edu (Scott Amspoker) writes:
  16.  
  17. >   * The ANSI spec which renders stack variables unpredictable after
  18. >     a longjump() sucks.  This is solved by declaring them 'volatile'
  19. >     but then you might lose bigtime in the optimizer.
  20.  
  21. This is totally bogus. Let us assume that the ANSI spec were to say: local
  22. variables are guaranteed to retain their values when a longjmp() takes you
  23. back to the stack.
  24.  
  25. Now how would this be done on a machine with several registers (i.e.
  26. something more modern than an 8085)? You'd either:
  27.  
  28.   (a) have to save register-cached variables back to stack before every
  29.       call, making the call overhead prohibitive and slowing the whole
  30.       program down tremendously, OR
  31.   (b) Make "longjmp()" unwind stack-frame by stack-frame to return to the
  32.       setjmp() point, making *that* very expensive.
  33.  
  34. For (a), you only have to do the flushing in routines that call
  35. "setjmp()", and only for calls executed after the call to setjmp().  A
  36. compiler smart enough to do this, can also flush only those variables that
  37. are actually used after the setjmp() call.
  38.  
  39. But this is pretty much what you are doing by finding those variables
  40. yourself and declaring them "volatile".  You lose no more and possibly
  41. less by doing so, because you can often tell better than a compiler which
  42. variables you are *really* depending to keep their values after a
  43. longjmp() - there are usually only a couple at most in any routine.
  44.  
  45. The whole "optimizer/volatile" bogeyman is a knee-jerk reaction by the
  46. Luddites in the C programming community who are too lazy to identify the
  47. really volatile variables.
  48. --
  49. Shankar Unni                E-Mail:    shankar@sgi.com
  50. Silicon Graphics Inc.            Phone:    +1-415-390-2072
  51. -- 
  52. Send compilers articles to compilers@iecc.cambridge.ma.us or
  53. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  54.