home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.asm.x86      Ahh, the lost art of x86 assembly      4,675 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 3,572 of 4,675   
   Rick C. Hodgin to R.Wieser   
   Re: EXE program stack setup questions   
   10 Oct 18 14:47:59   
   
   From: rick.c.hodgin@gmail.com   
      
   On 10/10/2018 12:57 PM, R.Wieser wrote:   
   > On 10/08/2018 Rick C. Hodgin wrote:   
   >> Your stack is setup properly here.  It's setup to the   
   >> top of the 64KB block by default   
   >   
   > I think your definition of "properly" and mine differ a bit here.   The   
   > resulting stack space is than *way* larger than it needs to be.  For no   
   > reason at all.   
      
   It's not for no reason.  DOS automatically allocates the full   
   64KB block to TINY memory model apps.   
      
   Even if you resize your stack, the memory control blocks have   
   been allocated to give you all of memory (I would double-check   
   that with an AH=4Ah, BX=0FFFFh, INT 21h function call.  It will   
   fail, but it will return the maximum paragraphs available in   
   BX.   
      
   You can see how much is initially allocated to your app in DOS.   
   I know .COM files received it all.  I'm pretty sure TINY model   
   .EXE files did also, but it's been ~25 years since I've done   
   regular DOS programming in assembly.  My memory could be failing   
   me.  I could be wrong.   
      
   >> giving you the max amount of space for your stack without entering a new   
   >> model that is no longer TINY.   
   >   
   > Actually, that is the question I started this thread with : Is there   
   > a(nother) way to declare stack in a way where SS stays the same as CS, and   
   > only SP changes - or a method which does not clash with using local   
   > variables and so on (which you have solved).   
      
   Yes.  Just set it that way.  SP will wrap to 0xfffe right now,   
   which is the top of the 64KB block relative to whatever CS=DS=   
   ES=SS is at startup, so you just need to MOV SP,Nnnn where that   
   value Nnnn is the correct size you need for your stack space   
   plus your existing code + data size.   
      
   >> The size of your stack is 64 KB - actual code size,   
   > Which is, as far as I'm concerned, *way* to big.   
      
   Out of curiosity, why is this too big?  It would only be an   
   issue if you're allocating memory later, or if you are making   
   a TSR program, then you'd need to manage memory carefully,   
   but in such a case you'd have all kinds of tricks up your   
   sleeve to prevent the stack from overflowing by your needs   
   running atop another app's existing needs, etc.   
      
   > As long as I do not put random data structures on the stack and stay away   
   > from recursion I can probably do with less than a single KByte.   
      
   Then all you need to do is find out how big your .EXE code +   
   data is in memory, which you can probably do by using two   
   OFFSET values, one at the start of everything, one at the end,   
   and then subtracting.   
      
   >> I've haven't used TASM / TLINK enough to remember, but   
   >> IIRC it reports the actual code size generated, either   
   >> by default, or by a flag / option that will report it.   
   >   
   > Nope.   Neither show such an option, nor do they display it by default.   
   > But its easy enough to get it from the EXE header   
      
   You'll have to generate a listing then and look at that,   
   and then set it up in two assembles.   
      
   > Strike that: I need that extra program anyway, to fix the max ammount of   
   > requested memory.  There seems to be no dependable way to figure it out   
   > inside the program.   
      
   The AH=4Ah, INT 21h resize memory might tell you how bit   
   it is if the EXE loader only allocated enough memory to   
   hold the code + data, and you're out there in la la land   
   with the stack.   
      
   It would require some research / checking.  I have an IBM   
   PC DOS 7-based 486 that I was doing some development on   
   recently.  It has TASM/TLINK on it, but I haven't used it   
   very much.   
      
   If you're still stuck, I'll break it out and see if I can't   
   figure out how to determine it reliably at startup.   
      
   --   
   Rick C. Hodgin   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca