home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / cplus / 2028 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  4.1 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!male.EBay.Sun.COM!exodus.Eng.Sun.COM!rbbb!chased
  2. From: chased@rbbb.Eng.Sun.COM (David Chase)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Use of nested functions (Was: Proposal for default scope)
  5. Date: 11 Jan 1993 19:55:44 GMT
  6. Organization: Sun
  7. Lines: 84
  8. Message-ID: <ll3k60INNih@exodus.Eng.Sun.COM>
  9. References: <lkrt9oINNjq2@exodus.Eng.Sun.COM> <1993Jan9.040554.3064@qualcomm.com>
  10. NNTP-Posting-Host: rbbb
  11.  
  12. greg@harvey.qualcomm.com (Greg Noel) writes:
  13. >David Chase <chased@rbbb.Eng.Sun.COM> writes:
  14. >>This is not correct.  Nested functions are not expensive to implement.
  15.  
  16. >OK, how do you do it so that:
  17. >     o    It's efficient enough on a wide class of architectures that I don't
  18. >    care about the overhead involved in using it.
  19.  
  20. The best trick in my book uses run-time code generation.  There are
  21. actually two ways to do this, depending upon the cache-flush penalty.
  22. You can either generate the code in-line (in your activation record)
  23. or you can keep a cache of code fragments.  The cached-fragment scheme
  24. is probably cheapest -- that's probably fewer than a dozen RISC
  25. instructions to get your hands on a "nested" function.
  26.  
  27. >     o    There is no penalty for _not_ using it.
  28.  
  29. That's the appeal of run-time code generation -- function pointers
  30. remain as function pointers always were.
  31.  
  32. >     o    It invokes the subroutine in the context where its address was
  33. >    evaluated, even under recursion.
  34.  
  35. Since this is necessary for correctness, it goes without saying.
  36. See the definition of Modula-3.
  37.  
  38. >     o    It's thread-safe; that is, the compiler doesn't create any global
  39. >    variables or the like behind my back.
  40.  
  41. Since this is necessary for correctness, it goes without saying.
  42. See the definition of Modula-3.
  43.  
  44. >     o    The address of the function is compatible with a ``standard''
  45. >    function variable.
  46.  
  47. This is necessary for correctness, but language designers like to wimp
  48. out and let nested functions become dangling references in the same
  49. way that pointers to auto variables can become dangling references.
  50. This is not a new problem.  Garbage collection would solve both
  51. problems, but that is another discussion.
  52.  
  53. >Note that if you can do this, it would be possible to bind a non-static class
  54. >member function and a class object together, assign that to a ``standard''
  55. >function variable, and arrange that when the function variable was invoked,
  56. >the class member function would be invoked on the object.  The mechanisms
  57. >involved are equivalent.
  58.  
  59. Of course.  I would hope that this would happen, since I have needed
  60. to do it more than once.
  61.  
  62. >>I speak as someone who has done it.
  63.  
  64. > I'm willing to be proven wrong, but it will take more than just an
  65. > assertion that it can be done.
  66.  
  67. Run-time code generation works well here.  For 68K and 386, the
  68. compile-time version of a nested function has an additional first
  69. parameter (the parameter is supplied by the run-time version of the
  70. function, which pushes it into the stack).  For Sparc, one of the
  71. global registers (2,3,4 are available) is used to pass a hidden
  72. parameter to the compiler-time version of the routine.  I described
  73. this in much gorier detail in an earlier post, including instruction
  74. sequences.  I wouldn't be surprised if GCC used this trick.
  75.  
  76. Obviously, the compiler must take note of which variables are accessed
  77. by the nested function, and which are not, and which are altered by
  78. the nested function, and which are not.  There's several choices for
  79. how you might represent the shared variables, once you've decided to
  80. use the RTCG trick to get the data to the actual code that you want to
  81. execute (I think Andrew Appel and Trevor Jim wrote a fairly through
  82. Princeton tech report on this sometime within the past 5 years.)
  83.  
  84. >Don't get me wrong---I would like to have nested functions.  But the same
  85. >logic that prevented the adoption of an exponention operator is in effect
  86. >here: it can be ``unexpectedly'' costly.
  87.  
  88. I don't think this is unexpectedly costly, having implemented it and
  89. used it in the past.  There are costs, but the run-time code
  90. generation trick restricts them to the actual use of nested functions,
  91. and that cost is typically not greater than the cost of faking the
  92. nested function with objects.
  93.  
  94. David Chase
  95. Sun
  96.