Hi Michael, > Many illegal memory accesses in programs which won't fail under HIMEM will > fail with EMM386 loaded. EMM386 does not allow memory reads/writes outside > of the actual PC memory range due to protected mode /V86...
You forget that the MEMCHECK switch for your EMM386 fixes this, by allowing int 15.87 memory access to anywhere, even non-RAM space :-). I think other ways to access memory, like XMS, do fail when you try out-of-range accesses even if EMM386 is not loaded. So MEMCHECK should really make a difference. More people should try it. Other EMM386 things from the last 12 hours: > Certainly true that VCPI provides discrete allocations in 4K units... Yes, in fact, the int 67.de04 call always allocates exactly ONE page! The current implementation scans a whole array of "4k page used" bits, avoiding all "completely used" and "completely free" 16k aligned 16k pages, to keep as many EMS pages useable as possible. While being very nice to EMS performance that way, you get quite bad VCPI performance. As you can have up to 64k pages (more if you add saturation to the "number of total free pages" reporting - then you have up to 64k pages per each of up to 250+ handles), each 16k in size (EMS pages), your bit string can be up to 32 kBytes in size... Well, could be. I see you limited VCPI alloc to 511 MBytes -> Bit string is up to 16 kBytes. Can be pretty slow to parse! I would recommend that you add some "bookmark" variables: - pointer to a 16k page of which already 4-12k are already in use for VCPI. (e.g. a bit number inside the VCPI_Tracking array). When the bit number test 3 is nonzero, just alloc the 4k and set the bit. Only when the bit number test 3 is zero, you first have to find a fresh 16k page. Fragmentation might be an issue here: If you dealloc some but not all 4k pages of a 16k page, only the OLD algorithm would reuse them. HOWEVER, you can make the bookmark point to the most recently freed 4k page to solve that (NOTE: You have to add an extra check to the "just alloc the 4k and set the bit" part, to see whether the bit was already set, and if so, scan for a free bit). alternatively - pointer to the first byte in the array where any free space can be found. Just reset it whenever any memory is deallocated. You still save a lot of scanning time by avoiding the "scan from the start" case very often. I hope you like those optimization ideas :-). If not, you can at least replace the "mov al,[esi] / cmp al,0ffh / je va_next / ... / va_next: inc esi / loop back" part by something like: "mov al,0ffh / repz scasb [esi] / jz fail / va_checksubs2: lodsb / compare al to 0, 0f, f0 and ff, and if neither, jump to success / else jump to va_next: loop back". That speeds up the initial scan through fully allocated ranges (notice that I check for ZERO first in the second part, as most of the end of the array will be fully unallocated). Aligning the scan code to 4/8/16 byte boundaries can give a performance improvement as well. Eric PS: About VME, if you add it, you would just activate it when you detect a VME-enabled processor. The int redirection bit field will have constant contents - redirect ALL except exceptions, IRQs and int 67h, that is. VCPI clients which reroute IRQs are not supported by current EMM386 implementation anyway, as the "is this interrupt an IRQ" check uses constant "8-f, 70-77 are IRQs" logics. (Not sure about whether it would be even okay to default to redirect 70-77 to the v86 task all the time, and what the int 13/40/4b settings for the bit map would be, but still, the bit map would be QUITE constant, and if you handle a few ints in software which could have been handled by VME directly, it will not hurt much either...) PPS: Arkady wrote that QEMM has switchable VME support. So it would be a good idea if some QEMM user could check the performance impact of switching VME on/off :-)). Some sound / mod players are for example quite I/O and IRQ heavy. Hint hint. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
