Hi!
How it is possible (MMX registers in use?) that the rdstc command does not work?
I'm using Agner Fogs ReadClock() command (in a dll), but I get always the same value?! To countercheck I used the implementation in the dll and got the same strange behaviour. int start=ReadClock() and int end=ReadClock() have both the same value it seems.
Somebody seen such behaviour?
Greets, Hannes
PS: Hardware is a P4.
Seems to be a strange compiler/debugger bug. Values are changing although there's no code changing them?!
I never had such problems with the VisualStudio 6 debugger until now. Anybody ever heared something like that?
Cheers, Hannes
This may sound stupid, but maybe the counter looped over? How long between each read? I know this is unlikely, but i just thought I would suggest it. Could you post your code so we can try it on our PCs?
Thanks for your interest!
It's C++ and looks roughly like this:
#include "misc.h" (contains declaration of read_clock())
CLASS::what_ever
{
unsigned int start=read_clock();
...call member function...
unsigned int end=read_clock();
unsigned time=end-start;
}
As far as I can see here, the code calls the read_clock() function correctly, executes rdstc and returns a valid time. It seems that the return value isn't written to the variable (start, end). However, start, end, time show the *same* value (even time which should be end-start) in the debugger (something like 1240428), but if e.g. start is written to the console, it shows something different from the debugger window (e.g. 9 or 0).
Further it seems to be compiler version dependent wether the whole thing segfaults during execution or shows above behaviour.
I'll try asap to incorporate read_clock into the class and execute it as member function, maybe this is enough to stop that.
Greets, Hannes
PS: using Agner Fogs library shows the exactly same behaviour (I actually used it first, after that I coded my own read_clock()).
Quote from: liquidsilver on September 21, 2005, 08:27:42 PM
This may sound stupid, but maybe the counter looped over? How long between each read? I know this is unlikely, but i just thought I would suggest it. Could you post your code so we can try it on our PCs?
If you mean the TSC, it's a 64-bit counter. A 4GHz processor would need to run ~146 years to do this.
I'm sure if you decompile it, you MIGHT find something like this.
call main;
main:
mov ebp,esp
sub esp,(total number of vars*varsize allocated locally)
call ReadTime
mov [ebp-xxh],eax
mov [ebp-xxh],eax
your start and end variables are allocated locally and probably set right at the start of your procudure. (everything locally allocated is allocated on the stack when the procudure first starts).
Try some inline asm.
a_h,
This is just a guess on my part, but:
In other routines I've used, that deal with 64-bit numbers, a function will usually give you access to the 64-bit answer in 1 of 2 ways.
1) by returning a 32-bit pointer to a 64-bit structure containing the answer. This is probably what you are getting, since each time you run the routine you get the same answer. Look at SystemtimeToFileTime, with it you pass a 32-bit pointer in and get a 32-bit pointer out.
2) by returning the high order 32-bits in the EDX register and the low order 32-bits in the EAX register.
I'd put my money on 1)
Tell us what the documentation for your ReadClock() function says!
hth,
farrier
a_h,
Which version of ML are you using? If it's 7.00 or greater, the debug information is not going to work in Visual Studio 6.0. You need to use ML (and LINK) 6.x.
Thanks to all your replies! :U
The answer to all that is so simple, the debugger shows wrong values. Writing to stdout shows that. Maybe I can get my hands on a newer version.
@farrier: actually its 2. I wrote read_clock() myself and it returns only the lower dword, which is up to now sufficient.
@Greg: thanks for the tip, but I had to learn that the hard way :-((
@all: thanks again for all your help!
Cheers, Hannes