home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / 3b1 / 3310 < prev    next >
Encoding:
Text File  |  1992-09-08  |  3.6 KB  |  89 lines

  1. Newsgroups: comp.sys.3b1
  2. Path: sparky!uunet!digibd!steve
  3. From: steve@digibd.com (Steve Wahl)
  4. Subject: Re: Lack of libPW.a module
  5. Organization: DigiBoard Incorporated, Eden Prairie, MN
  6. Date: Tue, 08 Sep 1992 20:58:23 GMT
  7. Message-ID: <1992Sep08.205823.22770@digibd.com>
  8. References: <89582@rphroy.ph.gmr.com>
  9. Lines: 78
  10.  
  11. =======================================================================
  12. The short story for those who don't want to read the whole thing: I
  13. was wrong, on the 3B1 you don't have to worry about register variables
  14. conflicting with alloca() (I made a mistake generalizing what I knew
  15. about a different archetecture).  You still have to worry about
  16. complex uses of alloca() - for the record I never disagreed with that.
  17. =======================================================================
  18.  
  19. In article <89582@rphroy.ph.gmr.com> tkacik@hobbes.hobbes.cs.gmr.com writes:
  20. >In article 4632@digibd.com, steve@digibd.com (Steve Wahl writes:
  21. >> I don't think anyone understands me yet.  First, some context.
  22. >> 
  23. >> In article <1992Aug29.052011.24352@colnet.cmhnet.org> res@colnet.cmhnet.org (Rob Stampfli) writes:
  24. >> >In article <1992Aug27.213851.20578@digibd.com> steve@digibd.com (Steve Wahl) writes:
  25. >> >
  26. >> >>   [ don't use alloca() with register variables ]
  27. >
  28. >All passed parameters and local variables will be ahead of the alloca'd
  29. >space, and will be accessed via the frame pointer (%a6) rather than the
  30. >stack pointer (%sp aka %a7).  Only temporary variables are accessed via
  31. >the stack pointer.
  32.  
  33. This is the part I didn't remember correctly; I've been working on a
  34. different, little-endian archetecture ( guess :-) ) lately that DOES save
  35. and restore the register variables via the stack pointer rather than the frame
  36. pointer (well, the compilers we use do this, anyway...), and I thought
  37. I remembered the 68010 compiler doing the same thing.  Andy Fyfe also
  38. pointed out this error to me.
  39.  
  40. >
  41. >All of the saved parameters, passed parameters, and local variables
  42. >are accessed via the frame pointer, not the stack pointer.  Your line
  43. >marked "**************" should use %a6.  (Actually, what will happen
  44. >is the link instruction is given a mask telling it which registers to
  45. >save.  Neither your save %d2, nor restore %d2 will be generated by
  46. >the compiler.  The Unlink instruction will restore the proper
  47. >registers from the stack, again using %a6 not %sp.)
  48.  
  49. Now, after I stuck my foot in my mouth last time, I don't want to
  50. sound so sure of myself this time.  But I don't remember link and
  51. unlink being able to save or restore registers.  Link takes two
  52. parameters, the frame pointer and an offset to add to the stack
  53. pointer for allocating local stack space.  The unlink instruction
  54. takes one parameter, the frame pointer.  I believe if you really
  55. examine the code ouput by the compiler, you will find two movem
  56. instructions, one after the link and one before the unlink, that take
  57. care of saving and restoring registers.  As a matter of fact, this is
  58. the compiler output Andy showed me:
  59.  
  60.         set     S%2,-4
  61.         set     T%2,-8
  62.         set     F%2,-12
  63.         set     M%2,0x0004
  64.         text
  65. f2:
  66.         link    %fp,&-12
  67.         movm.l  &0x0004,S%2(%fp)
  68.         mov.l   &7,%d2
  69.         mov.l   &10,%d0
  70.         mov.l   %d0,(%sp)
  71.         jsr     alloca
  72.         mov.l   %d0,%a0
  73.         mov.l   %a0,-4+S%2(%fp)
  74.         mov.l   %d2,%d0
  75.         movm.l  S%2(%fp),&0x0004
  76.         unlk    %fp
  77.         rts
  78.  
  79. This, of course, is a completely separate issue, and the compiler
  80. still works as advertised...
  81.  
  82. --> Steve
  83.  
  84.  
  85. -- 
  86. Steve Wahl               steve@digibd.com
  87. Digi International, Inc.
  88. Eden Prairie, MN         (612) 943-5387
  89.