Hi,

> >Thanks. Could you, instead of sending a cookie, include RDTSC emulation
> >in that version?

> RDTSC isn't flagged a privileged instruction at boot-up.  If it is 
> explicitly set privileged later, then EMM386 shouldn't bypass that.

Not really. RDTSC is allowed from ring 0 and from real mode, but the
CR4 TSD bit can block it for lower priv protected mode tasks. The
problem is that this bit does NOT have any effect (even though the
documentation tells that it should) on v86 tasks. The RDTSC command is
always disabled in v86 tasks for at least Pentium 1 and K6-2 CPUs,
and the only way to use RDTSC in a DOS program (apart from running the
whole program in protected mode with a DOS extender) turns out to be
adding RDTSC emulation to EMM386.

Do not ask me why CR4 TSD does not work for v86 tasks on some CPUs.
Maybe because it felt as sensitive as cli/sti/hlt for the people who
designed that CPU? Anyway. Adding emulation to EMM386 will be easy,
and "you must not load EMM386 if you want to use RDTSC" is not nice.

> >will help to avoid stupid user questions like "I used FD EMM386 with the
> >HIMEM of MS Win3.1 and now I have only 128k of EMS free?" ;-) ...?
...
> ... And if they are a stupid user, a 4309 message would be utterly 
> meaningless to them.

I meant more something like "your HIMEM is too old, switching to fixed
allocation mode" (auto-activating emm=X where X is a power of 2 and
e.g. the biggest power of 2 which is at most half of the amount of free
XMS at that moment). Would cause a comfy feeling for those users who
followed (outdated, but some users do not realize that) instructions to
use the "right" version of HIMEM for their program.

Alternatively, the message can be "your HIMEM is too old, emm386 will
not work, you are a stupid user who forgot to update HIMEM". Any
message will be better than just entering pool sharing mode with an
incompatible HIMEM and punishing the user by not giving him more than
a little bit of EMS without telling him why it happens to him.

Eric

PS: Nice that EMM386 emulates MOV from/to CR4. That way I could verify
that CR4 TSD somehow fails to configure RDTSC for v86 tasks. As your
EMM386 does not modify CR4 afaik, and as RDTSC failed for somebody else
(who has the Pentium 1) if and only if emm386 is on, I have to conclude
that the CR4 TSD bit does not control v86 tasks on some CPUs...



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Reply via email to