[DOSEMU Logo]
DOSEMU.org

| Home | | Developer Releases | | Stable Releases | | Documentation |

Home
README
Technical README  - 0.97.10
HOWTO
DANG
EMUfailure
Misc
Next Previous Contents

13. Pentium-specific issues in dosemu

This section written by Alberto Vignani <vignani@mbox.vol.it> , Aug 10, 1997

13.1 The pentium cycle counter

On 586 and higher CPUs the 'rdtsc' instruction allows access to an internal 64-bit TimeStamp Counter (TSC) which increments at the CPU clock rate. Access to this register is controlled by bit 2 in the config register cr4; hopefully under Linux this bit is always off, thus allowing access to the counter also from user programs at CPL 3.

The TSC is part of a more general group of performance evaluation registers, but no other feature of these registers is of any use for dosemu. Too bad the TSC can't raise an interrupt!

Advantages of the TSC: it is extremely cheap to access (11 clock cycles, no system call).

Drawbacks of using the TSC: you must know your CPU speed to get the absolute time value, and the result is machine-class specific, i.e. you can't run a binary compiled for pentium on a 486 or lower CPU (this is not the case for dosemu, as it can dynamically switch back to 486-style code).

13.2 How to compile for pentium

There are no special options required to compile for pentium, the CPU selection is done at runtime by parsing /proc/cpuinfo. You can't override the CPU selection of the real CPU, only the emulated one.

13.3 Runtime calibration

At the very start of dosemu the bogospeed() function in base/init/config.c is called. This function first looks for the CPUID instruction (missing on 386s and early 486s), then looks for the CPUSPEED environment variable, and at the end tries to determine the speed itself.

The environment variable CPUSPEED takes an integer value, which is the speed of your processor, e.g.:

    export CPUSPEED=200

The last method used is the autocalibration, which compares the values of gettimeofday() and TSC over an interval of several hundred milliseconds, and is quite accurate AFAIK.

You can further override the speed determination by using the statement

    cpuspeed div mul
in your configuration file. The integer ratio (mul/div) allows to specify almost any possible speed (e.g. 133.33... will become '400 3'). You can even slow down dosemu for debugging purposes (only if using TSC, however).

The speed value is internally converted into two pairs of integers of the form {multiplier,divider}, to avoid float calculations. The first pair is used for the 1-usec clock, the second one for the tick(838ns) clock.

13.4 Timer precision

I found no info about this issue. It is reasonable to assume that if your CPU is specified to run at 100MHz, it should run at that exact speed (within the tolerances of quartz crystals, which are normally around 10ppm). But I suspect that the exact speed depends on your motherboard. If you are worried, there are many small test programs you can run under plain DOS to get the exact speed. Anyway, this should be not a very important point, since all the file timings are done by calling the library/kernel time routines, and do not depend on the TSC.

13.5 Additional points

The experimental 'time stretching' algorithm is only enabled when using the pentium (with or without TSC). I found that it is a bit 'heavy' for 486 machines and disallowed it.

If your dosemu was compiled with pentium features, you can switch back to the 'standard' (gettimeofday()) timing at runtime by adding the statement

    rdtsc off
in your configuration file.


Next Previous Contents
 
The DOSEMU team