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