home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 12038 < prev    next >
Encoding:
Text File  |  1993-01-02  |  2.1 KB  |  56 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!microsoft!wingnut!raymondc
  3. From: raymondc@microsoft.com (Raymond Chen)
  4. Subject: Re: No Last Call Optimization on Sparc and DECstation
  5. Message-ID: <1993Jan02.222131.21638@microsoft.com>
  6. Date: 02 Jan 93 22:21:31 GMT
  7. Organization: None.  That way I don't have to write a disclaimer.
  8. References: <1992Dec30.094352.4243@cucs5.cs.cuhk.hk> <1993Jan2.144518.20826@walter.bellcore.com>
  9. Lines: 45
  10.  
  11. In article <1992Dec30.094352.4243@cucs5.cs.cuhk.hk> bmtong@cs.cuhk.hk (Tong Bo-Ming) writes:
  12. >    p(a,b,c) { x(a); y(b); z(c); }
  13. >
  14. >In the above procedure, we may discard the current stack frame (or reg
  15. >window in Sparc) before calling z.  We then replace the call z
  16. >instruction by a jump instruction.
  17. >
  18. >It is a sad thing to notice that such a nice optimization is not
  19. >implemented in languages other than Prolog and on RISC architectures.
  20.  
  21. As has been noted, LISP-like languages are major consumers of tail
  22. recursion technology.
  23.  
  24. In article <1993Jan2.144518.20826@walter.bellcore.com> mo@gizmo.bellcore.com (Michael O'Dell) writes:
  25. : There are a number of challenges to exploiting the technique 
  26. : in C compilers (having to do with exception handling, setjmp/longjmp,
  27. : etc).
  28.  
  29. I figure stack management is the toughest part.  the "caller cleans the
  30. stack" calling convention used by many compilers (to make variadic
  31. functions easier) makes it impossible to optimize the last call in a
  32. function like
  33.  
  34.     f(a) { return g(a, 2); }
  35.  
  36. because f's caller will clean only one word from the stack, whereas
  37. g will leave two words of garbage on the stack when it exits.
  38.  
  39. And pointers really make things confusing.  If you gave anybody a pointer
  40. to a local variable, you cannot optimize the last call.  Consider,
  41. for example,
  42.  
  43.     f(a) { int b; g(&b); return h(a); }
  44.  
  45. You can't clean f's stack frame before calling h(), because g() and h()
  46. might've been written like this:
  47.  
  48.     int *scary;
  49.     g(p) int *p; { scary = p; *scary = 2; }
  50.     h(a) { return *scary + a; }
  51.  
  52. We learn once again that the tremendous flexibility of C's pointers
  53. proves an obstacle to optimization.  (As if we didn't know this already.)
  54. --
  55. Raymond (not a compiler writer) Chen
  56.