home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / compiler / 1254 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  4.5 KB

  1. Path: sparky!uunet!pmafire!news.dell.com!swrinde!mips!darwin.sura.net!wupost!think.com!spdcc!iecc!compilers-sender
  2. From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  3. Newsgroups: comp.compilers
  4. Subject: Re: Pros and cons of high-level intermediate languages
  5. Keywords: translator, design
  6. Message-ID: <92-07-075@comp.compilers>
  7. Date: 23 Jul 92 09:14:14 GMT
  8. References: <92-07-064@comp.compilers> <92-07-073@comp.compilers>
  9. Sender: compilers-sender@iecc.cambridge.ma.us
  10. Reply-To: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  11. Organization: Computer Science, University of Melbourne, Australia
  12. Lines: 77
  13. Approved: compilers@iecc.cambridge.ma.us
  14.  
  15. shankar@sgi.com (Shankar Unni) writes:
  16.  
  17. >bbx!bbx.basis.com!scott@unmvax.cs.unm.edu (Scott Amspoker) writes:
  18. > [ re optimizing around setjmp()
  19. >
  20. >This is totally bogus. Let us assume that the ANSI spec were to say: local
  21. >variables are guaranteed to retain their values when a longjmp() takes you
  22. >back to the stack.
  23. >
  24. >Now how would this be done on a machine with several registers (i.e.
  25. >something more modern than an 8085)? You'd either:
  26. >
  27. >  (a) have to save register-cached variables back to stack before every
  28. >      call, making the call overhead prohibitive and slowing the whole
  29. >      program down tremendously, OR
  30. >  (b) Make "longjmp()" unwind stack-frame by stack-frame to return to the
  31. >      setjmp() point, making *that* very expensive.
  32. >
  33. >For (a), you only have to do the flushing in routines that call
  34. >"setjmp()", and only for calls executed after the call to setjmp().  A
  35. >compiler smart enough to do this, can also flush only those variables that
  36. >are actually used after the setjmp() call.
  37. >
  38. >But this is pretty much what you are doing by finding those variables
  39. >yourself and declaring them "volatile".  You lose no more and possibly
  40. >less by doing so, because you can often tell better than a compiler which
  41. >variables you are *really* depending to keep their values after a
  42. >longjmp() - there are usually only a couple at most in any routine.
  43.  
  44. But then if you *do* have a machine where register variables are saved and
  45. restored by setjmp/longjmp, then the compiler will be unable to do any
  46. optimization on the local variables, since you have declared them as
  47. volatile!
  48.  
  49. What about option (c): let the compiler handle the details.
  50.  
  51. It is not difficult. There are basically two cases:
  52.     (1) Registers can be saved/restored by setjmp/longjmp.
  53.         In this case, there is nothing to do.
  54.     (2) Registers cannot be easily saved/restored by setjmp/longjmp.
  55.         In this case, compiler can check each function to see whether
  56.         it contains a call to setjmp. (setjmp is a macro, so there is
  57.         no problem with the programmer taking its address and calling it
  58.         via a function pointer). If the function does contain a call to
  59.         setjmp, then just mark all the local variables as volatile.
  60.  
  61. Of course in case (2) the compiler can apply much more sophisticated
  62. optimization than just considering everything volatile. For example it
  63. might prevent the local variables from being stored in registers but still
  64. consider them as candidates for common sub-expression elimination and many
  65. other optimizations. I would be much more inclined to say that the
  66. compiler is in a better position to say which variables are used after
  67. setjmp is called than the programmer. When you consider further the
  68. possiblilty that the code may have to be maintained, the likelyhood of
  69. maintenance programmers accidentally introducing extremely obscure bugs is
  70. another reason to prefer letting the compiler handle it.
  71.  
  72. >The whole "optimizer/volatile" bogeyman is a knee-jerk reaction by the
  73. >Luddites in the C programming community who are too lazy to identify the
  74. >really volatile variables.
  75.  
  76. The whole "ANSI setjmp/volatile" spec. is a knee-jerk reaction by the
  77. Luddites in the C compiler implementors community who are too lazy to 
  78. bother implementing a very simple modification to their compilers that would
  79. benefit users (:-).
  80.  
  81. The benefit is two-fold: firstly it is much easier to use setjmp (and much
  82. easier for less experienced programmers in particular), and secondly it
  83. allows much more room for smart compilers to do a decent job of
  84. optimization.  The ANSI spec (like the C++ committee's Humpty-Dumpty
  85. const) goes against the grain of the language, which was designed to give
  86. compilers as much opportunity to generate efficient code as possible.
  87. -- 
  88. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  89. -- 
  90. Send compilers articles to compilers@iecc.cambridge.ma.us or
  91. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  92.