Here I am again. I am trying to use the two macros in masm32\macros\timers.asm that calculate the milliseconds for code between the macros to execute. I copied both macros, timer_begin and timer_end as asm files in the macros folder. I included "INCLUDE \masm32\macros\timer_begin.asm" and ..timer_end.asm in my program. I call the timer_begin macro, then execute my code then call timer_end macro. At the end of the program I print to screen with an inkey str$(eax) statement. The timer_end macro is supposed to exit with milliseconds saved in eax. Program assembles and links with no errors. My code executes properly. I check a known result by loading eax with the named dword variable.
BUT, the macros appear to do nothing. When I let the macro load milliseconds in eax, the value is over one billion milliseconds, clearly not correct since the program executes in the blink of my eye.
So, I am stumped. I thought about writing the macros as procedures so I could do some detective work, but the macros have stuff I don't understand. Examples include the use of @@: and jnz @B, and there is no @B anywhere in the macro.
Any advice will be very much appreciated. Thanks, Jim
the counter_end macro returns the count in EAX
but - it is not in milliseconds or microseconds - it is in CPU clock cycles
so, if you have a 2 GHz computer, that's 2,000,000,000 per second :P
when we measure code, we are not interesting in how fast the computer is
we want to know clock cycles - not seconds
attached is a program that tests the DIV instruction
i get about 30 clock cycles on my 3 GHz pentium 4
hope it helps
Thanks for your reply. I will check out your example.
timers.asm has two sets of "timer" macros. The first set uses counter_begin and counter_end to count and store in eax cycles. The second set uses timer_begin and timer_end to count and store in eax milliseconds. The second set of macros just converts cycles to milliseconds. I am not sure how this second set of macros gets the PC GHz.
This second set is the one I have been trying to use. Maybe I will try the first set and do my own conversion from cycles to milliseconds.
Thanks, Jim
hi Jim
it's been a while since i looked at the other one
but, i seem to recall it uses the FPU to calculate the clock cycles
and - it preserves EBX, whereas the original one does not
as Michael explains, there is also a difference in the way they tally....
http://masm32.com/board/index.php?topic=1663.msg16953#msg16953 (http://masm32.com/board/index.php?topic=1663.msg16953#msg16953)
Thanks again for your help. My 1.8 GHz i3 uses 6 cycles for your example.
The reason I want time is because the code I want to time is a sort of PC crunch power measurement, and I have results for about 100 computers ranging from a HP12C calculator to a 2.4 GHz P4. The original code I wrote used the system clock to measure elapsed time in 1/100 seconds. So, I would like to convert cycles to milliseconds.
My code takes 265 cycles using your program. However, that seems like a very short time on a 1.8 GHz i3. And using the timer macros gives 7253 milliseconds, or over seven seconds, a huge difference from the 265 cycles. (That result may explain why the second set of macros is not recommended.) My 2.4 GHz takes about .06 seconds as measured by my original program.
I would appreciate any additional insight.
Thanks, Jim
Thanks, Jim
in the attachment above, i selected a Loop_Count value so that each pass takes about 0.5 seconds
we seem to get more repeatable results if each pass uses that much time
it has no real bearing on the code speed or the CPU speed, really
what may be helpful is to get some kind of measurement of the CPU clock speed
then, convert clock cycles to elapsed time, using the CPU frequency
here is a link to a thread on the "old forum"
there is an attachment to this specific post that measures CPU frequency
http://www.masmforum.com/board/index.php?topic=12024.msg92378#msg92378
i see that attachment has no source code
that means i probably intended to do some clean-up - lol
but, that thread might provide some interesting reading, anyways
here it is, as is....