home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / 3b1 / 3274 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  3.1 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!rphroy!hobbes!tkacik
  2. From: tkacik@hobbes.hobbes.cs.gmr.com (Tom Tkacik)
  3. Newsgroups: comp.sys.3b1
  4. Subject: Re: Lack of libPW.a module
  5. Message-ID: <89582@rphroy.ph.gmr.com>
  6. Date: 3 Sep 92 11:54:45 GMT
  7. Sender: news@rphroy.ph.gmr.com
  8. Reply-To: tkacik@hobbes.hobbes.cs.gmr.com
  9. Organization: GM Research Labs
  10. Lines: 77
  11. Nntp-Posting-Host: hobbes.cs.gmr.com
  12.  
  13. In article 4632@digibd.com, steve@digibd.com (Steve Wahl writes:
  14. > I don't think anyone understands me yet.  First, some context.
  15. > 
  16. > In article <1992Aug29.052011.24352@colnet.cmhnet.org> res@colnet.cmhnet.org (Rob Stampfli) writes:
  17. > >In article <1992Aug27.213851.20578@digibd.com> steve@digibd.com (Steve Wahl) writes:
  18. > >[ alloca.s code deleted ]
  19. > >>
  20. > >>Rob's post mentions that you can't call this alloca() when there's
  21. > >>something on the stack.  But beware: I believe this aproach also fails
  22. > >>if you use register variables in your functions: think about how the
  23. > >>compiler saves and restores the registers.
  24.  
  25. All passed parameters and local variables will be ahead of the alloca'd
  26. space, and will be accessed via the frame pointer (%a6) rather than the
  27. stack pointer (%sp aka %a7).  Only temporary variables are accessed via
  28. the stack pointer.
  29.  
  30. Register variables are ok, as they will be saved before the alloca.  The stack
  31. will be clear.  The only problem is using alloca in an expression.
  32. Never do something like   char *c; c=i*(j+alloca(10))
  33. Any temporaries that are put on the stack for this expression are accessed via
  34. the stack pointer, and will be corrupted.
  35.  
  36. Also, note that this alloca is non-reentrant.  Do not do c=alloca(alloca(10)).
  37. This one is guarenteed not to work.
  38.  
  39. > Yes, but the problem is in what is restored by the called function...
  40.  
  41. No, that is not a problem.  The unlink instruction will return everything to
  42. normal when the routine ends.
  43.  
  44.  
  45. An example is given (most of which is now deleted):
  46. > f2()
  47. > {
  48. >     register int b;
  49. >     char *p;
  50. > 
  51. >     b = 7;
  52. >     p = alloca(10);
  53. >     return(b);
  54. > }
  55.  
  56. And the approximate assembly code:
  57.  
  58. > f2:
  59. >     link.l    %a6,-4        # create stack frame
  60. >     mov.l    %d2,-(%sp)    # save regsiter variable
  61. >     mov.l    &7,%d2        # set b to 5
  62. >     pea.l    10        # parameter to alloca
  63. >     bsr    alloca        # call alloca
  64. >     add.w    &4,%sp        # pop argument to alloca
  65. >     mov.l    $d0,-4(%a6)    # store alloca return in p
  66. >     mov.l    %d2,%d0        # return value
  67. >     mov.l    (%sp)+,%d2    # restore register variable **************    
  68. >     unlk    %a6        # remove stack frame
  69. >     rts
  70.  
  71. All of the saved parameters, passed parameters, and local variables are accessed
  72. via the frame pointer, not the stack pointer.  Your line marked "**************"
  73. should use %a6.  (Actually, what will happen is the link instruction is given
  74. a mask telling it which registers to save.  Neither your save %d2, nor restore %d2
  75. will be generated by the compiler.  The Unlink instruction will restore the
  76. proper registers from the stack, again using %a6 not %sp.)
  77.  
  78. Everything will work out just fine.  The Unlink will also restore the stack
  79. pointer to its proper value before calling alloca.
  80.  
  81. > Anyone disagree with my analysis?
  82.  
  83. Yes.
  84.  
  85. Tom Tkacik
  86. GM Research Labs
  87. tkacik@hobbes.cs.gmr.com
  88. tkacik@kyzyl.mi.org
  89.  
  90.