From: address@nospicedham.not.available   
      
   Rick,   
      
   > The value there for SP is probably correct.  It will   
   > wrap to 0xfffe on the first use, which will place it   
   > at the top of the 64 KB block of memory in use.   
      
   I think I also mentioned that, not sure anymore if it was to Alexei or you.   
   And yes, it will work.  But no, it isn't acceptable.    I don't want a 64   
   KByte block occupied when the full program uses (way) less than that.   That   
   is why I got this thread started :-)   
      
   > If you needed to adjust your stack manually you would re-define your main   
   > function to be a tiny little bit of code that doesn't have local local   
   > storage, but simply fixes up the stack, and then issues a JMP to your real   
   > "main" program, which you could call "main2" or something.   
      
   Shucks.  I have used that "trick" on other occasions, but I didn't think of   
   it here.   Yes, that would do the job quite nicelyl.   
      
   > which it does not look like you need to do   
      
   The need is ofcourse relative.   But as I'm also trying to limit the   
   programs memory hunger (setting "max_extra_paragraphs" (its currently   
   0FFFFh) to "min_extra_paragraphs" I also need to reign-in the stackpointer a   
   bit.   
      
   > 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.   
      
   > 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).   
      
   > The size of your stack is 64 KB - actual code size,   
      
   Which is, as far as I'm concerned, *way* to big.   
      
   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.   
      
   > 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   
      
   Which by the way I've been tinkering with, both to quench the programs   
   memory hunger, as well as for a non-stack program adjusting SS:IP to match   
   CS:{size of memory image}, or, when a stack is defined (".stack {size}"),   
   move SS back to CS and adjust IP accordingly up.  Seems to work well.   
      
   Though your "adjust it at entrypoint, than jump to the actual  main   
   procedure" has a better ring to it (no extra program shennigans needed).   
      
   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.   
      
   Regards,   
   Rudy Wieser   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)