Hello Stas, First of all I'm sorry for my general non-responsiveness, I've just been busy in general.
> 3. Make a fully functional dosaddr_to_unixaddr(), not just > a quick hack it currently is. It should use the proper reverse-mapping > maintained by mapping.c, instead of relying on a "map_char". > > I think the most "correct" approach is 3. I agree. > Then, if this is fixed, I think all the uses of LOWMEM() should > be killed, except those intended initially: for the use by the mappers. > No one, except "mappers", should use LOWMEM(). Fortunately, > the uses of LOWMEM() are already very few in the code. The problem is as follows: the reason why LOWMEM is used, is that DOSEMU needs to write to DOS memory, on pages that are potentially write-protected by the CPU emulator. Most of these writes involve just data, and it's expensive to unprotect, than write, and then again protect the page: an alias is cheaper. Some writes (mainly disk reads by int13 and the mfs, and xms transfers) may actually involve code. That's one place where e_invalidate() comes in -- the other places are where the memory is potentially outside the non-aliased conventional memory range, which is why e_invalidate() is also in dpmi.c. (In total I counted 6 or 7 e_invalidate() calls, which doesn't look so excessive to me). If neither the alias nor invalidation is used, DOSEMU page faults, which is then corrected by the CPU emulator, much like an exception that is caught, that is, an expensive way of doing things. These exceptions are logged in boot.log. The LOWMEM alias is mostly useful for BIOS data area writes though, and for that you'd only need a 4K alias of the first page, that is guaranteed to contain both frequently used DOS code, the IVT and the BIOS data area. looking at the code again: lowmemp(ptr) can actually be coded like this: return LINEAR2UNIX((unsigned char *)ptr-mem_base); it maps a *Linux* pointer to the equivalent address in the aliased r/w low memory if it exists, and otherwise it just returns ptr. When I adjusted the DOSEMU code to work with non-zero mem_base I tried to make sure that every time you have a pointer it is the actual Linux address. A DOS address like 0xb8000 is stored as an unsigned int, never explicitly as (void *)(0xb8000); when stored as a Linux pointer it is stored as p=&mem_base[0xb8000]. > But the good thing is that the aforementioned multitasker > works under (patched) dosemu even on x86_64. I am surprised > with how mature the CPU emulator is; it was barely usable > the last time I looked. :) I think KVM also has the CPU emulator > builtin. Was this considered as the speedup? I haven't looked a lot at KVM's CPU emulator, I think it is not a JIT emulator, but interpretative with some tricks to speed up flag handling. Most of the bugs in the CPU emulator were gotten rid of by using QEMU's test program and various fixes from Reinhard and Michael Karcher. And I sped up the FPU emulation by having it use the real FPU stack, so most of the FPU instructions could simply be copied for the JIT. I hope to have a more detailed look at your patch later -- it looks promising. Bart ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Dosemu-devel mailing list Dosemu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dosemu-devel
