From: nowhere@never.at   
      
   R.Wieser wrote:   
      
   > Wolfgang,   
   >> yes, of course your near CALL needs two bytes anyway   
   > You have not really looked at my code, haven't you ?  :-(   
      
   already posted a reply but cant see it yet:   
      
   I saw that you fiddle the return into... so yes this are only   
   6 byte on stack, but your code access the stack eight times,   
   which I see as a waste in size and speed, just to save one   
   byte for the return and two bytes on stack.   
      
   what's your reason to have only 6 instead of 8 ?   
      
   but you seem to insist on it, so how about this:   
      
   int_n:   
   2e 8f 06 xx xx   pop [cs:int_n+0x0c]  ;reduce stack usage   
   eb 02 90 90      flush queu ;just in case for older CPU SMC   
   9c               pushf      ;these three needed for the IRET   
   0e               push cs    ;   
   68 xxxx          push imm   ;return address goes here by SMC   
   fa               cli   
   EA xxxx xxxx     jmpf imm   
      
   20(16) byte, no regs altered, 6 stack bytes and 4 times stack access.   
      
   your 26 bytes:               ;I checked in detail   
                                ;bp+6 is your return   
   50       push ax             ;bp+4 = ax   
   9c       pushf               ;bp+2 = fl   
   fa       cli   
   55       push bp             ;bp+0 = bp   
   8b ec    mov bp,sp   
   8b 46 02 mov ax,[bp+WORD*1]  ;swap RET with Flags   
   87 46 06 xchg ax,[bp+WORD*3] ;bp+6 = flags   
   89 46 02 mov [bp+WORD*1],ax  ;bp+2 = RET   
   8c c8    mov ax,cs   
   87 46 04 xchg ax,[bp+WORD*2] ;bp+4 = CS   
   5d       pop bp              ;OK, it's in correct order   
   ea xxxx xxxx  jmpf imm   
      
   the SMC will cause a speed penalty, but it's shorter and may be faster   
   than a xchg stack fiddler (depending on CPU-version).   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)