From: rick.c.hodgin@gmail.com   
      
   On 10/8/2018 3:06 AM, R.Wieser wrote:   
   > -- Code example, stack defined, no stack-based storage   
   >   
   > 17     0000    Main proc   
   > 18     0000  2E: 8C 0E 00D0r   mov  [cs:OldCS],cs   
   > 19     0005  2E: 8C 16 00D2r   mov  [cs:OldSS],ss   
   > 20     000A  2E: 89 26 00D4r   mov  [cs:OldSP],sp   
   > 21     000F  2E: 89 2E 00DEr   mov  [cs:OldBP],bp   
   >   
   > CS=0DD4 SS:SP=0DD4:0000 BP=091E   
      
   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.   
      
   You can verify this by inserting a line there between   
   17 and 18.  Add a PUSH AX and then read what those   
   values are.  It should be set to 0DD4:FFFE if you do   
   this.   
      
   It isn't that the stack isn't there, it's just using   
   the automatic wrapping features of the 16-bit regs in   
   this CPU model.   
      
   > -- Code example, no stack defined, with stack-based storage   
   > 17     0000    Main proc   
   > 18       local  @@Data[6]:BYTE   
   > 19   
   > 20     0000  C8 0006 00    ENTERW  00006h,0   
   > 21     0004  2E: 8C 0E 00D4r   mov  [cs:OldCS],cs   
   > 22     0009  2E: 8C 16 00D6r   mov  [cs:OldSS],ss   
   > 23     000E  2E: 89 26 00D8r   mov  [cs:OldSP],sp   
   > 24     0013  2E: 89 2E 00E2r   mov  [cs:OldBP],bp   
   >   
   > CS=0DD4 SS:SP=0DD4:FFF8 BP=FFFE   
   >   
   > In this code fragment you can see the local storage definition at line 18,   
   > and the emitted code for it at line 20.  The first actual instruction I've   
   > written is now at line 21.   
      
   If you needed to adjust your stack manually, which it   
   does not look like you need to do, 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.   
      
   > And please do compare the SP and BP contents of both fragments.   Also   
   > notice that, in the first code sample, SP is actually *zero* when no stack   
   > has been defined (and accordingly adjusted in the second code sample)   
      
   That 0000 value uses the knowledge of how the x86 stack   
   works, and how it will overflow back to 0xfffe on the   
   first use.   
      
   SS:SP = 0DD4:0000 to start out with.  Once you have an   
   ENTER 6,0, it will PUSH BP, setup a stack frame with   
   a MOV BP,SP, and then SUB SP,6.  What you see there   
   is the stack being setup to 0DD4:FFFE (which is what   
   I told you to set it to manually, but I can see now   
   you don't need to do), resulting in the stack looking   
   like this.   
      
        0DD4:FFFE - [old BP value]   
        0DD4:FFFC - ;   
        0DD4:FFFA - ; 6 bytes of local storage   
        0DD4:FFF8 - ;   
      
   Your local stack data is now accessible at [bp-2]   
   for the bytes at 0DD4:FFFC to 0DD4:FFFD, [bp-4] for   
   the bytes at 0DD4:FFFA to 0DD4:FFFB, and [bp-6] for   
   the bytes at 0DD4:FFF8 to 0DD4:FFF9.   
      
   Your stack is setup properly here.  It's setup to the   
   top of the 64KB block by default, giving you the max   
   amount of space for your stack without entering a new   
   model that is no longer TINY.   
      
   The size of your stack is 64 KB - actual code size,   
   which your assembler and/or linker should be able to   
   tell you.   
      
   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.   
      
   --   
   Rick C. Hodgin   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)