12.11.2012 06:50, Eric W. Biederman пишет: > Originally we used to take a fault on any vga memory access that might > need emulation and the go back into vm86 mode. With the enhancement of > instremu to handle all of the instructions allowing us to run several > instructions and if we were in a loop to avoid taking multiple faults at > once the weird cga, ega, and vga modes went from unusable under X on a > 700Mhz 486 to a something that worked. I was also thinking about instremu.c as just an optimization. Bart is trying to convince me now however that this is an essential and unavoidable thing. That you can't use a fault approach at all. And I think he is succeeding with that. Please see the nearby replies.
> I also remember there was a lot of work put in to avoid having to fault > in the pages. So I would be surprised if there were missing > opportunities. If PROT_WRITE would work without PROT_READ, then there is a possibility to still avoid most of the faults. The problem Bart points, is that it doesn't work on x86, so the fault-based implementation is simply not even possible. :( > I don't know how the code is structured today or how cpuemu works, but > if I was to design it from scratch the way I would put the code together > is: > > - A slowpath emulator that can handle all of the weird case and fill in > where vm86 mode, running on the native cpu, or anything else falls > off. > > - A fast path jit (cpuemu?) that would emulate instructions by > converting them into native code, and would ensure there is an > appropriate fault on unhandled cases so that the slowpath emulator > could handle the issue. That's pretty much what it does now (AFAIK), except that simulating the generated code looks a bit weird. At least theoretically it can use the instructions that the DOS code does not use. > With that split it would be possible to just let the slowpath emulator > handle the vgaemu case. It still might make sense to bring the > optimization of weird memory accesses into a jit but it would not be Looks like that's what Bart wants to implement, which is fine, but complex and has bugs (already had). That's exactly where the vgaemu hooks are starting to spread itself into cpuemu, and I thought something cleaner can be done. > But the property of avoiding page faults through emulating hundreds of > instructions in a row in the slow path emulator still seems to be a very > good idea. At least for debugging purposes it might be a good idea to quickly disable that, to see if the problem is not in that decoder. instremu.c had many bugs too. So it might be good to still have a fault-based technique at hands, but maybe it is completely impossible, as it seems now. So if you know some way to use the fault-based approach (even in a slow way), please post it here. :) ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov _______________________________________________ Dosemu-devel mailing list Dosemu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dosemu-devel
