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,563 of 4,675   
   R.Wieser to All   
   Re: EXE program stack setup questions   
   08 Oct 18 09:06:50   
   
   From: address@nospicedham.not.available   
      
   Rick,   
      
   > I don't understand.   
      
   You don't *have* to.   You just have to accept that those are the facts, and   
   work from there.   
      
   If you want I can provide you with the values of all the registers you want,   
   but those will just support what I've been saying.   If you want me to add   
   specific pseudo-ops to my code to see what the result is than I can   
   accomodate you too.   
      
   > I think that's an error in the loader,   
      
   If you mean by "loader" the program that actually loads the program than   
   thats XPsp3.   
      
   > or there's some startup code being injected by TASM to handle some kind of   
   > "fixup" at startup.   
      
   Shouldn't you just ASK ?   
      
   FYI: Tasm doesn't inject such code.   Its an *assembler*.   And yes, just to   
   make *very* sure I took another peek.   The code is exactly as I wrote it.   
      
   But, I've added some .LST file output at the end, together with some   
   register values.   Maybe that will allow you to understand.   
      
   > If I recall correctly, you can set it up that way manually   
   > (from memory, untested):   
      
   In other words, just point it about 64KB away from the start of the program,   
   regardles of if that memory is actually owned by the program ?     Don't you   
   think that that would be a stupid thing to do ?   
      
   Besides the point that in the parent of the message you first responded to   
   I've put some code to show why such a simple solution would create a problem   
      
   And here we go *again* : because stuff has already been put on the stack   
   (like local storage), resulting in both BP and SP being altered/in use.   
      
   I described that in the first message (go read it!), in an attempt to   
   pre-empt exactly the song-and-dance you and I are now doing. :-(   
      
   Regards,   
   Rudy Wieser   
      
   -- 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   
      
   -- 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.   
      
   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)   
      
   --- 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