winedos / Speed up RM software interrupt handling

[Ove Kaaven]

søn, 2003-03-16 kl. 19:25 skrev Jukka Heinonen:
> Well, an educated guess would be that SEH is going to be 10-100 times
> slower than direct function call, even if the implementation was
> optimal. However, this would be acceptable. Unfortunately, Wine SEH
> handling makes a server call in order to notify debugger and I suspect
> this is what makes SEH slow (using SEH also makes running DOS programs under
> winedbg hard, but this is most likely because I don't know how to make
> winedbg ignore VM86 exceptions).

Perhaps that could be avoided if, when a debugger is attached, the
appropriate TEB entry is written to (as in Windows) using ptrace or
something, and such server calls are only done if that TEB entry is
present.

> It is likely that I shall not try to change the mechanism from SEH to
> something faster because it is not a particularly interesting problem.
> It would improve the performance of real mode DOS programs, but
> I guess I have more important things to do. However, I think replacing
> SEH would be much easier than you believe. As far as I understand
> it, something like the following would be enough:
> 
> * Replace custom vm86_enter with glibc vm86 function. 
> * Make set_vm86_pend to return immediately if context is in VM86
>   (vm86 syscall will automatically return with return value of VM86_SIGNAL). 
>   If, instead teb->vm86_ptr is set and interrupts are enabled, push CS/IP to 
>   stack and replace them with pointer to real mode stub that does "sti and ret".
>   This makes vm86 return with VM86_STI.
> * Make __wine_enter_vm86 check after return from vm86 that CS/IP does not 
>   point to stub defined above. If this is the case, just pop old CS/IP from stack.
>   This fixes race if signal is received during return from vm86 and before
>   teb->vm86_ptr is cleared.
> * Add some mechanism (return or direct call) to __wine_enter_vm86 for handling
>   software interrupts and pending events (this is unlikely to make the function
>   more than a few lines longer).

But I was talking about interrupts in DPMI protected-mode. I was already
sure that exceptions could be easily avoided in real-mode, the only
reason I used them in the first place was because that's how Alexandre
seemed to like it (he had set it up like that in his original winedos
separation patch, which I then based my own winedos separation work on).
Protected mode is a much harder beast to deal with if set_vm86_pend
isn't supposed to know about DPMI directly.