> 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
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).
- 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
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.
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.
Freedos-user mailing list