On 08.09.2019 10:09, Michael Van Canneyt wrote:
On Sat, 7 Sep 2019, Zoe Peterson wrote:
From: Martin Frb <laza...@mfriebe.de>
But that does not mean, it needs to be changed on existing targets.
And if it is not going to be changed, then it can be documented.
I agree with everything Martin has said, though IMO GetTickCount must return values in ms on every single platform and
any that can't should have it removed. It's not a precision timer and it should not be an intrinsic for whatever
random RDTSC-like instruction the current platform has. It's used for checking (rough) elapsed times. I honestly can't
think of a single use for the current function as defined, especially in a cross-platform app. Precision and accuracy
can vary, but unspecified units with no way to query them is ridiculous.
For relative measurements, units are not needed. A ratio has no units, the
only thing that is required is that the units for both measurements are the
same (which should be the case on a single platform).
Strictly defined measurement units are important for cross-platform (and Delphi) compatibility. So GetTickCount_2 -
GetTickCount_1 must return how many milliseconds have elapsed between calls of GetTickCount regardless of the platform
where the program is running.
But I have re-checked the Microsoft documentation, the implementation, and
have added millisecond units to documentation of gettickcount(64).
Thanks.
Note that the FPC implementation gives an increasing time, not the number of
milliseconds elapsed since system boot. Which is what, strictly speaking,
it should return to comply to the Microsoft implementation.
Yes. Implementing this for every platform would be overkill. GetTickCount in FPC should be documented just as a
millisecond counter without defined starting point and without guaranteed precision.
Yuriy.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal