In \masm32\macros\timers.asm, there are several Windows API functions used, such as GetCurrentProcess and QueryPerformanceCounter.
Is it possible to rewrite this so only asm instructions used, and no Windows API?
Just wondering, though.
it can be done using, primarily, CPUID and RDTSC instructions
however, during program initialization, you may want to use a few API's to get better readings
when i time code, i like to start the program with...
INVOKE GetCurrentProcess
INVOKE SetProcessAffinityMask,eax,1
INVOKE Sleep,750
Michael sets the process priority - not sure what he does with QueryPerformanceCounter
process priority may not be an issue for you
can you be more specific about your needs or what you are trying to do ?
Quote from: dedndave on November 13, 2011, 11:43:07 AM
can you be more specific about your needs or what you are trying to do ?
well i'm thinking of an OS independent timing macro
linux or other OS's probably have similar functions
you can use some of the conditional assembly directives to make the changes for you
however, it can be done "in the raw", as well
attached is a simple example
3 time marks are made (A, B, C)
the difference between the first 2 marks (B-A) is our "reference"
the code to be timed is inserted between mark 2 and mark 3 (C-B)
so, the resulting time is (C-B)-(B-A), or C-2B+A
these processors may execute instructions "out of order" to enhance performance
to ensure they are serialized, the CPUID instruction is used
note - .586 or better processor must be specified to assemble CPUID and RDTSC
Ah I forgot about the conditional compilation :red
Guess I should learn more about Linux API.
Thanks anyway.
In DOS we used to utilize the 8253 timer and RDTSC, but your operating system independence runs in to a couple of issues, like the IOPL, virtualization, CR4.TSD, thermal throttling, and multiprocessor. Unless you nail execution to a particular core there is no guarantee that the TSC will be in sync. It's been a long time single I tinkered with x86 start up code, but as I recall one core comes up first and then brings up the others, and deals with the APIC. Clearly things may have evolved in terms of integration, and complexity in terms of cores/threads/hyperthreads/numa.
Using a pair of RDTSC and computing the delta cycles is generally quite effective if you time enough to be measurable, but not exceed the thread/process timing quanta, and the ability to reject outlying measurements. The temptation is always to measure over long periods and average, but this can often be quite misleading, and people often confuse throughput and latency.
The DOS version is essentially pure assembly, but even they must contain OS-specific details (CLI/STI).
http://www.masm32.com/board/index.php?topic=12540.0
And for timing (as in elapsed seconds/milliseconds/microseconds) under DOS, to get reasonable accuracy you must resort to techniques that could not possibly work under Windows or Linux (reprogramming the system or RTC timer and installing an interrupt handler).