home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v1 / text0052.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  3.9 KB
  1. From: John Quarterman (moderator) <std-unix-request@ut-sally>
  2. Topic: Storage allocaters (alloca)
  3.  
  4. ----------------------------------------------------------------------
  5.  
  6. From: ihnp4!hcr!hcrvx1!hugh
  7. Date: 8 Aug 85 11:37:25 CDT (Thu)
  8. To: hcr!ihnp4!ut-sally!std-unix
  9. Subject: Re: Storage allocators
  10.  
  11. > ...since C supports variables on the stack, so I doubt that there are many
  12. > machines which can't do alloca(), and for Unix, it comes down to
  13. > documenting something that has been there for a long time.
  14.  
  15. alloca(), when implemented behind the back of a compiler is dangerous,
  16. as described earlier ("f(..., alloca(...), ...)").  It also has a
  17. potential performance penalty on EVERY function, not just those that use
  18. it: with alloca, the system is forced to have a distinct frame pointer
  19. and stack pointer.  Without the possibility of alloca, a frame pointer
  20. is not needed (the activation record can be accessed by
  21. known-at-compile-time offsets from the stack pointer).  Using two
  22. registers instead of one could cause a noticeable increase in function
  23. prologue/epilogue time.
  24.  
  25. I agree that the functionality of alloca() is useful, but it is not
  26. sanely handled as a library routine.  ALGOL-60 got this right;
  27. too bad its descendants didn't.
  28.  
  29. It appears that the C standard will give the compiler license to "know"
  30. about library routines specified in the standard (and no others!).  Thus
  31. the compiler would be able to treat alloca specially if it were included
  32. in the standard.  Such a compiler might need an extra pass to be able to
  33. avoid using a frame-pointer, and it would have to be able to generate
  34. code both with and without a frame-pointer.  Even generating correct code
  35. is tricky.  Perhaps, if alloca is standardized, it should be restricted
  36. to certain usages, just as setjmp has been.
  37.  
  38. My hope is that alloca could be eliminated.  But even though it is
  39. undocumented, there may be too many programs using it now.  Does anyone
  40. know?
  41.  
  42. Perhaps this discussion should be in mod.std.c, not mod.std.unix.  I
  43. hope that I have convinced you that this is a compiler/language issue,
  44. not an isolated library issue.
  45.  
  46. [ The article that started the discussion was cross-posted to the two
  47. newsgroups.  It's not clear that it still belongs in mod.std.unix,
  48. but since it's involved UNIX history and implementation, I've seen
  49. no reason to discourage it.  C library issues in general do more 
  50. properly belong in mod.std.c, though.  -mod ]
  51.  
  52. ------------------------------
  53.  
  54. From: ihnp4!tektronix!hammer.TEK!steveh (Stephen Hemminger)
  55. To: tektronix!ihnp4!seismo!ut-sally!jsq
  56. Date: Fri, 9 Aug 85 09:14:33 PDT
  57. Subject: Re: Storage allocators
  58. In-Reply-To: <2592@ut-sally.UUCP>
  59. References: <2561@ut-sally.UUCP> <2579@ut-sally.UUCP> <2590@ut-sally.UUCP>
  60.  
  61. On the Tek NS32000 computers we have to fudge to get alloca() to work, but
  62. I think the same technique might work on other computers.
  63.  
  64. The stack frame looks like:
  65.     sp ->  ...
  66.           saved registers (0 ... 8)
  67.           local vars
  68.     fp -> old fp
  69.           args
  70.  
  71. The kludge we implemented for alloca was to allocate 32 bytes (8 regs)
  72. more of storage and copy the top 32 bytes.  Unless the machine has
  73. a huge number of registers, this technique should allow alloca on
  74. any machine!
  75.  
  76.                 |--|        |--|
  77.   [I'd rather be skiing]    | /|        | /|
  78.                 .    |/ |        |/ |
  79.                    .|--|        |--|
  80.                 | .|        |  |
  81.     Stephen Hemminger    |  |.        |  |
  82.     (steveh@hammer.TEK)        .
  83.                    .
  84.                  .
  85.                     .
  86.  
  87. [ I've broken my rule of asking for explicit permission to post things
  88. mailed to my personal address, since this one was an obvious submission. -mod ]
  89.  
  90. ------------------------------
  91.  
  92. Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
  93. Submissions-To:    ut-sally!std-unix    or std-unix@ut-sally.ARPA
  94. Comments-To: ut-sally!std-unix-request    or std-unix-request@ut-sally.ARPA
  95. UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
  96. Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)
  97.  
  98. Volume-Number: Volume 1, Number 53
  99.  
  100.