From: nowhere@never.at   
      
   R.Wieser wrote:   
      
   > Wolfgang,   
   >> no registers in use, ten bytes code, four byte data and 6 bytes stack   
      
   > My apologies, but thats 8 bytes stack: The my_return RET address needs   
   > to go somewhere too   
      
   yes, of course your near CALL needs two bytes anyway, I just counted   
   the addon. And you may not find a solution with lesser stack usage   
   except callee code modification (copy it and make it a near routine).   
      
   > That was the whole idea of my code, not having, while calling the INT   
   > procedure, more on the stack than a regular INT would have [1].    And   
   > although I'm not sure if there would actually be a valid use case, that way   
   > even stack-based arguments (C style, popped by the caller) would keep   
   > functioning.   
      
   > [1] otherwise the regular "INT {byte value}", "RET" sequence wins   
   > hands-down. :-)   
      
   an INT_n followed by a near RET will ALWAYS abuse 6+2 byte on stack :)   
      
   > And although my code does use registers, the ones that go into the   
   > code are the ones the INT procedure is called with.   
      
   what I posted saves on register preserve, it's short and would work   
   within C-styled frames as well (you might insert a CLI before jmpf).   
      
   what's the problem with two more temporary bytes on stack ?   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)