Re: reltime() low part incorrect in win32?
What should be returned by the reltime() call? If Vim script only
handles int types, the values returned are apparently inconsisent.
Am I missing something, or is reltime() on windows currently useful
only for short delta times?
I'm considering making a patch that will roll the amount of the low
part into the high part, but of course that might invalidate the
high part. An alternative would be to return a list of 4 ints.
P.S. Internally, QuadPart is used so I guess that must be correct.
On 6/11/06, George V. Reilly [EMAIL PROTECTED] wrote:
(Moving the non-developer list to BCC.)
Eric Arnold wrote:
I'm trying to understand what I'm seeing with the msec timing on win32
(cygwin). Inside the debugger, I'm seeing:
(gdb) p tm_delta
$1 = {u = {LowPart = 2434313347, HighPart = 896}, {LowPart = 2434313347,
HighPart = 896}, QuadPart = 3850725010563}
(gdb) n
180 n1 = tm_delta.HighPart;
(gdb)
181 n2 = tm_delta.LowPart;
(gdb) p n1
$4 = 895
(gdb) p n2
$2 = -1860653949
And in Vim:
:echo reltime()
[895, -162159878]
So is this a bug? Internally, the low part of theproftime_T
structure is positive, and it shows up externally as negative. I
checked, and as far as I can tell, the LowPart is a win32
LARGE_INTEGER, which is 8 bytes, which is trying to be stuffed into a
long which is 4 bytes. I think the right answer is a double, but
I'm not real sure about how win32 stuff works (since WhyTF has it
defined a special LARGE_INTEGER type?).
If you go look at the definition of LARGE_INTEGER in the Windows
headers, you'll see that it's a union of a 64-bit integer (QuadPart) and
two 32-bit integers (HighPart, LowPart). It has to be a LARGE_INTEGER
because the profiler uses QueryPerformanceCounter() to get the most
accurate results, and that's what QPF uses. LARGE_INTEGERs date from the
early 90s, when many compilers didn't support intrinsic 64-bit operations.
The value you actually want is QuadPart. However, this is calibrated in
system-dependent ticks, which are generally, but not always, equal to
the frequency of your CPU. To convert QuadPart to milliseconds, multiply
QuadPart by 1000/Frequency, where Frequency is the result of a call to
QueryPerformanceFrequency().
--
/George V. Reilly [EMAIL PROTECTED]
http://www.georgevreilly.com/blog
Re: reltime() low part incorrect in win32?
Eric Arnold wrote: What should be returned by the reltime() call? If Vim script only handles int types, the values returned are apparently inconsisent. Am I missing something, or is reltime() on windows currently useful only for short delta times? reltime() returns a list to be able to store more than one number. You shouldn't use the return value for anything but reltime() and reltimestr(), since they depend on the system. -- panic(Fod fight!); -- In the kernel source aha1542.c, after detecting a bad segment list /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: reltime() low part incorrect in win32?
(Moving the non-developer list to BCC.)
Eric Arnold wrote:
I'm trying to understand what I'm seeing with the msec timing on win32
(cygwin). Inside the debugger, I'm seeing:
(gdb) p tm_delta
$1 = {u = {LowPart = 2434313347, HighPart = 896}, {LowPart = 2434313347,
HighPart = 896}, QuadPart = 3850725010563}
(gdb) n
180 n1 = tm_delta.HighPart;
(gdb)
181 n2 = tm_delta.LowPart;
(gdb) p n1
$4 = 895
(gdb) p n2
$2 = -1860653949
And in Vim:
:echo reltime()
[895, -162159878]
So is this a bug? Internally, the low part of theproftime_T
structure is positive, and it shows up externally as negative. I
checked, and as far as I can tell, the LowPart is a win32
LARGE_INTEGER, which is 8 bytes, which is trying to be stuffed into a
long which is 4 bytes. I think the right answer is a double, but
I'm not real sure about how win32 stuff works (since WhyTF has it
defined a special LARGE_INTEGER type?).
If you go look at the definition of LARGE_INTEGER in the Windows
headers, you'll see that it's a union of a 64-bit integer (QuadPart) and
two 32-bit integers (HighPart, LowPart). It has to be a LARGE_INTEGER
because the profiler uses QueryPerformanceCounter() to get the most
accurate results, and that's what QPF uses. LARGE_INTEGERs date from the
early 90s, when many compilers didn't support intrinsic 64-bit operations.
The value you actually want is QuadPart. However, this is calibrated in
system-dependent ticks, which are generally, but not always, equal to
the frequency of your CPU. To convert QuadPart to milliseconds, multiply
QuadPart by 1000/Frequency, where Frequency is the result of a call to
QueryPerformanceFrequency().
--
/George V. Reilly [EMAIL PROTECTED]
http://www.georgevreilly.com/blog
