Mail Archives: djgpp/2003/02/11/09:45:15
>
> Please do not toppost. RDTSC will cause a bad opcode trap on a
> 486, or a 386, both of which are suitable processors for the DJGPP
> system. Bad idea.
>
My idea is that the uclock() checks whether rdtsc is available when it is
first called. And, if it's available the use it. If it's not, don't.
First, check the existence of cpuid. If it does not exist, then the tsc does
not exist, so go to the normal pit routine. If cpuid does exist, then use it
to determine the existence of the tsc. If it does not exist, then go to the
normal pit routine. If the tsc does exist, then check for the existence of
cr4. If it exists, then check the setting of the tsd (Time Stamp Disable)
bit (bit 2). If it is set, then go to the normal pit routine, as the tsc has
been disabled for all but cpl=0. If the tsc has not been disabled, then time
the cpu to determine the ratio between the cpu speed and the pit speed,
store that ratio in a global variable, and set a flag signalling that rdtsc
is available.
Then, on each subsequent call of uclock(), it can either read the tsc and
divide by the cpu/pit ratio, or get the standard pit + bios time, depending
on the "rdtsc available" flag.
Now, the only case when the tsc would be unavailable under Windows XP would
be when WinXP specifically disables access to the tsc, as Windows XP will
only run on a Pentium class or better cpu. (Do you know of any 486's that
run at 233MHz?)
- Raw text -