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,635 of 4,675   
   Terje Mathisen to R.Wieser   
   Re: Indirect INT calling   
   29 Oct 18 21:13:15   
   
   From: terje.mathisen@nospicedham.tmsw.no   
      
   R.Wieser wrote:   
   > Terje,   
   >   
   >> Adding 10-100 patch locations in order to save a single word of   
   >> stack space?   
   >>   
   >> "You gotta be kidding!" :-)   
   >   
   > I think you misunderstood.  I was expressing my preference for a   
   > single procedure (with a singe to-be-patched byte) which gets called   
   > instead of any INT 0x60.   
   >   
   > But now you mention it, creating a patching framework just to save a   
   > single stack save does sound a bit exessive, doesn't it ?   
   >   
   > On the other hand, I *did* ask for possible other solutions, and that   
   > it certainly is. :-)   
   >   
   >> Before calling a driver which switches to a private stack anyway?   
   >   
   > :-)  That is for thr SIS900 packet driver. I cannot say anything   
   > about others.  They might, but they also might not.   
   >   
   > Hmmm...  I'm rather sure that with some stack shennigans I could   
   > change the stackframe of a simple near call of a procedure into a   
   > push-and-far-return, needing only the far jump to the INT procedure   
   > ...   
   >   
   > I'm not sure I would actually want to use it though ... (too hackish)   
   > :-)   
      
   You would definitely NOT want to use it unless you really have to:   
      
   proc trampoline   
   ; Assumes calling parameters in any register, INT xx address stored in   
   ; static code segment location   
      
      push ax   
      push bp   
      mov bp,sp   
      pushf   
      cli   
      push cs   
      mov ax,offset return_address   
      push ax   
      pushf   
      mov ax,[cs:int60+2]   
      push ax   
      mov ax,[cs:int60]   
      push ax   
      mov ax,[bp+2]	;; restore AX   
      mov bp,[bp]	;; restore BP   
      iret   
      
   return_address:   
      add sp,4   
      ret   
   endp   
      
   I.e. setup the stack so that an IRET makes the far call to the INT60   
   handler, and when that function does its IRET we get back   
      
   If we have a spare register then it becomes possible to do this with   
   zero stack overhead, or we can use more complicated code to achieve the   
   same:   
      
      sub sp,10	;; Room for two IRETs including the caller's return   
      push bp   
      mov bp,sp   
      push ax   
      
      mov ax,[bp+12] ;;  Calling routine   
      mov [bp+8],ax   
      pushf   
      pop ax   
      CLI   
      mov [bp+12],ax   
      mov ax,cs   
      mov [bp+10],ax   
      pushf   
      pop ax   
      mov [bp+6],ax   
      mov ax,[cs:int60+2]   
      mov [bp+4],ax   
      mov ax,[cs:int60]   
      mov [bp+2],ax   
      
      pop ax   
      pop bp   
      iret   
      
   With this setup there is zero extra stack space in use, all registers   
   are available for input/output, and the driver IRET returns directly to   
   the (near) location that called this trampoline!   
      
   Terje   
      
   --   
   -    
   "almost all programming can be viewed as an exercise in caching"   
      
   --- 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